Developer.com

Articles originally published at Developer.com. Some have been retired, so if you find a broken link to developer.com and are looking for the content, use the Contact Me link and I will re-publish it here.

Portal Federation with WebLogic Portal WRSP Part 1: The Basics

Scott S NelsonLeave a comment

Originally published at developer.com

WSRP stands for Web Services for Remote Portlets, a handy specification from the folks at OASIS that provides a standard for portal applications to share portlets between portals. Put another way, WSRP is the ability to produce an interface to useful functionality which can be consumed throughout your enterprise with little or no changes to existing code. Sound familiar?

Almost all of the latest versions of commercial and open source portal products support WSRP, though your mileage may vary based on the vendor.  The basic mechanism is the same as any old web service. The producer provides a WSDL that instructs the consumer on how to generate a SOAP request. The difference between web services and WSRP is that with a web service the developers of the consumer application next need to figure out how they will use the SOAP response where the WSRP consumer receives a response at the presentation level and all the consumer needs to do is decide where they will display it.  The portal frameworks abstract the heavy lifting and all that is required of developers is to configure the producer and consumer to achieve basic WSRP integration. In theory, this simplicity provides all an enterprise needs to reuse portlets across the enterprise “instamagiclly”. In practice, business requirements rarely let us get off the hook so easy.  In fact, once an enterprise begins to use WSRP, the requirements tend to get more and more complicated, which is why the WebLogic Portal (WLP) has evolved to provide more and more WSRP functionality with increasing ease of development.

When WSRP Makes Sense

WSRP is a technology that provides three benefits. One is reuse; another is performance, (though oftentimes using WSRP will provide only one these two benefits); and the third is the ability to release portlets asynchronously.

WSRP is not the only approach to achieving portlet reuse. Portlets can also be bundled into a WAR file and used as a shared library, or simply copied from one application to another.  Where reuse is the goal, WSRP is the solution of choice when the portlet is used in more than one portal.

Sometimes portlets are resource intensive. If a portal page contains a collection of portlets where system or network resources impact the usability of the portal, WSRP can provide a strategy where the processing is divided across servers to improve performance.

Portals provide the ability to aggregate access to applications. In many enterprises, these applications are owned and maintained by disparate groups where the coordination of release schedules can be difficult (if not impossible). Here, WSRP provides the advantage of allowing a portlet or group of portlets to be released independently of the main portal application.

The Best Way to Consume a Remote Portlet

In the WebLogic Portal, portlets are WSRP enabled by default since version 9.2, as shown below:

In fact, the notation in the .portlet file is only required if you are not offering your portlet as remote, as show by these two snippets:

<netuix:portlet definitionLabel=”simpleProducerA_1″ title=”Simple Producer A”>

<netuix:portlet definitionLabel=”nonRemoteExample_1″ offerRemote=”false” title=”Locals Only”>

In a WSRP implementation, the remote portal is the producer and the portal displaying the remote portlet is the consumer. The consumer gains access to the producer by registering the producer as a remote producer by accessing the producers WSDL. The WSDL is generated automatically by WLP and available as an address from the producers web application in the format of [server_address]/[web_application]/producer?wsdl. The example portal applications referenced in this article are named wsrpConsumer and wsrpProducer, with the portal web applications being named wsrpConsumerWEB and wsrpProducerWEB, which would make the producer’s WSDL address http://localhost:7001/wsrpProducerWEB/producer?wsdl. This WSDL simply defines key details about interacting with the producer, such as security:

<wssp:SecurityToken TokenType=”http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID”>

And where to find various services, such as registration:

<s0:port binding=”s3:WSRP_v1_Registration_Binding_SOAP” name=”WSRPRegistrationService”>

<s4:address location=”https://localhost:7002/wsrpProducerWEB/producer/wsrp-1.0/registration” />

</s0:port>

While the most basic of WSRP producers require 60+ lines of XML to define the WSDL, even the most complicated WLP applications will generate a WSDL for you. The only hand editing you may need to do is with simpler files such as wsrp-producer-config.xml and wsrp-producer-registry.xml.

Remote portlets are consumed in the producer with a proxy portlet, and WLP provides two ways to create a proxy portlet. One method is through the WebLogic Workshop IDE at design time. Defining a proxy portlet at design time requires providing an address to the producer in a .portlet file, which cannot be changed at runtime. Due to this drawback, this approach is not recommended in this article. If you want to see how it works in detail, you can follow the tutorial included in the WLP documentation.

The other method to define a proxy portlet is through the WLP Portal Administration Tool (PAT). To define proxy portlets in the PAT, you must first create a streaming portal. Streaming portals are database-driven rather than file-based (where users access the portal through a .portal file defined in Workshop). There are many considerations outside of WSRP in choosing between a file-based versus a streaming portal and are beyond the scope of this article.

To quickly illustrate the steps of creating a streaming portal and consuming a WSRP portlet we will use the naming conventions from our example applications as well as the existing assets in the example. For simplicity we will have both portal applications deployed to the same domain. With this in mind, here is the process to create a streaming portal and consuming a simple remote portlet:

With portal server running, navigate to http://localhost:7001/wsrpConsumerAdmin for your consumer portal’s administration console (or, with the Portal perspective open in Workshop, select RunOpen Portal Administration Console) and log in with the admin credentials. From the Portal Management page, create a streaming portal and a desktop based on the .portal file you created in Workshop. In the screen shot below, we’ve created a portal named “wsrp” with desktop named “default”.

Next, add your producer portal to your library by expanding Library and Remote Producers, then click on the Add Producer button. In the wizard, enter

http://localhost:7001/wsrpProducerWEB/producer?wsdl and click Search. Click on the Remote Producer in the search results, then follow the self-explanatory prompts to complete registration.

With your remote producer registered, click on the producers’ name, then Selected Portlets to access the Add Portlets button. The Add Portlets button will start a straight-forward wizard to add your remote portlets.

Finally, add the Hello Producer to your Consumer Desktop using the intuitive PAT, which will display as follows once completed:

In WLP 9.2, the process of placing your remote portlets must be repeated manually for each environment (typically, with varying names and number of environments, Test, Staging, and Production). Beginning in WLP 10.0, WSRP portlets can be included in propagation as other portal configurations are in earlier versions of WSRP (see Propagating Weblogic 8.x Portals for an introduction to portal propagation).

If you followed the naming examples in this article you can browse to http://localhost:7001/wsrpConsumerWEB/appmanager/wsrp/default to see the results.

Congratulations, you have achieved portal federation with WSRP!

If you found this interesting, please share.

© Scott S. Nelson

BEA Weblogic Portal 8.x Tips & Tricks

Scott S Nelson

Originally published at developer.com

As documentation goes, BEA is in my top five vendor list. It can be hard to find documentation for older versions (it’s all still there, the links are just buried), but once you find the product documentation page you’ll have a well indexed reference for most of what you need. Still, there are always those wonderful little gotchas that you will run across where the answer either came after the documentation or is something that you can do to make your life easier that the product reference team didn’t think of (or, in some cases, they thought of it but didn’t give the best answer).

In this article I want to share a few solutions I have discovered outside of the standard documentation. Some you can find on BEA’s Dev2Dev (though it might take a long time), some came from trial and error, and one came from days of pain following a the recommended path to later try almost the total opposite approach and cut my work time by two-thirds. And I am sure there are dozens (if not hundreds) of other little helpful hints, but these are the ones that I remember the most in almost three years of building many BEA Portal solutions.

You Can Get There From Here

The most cherished word to any vendor is also the most dreaded to an IT department: Upgrade. This is very near the top of my mind with BEA showcasing Aqualogic as a growing technology stack. I know that as soon as they have the Aqualogic Portal (or whatever name they are going to give it), I will have a lot of upgrades to do (and as a professional services consultant, I personally look forward to it). Based on the many job postings from BEA lately, my guess is that it will be heavily based on the Plumtree portal they bought last year. You may think I digress speaking of future upgrades in an article about the current version, but it all ties in.

The first BEA portal upgrade I dealt with was from version 7.x (really .x in this case, because I don’t recall the exact release) to version 8. Being a self-appointed member of the semantics police, I recall complaining that the project name for this process included the word migration rather than upgrade. When the dust finally settled, I retreated from my position on the project title. Version 7 is nothing like version 8 (which was the point of mentioning the likelihood of the next version being based on an entirely different product).

Being the astute engineers that are expected in professional services, the migration team went directly to the BEA site for a hint on how to handle this project. As I said in the beginning, BEA has pretty good documentation available and we immediately found a very detailed set of instructions for upgrading. I’m not going to make a big deal of what I thought about the instructions because I’m still a fan of BEA products. What I will state is that I am really, really glad that I had to migrate multiple portals or else I wouldn’t have this topic to write about.

If you ever need to move from version 7 to version 8 (and there are plenty of version 7 applications still out there), ignore the upgrade documentation. Instead, inventory your existing application and separate it into webflow portlets and non-webflow portlets. By doing this, you will save yourself hours (days or weeks, depending on the size of your application). Do read the online instructions for working with version 8 if you’re not familiar with it. Then create a brand new portal in 8 with all of the pages in Workshop. Once you have a nice, blank portal, import your non-webflow portlets one at a time. With each import, run a build. Each time you do this you’ll get a stack of errors for the methods that have changed. Take the advice of the Hitchhikers Guide to the Galaxy and Don’t Panic. Track down the compile errors and look up what that method did for you in version 7 and change it to use the version 8 method. This will get easier with each portlet, especially if you have a consistent development process because before you are done you’ll start to anticipate errors and correct them before you build. This may sound tedious, but it is a heck of a lot easier than following the proscribed path and tracking down both compile errors and functional bugs.

Now, according to all the documentation, you can port your webflows to pageflows with minimal fuss. This reminds me of the question asked by every mother all over the world: “If you’re friend jumped off a bride, would you do it to?”  Instead, create a new pageflow, fire up your old webflow editor, and re-write it in pageflow format. This will get rid of the many limitations imposed on version 8 webflow support and prevent the harried calls from whomever inherits your applications asking how the heck to make a change to that monster. Again, no matter how tedious this sounds, it will be worth it in the time saved. Additionally, version 9 has no support for webflows, so following this track will leave you ready for a future upgrade. In fact, many of the work-arounds described in this article have been solved as a standard feature in version 9 (which I had not investigated prior to starting this article).

Upgrading from one version 8 Serviceicipate errors and correct them before you build. This may sound tedious, but it is a heck of a lot easier than following the proscribed path and tracking down both compile errors and functional bugs.

Now, according to all the documentation, you can port your webflows to pageflows with minimal fuss. This reminds me of the question asked by every mother all over the world: “If you’re friend jumped off a bride, would you do it to?”  Instead, create a new pageflow, fire up your old webflow editor, and re-write it in pageflow format. This will get rid of the many limitations imposed on version 8 webflow support and prevent the harried calls from whomever inherits your applications asking how the heck to make a change to that monster. Again, no matter how tedious this sounds, it will be worth it in the time saved. Additionally, version 9 has no support for webflows, so following this track will leave you ready for a future upgrade. In fact, many of the work-arounds described in this article have been solved as a standard feature in version 9 (which I had not investigated prior to starting this article).

Upgrading from one version 8 Service Pack (SP) to another is not nearly as difficult, yet some caution should still be exercised. The whole versioning naming convention is misleading. Sometimes they are referred to as .release, sometimes as service pack releases. This would make you think that they made some enhancements that are major changes, and you would be thinking correctly. However, it would also lead you to believe that methods and classes may be added or improved that require no effort on your part to upgrade, and there you have the gotcha. Sometimes they replace classes and methods. Though the changes are covered in the release notes, who wants to read through all of that to find the two or three things that are specific to your application?

I have found that most of the big changes take place in the framework implementations. The easiest way to a smooth upgrade is to import everything into a new portal except your portlet and framework JSPs. Those you want to leave behind, then create new JSPs in your new portal and copy-paste all of your custom code from your original application. Workshop will color code the stuff that no longer works right away for you. Once you have hand-moved your JSPs into your new portal, run your build and track down the little changes. Then regression test and find the other quirks that may have popped up. One that occurred from one SP to the next is the relative path used for page tab icons. The quickest way to figure out where to move your reference to is to let the icon fail to show up and the view the page source to see where it is looking for it. The relative path changed from the framework to application. While this was a wise approach (especially for clustered environments) it can be daunting to figure out without knowing that a change occurred and it isn’t some bug in your port.

Write Once, Run In Any Project

Alright, this is just a quick note on a quirk of Workshop that can be annoying for those who frequently use either their own legacy code or purchase code. I’m sure most folks who have done any extensive work with Workshop have already discovered that a BEA control project has no option for adding classpaths. While I’m sure there was some good reason behind this, it’s tough to use your existing code base throughout your portal project if you can’t reference it when you need it. To get around this limitation, just make sure that what you need is in the classpath of another plain old Java project. Then set your build order so that the project with your legacy code reference is built before your control project.

This isn’t a perfect fix as you will still need to keep your various portal projects in sync if there are cross dependencies. You will also need to document this dependency in case your control project later becomes legacy code. Still, this is far more maintainable of a solution than duplicating your legacy code into your control project.

Dude, Where’s My Portlet?

Portals that are built well (or are well funded despite not having been done right the first time) will grow. If the growth of your portal requires no security restrictions on your new portlets and you manager all of your portal layouts through Workshop, you will never know that there are some quirks to how portlets are associated to a portal in the portal administration application. For the rest of us, here’s a couple of things to consider if it is early enough, and how to deal with them if it is too late.

Properties about your portal are stored in the database when you deploy it to your server. From what I can guess (I’m too lazy to look it up, so please don’t send me a flood of comments that this is documented somewhere) the portal was designed to be run from a managed server with plenty of horsepower. This makes sense, considering that useful portals will require a fair amount of resources and have a large enough base of users to require a server farm. What this means to those of us who manage portals in the wild is that time spent documenting and following a proper deployment plan will save hours (or days) of work dealing with future changes.

When deploying your portal, you want to first deploy it to your admin server before deploying to managed servers. This approach will allow the server to handle LDAP propagation automatically for you, so that new users are added to the full server farm instead of the first server you deploy to. At the time of this first deployment, your portal assets are catalogued into the database for management. If you deploy to a managed server first, the assets become frozen and future deployments will not update your portal administration application with new portlets and/or page. With this in mind, even if you will not be initially deploying to a server farm it is still a wise strategy to create a managed server environment anyway and follow the above plan.

If you are already in production and didn’t plan for this, all hope is not lost. The best approach would be to re-build your environment with a deployment plan, eliminating extra steps in the future. That said, I have seen situations where this was not practical (generally based on political rather than technical challenges). In which case, the next approach to gain access to your assets is to do the following:

First, if you have an admin server and haven’t already deployed your portal to it, do so now. If you have resource constraints you can always remove it once you have updated your database.

Next, in the portal admin console, create a new desktop and then assign your current portal to it. The new desktop should contain your new pages and portlets as the new desktop will generate the necessary database entries. Depending on the service pack you have installed you may need to re-start the server to add these assets to your original desktop. Now you can manage your new assets.

Another important thing to remember about your initial deployment planning is that in a clustered environment, you must deploy your LDAP to Admin only, so that it replicates properly across all servers. Otherwise you will frequently run into user profile issues. In the managed server environment, you will want to use your Admin deployment to make updates as all the neat stuff is there, where you have to search or type group names to find them in managed server admin consoles.

Are We There Yet?

Some portals are small, some are big, and some are gigantic. I’m not talking about users, and not necessarily functionality, but total code involved. Code bases get huge, especially if there have been upgrades or (gasp!) migrations from one platform to another. From SP 3 up, loading Workshop and running builds can seem to take forevvvvvvver as all the paths are validated and the code assists are updated. It’s the old story of do you want it easy to use or fast (pick one).  The answer from everyone is: both! That’s ok. It was evolution that got you to this point and one more step will get you past it and back to fast(er) builds. The two-step trick is to first find all the legacy stuff that you aren’t using and get rid of it. Of course, most of us don’t have the time to do that, but the second step will help in that case, too. Step two is to find all the legacy stuff (preferably only what you still use) that has not changed in eons and JAR it up. JARs get stored more efficiently and only need to be referenced the very first time the environment is created. This will cut your build times anywhere from 10 – 80%, depending on how thorough you are and how honest you are.

When Java Calls for A Coffee Break

Portals are often used to consolidate disparate data sources into a single view, especially with the growing popularity and need for Business Intelligence Dashboards. With many of these views being composites of separate sources and/or accessing web services, sometimes the data for a portlet takes a long time load. Despite the modularity of a portlets at design time, at run time it all is distilled into a single web page, and a web page doesn’t load until the last line of HTML as been generated and sent to the browser. When one or more of your portlets takes too long to load, you could be inundated with complaints about your portals performance, even after having done everything programmatically possible to streamline your back end calls. How do you provide the users with what they want while not gaining a reputation for causing a traffic jam at the coffee pot? Use the old iFrame trick (aka the new AJAX trick).

iFrames for portlets (note: version 9 has built-in functionality to handle this issue and it is strongly recommended that if you used this work-around in version 8 to re-write your portal to use the out-of-the-box features available in version 9).

Faster Start Up in Development

One complaint I hear from developers is about how long it takes the application to start when developing. The default memory settings are low to be respectful of slower developer machines. It is easy to change by updating your setDomainEnv.cmd file to use your memory more efficiently. The basic setting is MEM_ARGS=-Xms96m -Xmx256m. Change this to MEM_ARGS=-Xms786m -Xmx768m and the full memory will be allocated immediately rather than growing as you need it (which is usually during start up). Keep in mind that if you have less than 1GB RAM installed, this won’t work, but then if you do have less, you need more to do any serious development. I consider 1.5 to be the minimum to be productive as a developer.

Once you are up and running, you may run into out of memory errors. While this is a good way to convince the boss to buy you an upgrade (as I did before I found the real problem), t

If you found this interesting, please share.

© Scott S. Nelson

Propagating Weblogic 8.x Portals

Scott S NelsonLeave a comment

Originally published at developer.com

Before Service Pack 5 (SP5), the most dreaded day of some portal projects was the push to production. If you have a fairly decent deployment plan, getting the portal EAR into production was a snap. What profited the pizza industry with the late-night dinner orders was moving all of the settings that are stored in the database from Staging to Production. Entitlement roles, groups, and the association of entitlements to portlets had to be re-created by hand. Because these deployments often take place after hours, the person with the pleasure of creating them will almost always make some mistake that takes hours to trace down. The mistakes aren’t because it is terribly difficult, but because even if you get to come in late for these deployments, you still probably woke up at your usual hour and are starting to fade a bit. That, and few deployment documents are perfect. The propagation tool is here to rescue you.

The propagation tool is built into SP5 and SP6, and is available as a patch upgrade to SP4 (note: there are other patches included in this download, so this may entail risk depending on what APIs you are using). For earlier versions, you need to contact your BEA representative.

There is an official manual for the propagation tool on the BEA site, which I recommend if you want every nuance. What I will cover here is a typical, simple, straight-forward approach that will save you some time. I also deviate a bit here for the sake of doing the process faster, knowing that time is often a factor when you get to your deployment phase. As with any process, I highly recommend doing a dry-run in a test environment first (mostly because I own no stock in pizza companies). The steps described here are for SP5. They should be the same for SP6. If you wish to attempt this on an earlier version, I suggest going to the link mentioned earlier.

First, you need to put the tool where you can use it. Copy propagation.war from <WEBLOGIC_HOME>weblogic81portallib to the root of your Staging domain (or Integration, if you are moving to Staging). To make sure you put it in the right place, make sure that adminPortal.war is already in the same path you are copying to.

Start your server through Workshop, then go to <DOMAIN_ROOT>META-INF and open application.xml in your favorite XML editor. After the last <module> entry, add the following:

<module>
  <web>
    <web-uri>propagation.war</web-uri>
    <context-root>propagation</context-root>
  </web>
</module>

When you save the file, Workshop should detect the update and automatically deploy it to the server for you. If for some reason it doesn’t, you will need to stop your server, open config.xml, and manually add the following to the end of your <Application> node:

<WebAppComponent Targets="genericPortalServer" URI="propagation.war"/>

Once your server has started up again, check your installation by going to http://<SERVER>:<PORT>/propagation (example: http://localhost:7001/propagation). You should see the following screen:

Propagation Screen
Propagation Screen

From the screen the next step should be obvious: Click Export an Inventory. The application will walk you through the steps with fairly clear instructions (you’re welcome to read them all, based on your paranoia level or the fragility of your application). The steps are as follows, with only minor comments where necessary:

  1. Enter the user name and password for the uber admin account
  2. Click Continue
  3. Click Export XML
  4. Click Export Locally and save to someplace convenient (unless you are propagating to an domain on the same machine with read-write privileges)

Export complete! That was easy, wasn’t it? Now you need to import it. Again, I’m going to pare things down for the simple, straight-forward process here. If your application is really, really complicated, fragile, or you just have a lot of time on your hands, you can read the full documentation at http://e-docs.bea.com/wlp/docs81/sp5/prodOps/propTool.html#1025334.

First, you need to install the propagation application on the target server. Copy the same war file to the same place in your new domain. Then deploy your portal EAR to the new domain. So long as you create the EAR after installing the propagation application on the original server, you shouldn’t have to do anything else. If for some reason it doesn’t work for you, follow the same installation instructions given above for the original server.

The import process is also very simple, and has step-by-step prompts. With lots and lots and lots of warnings. Again, we’re going to cover the short path here. And, again, read the docs at the link given earlier if you have concerns. For me, the longest part was reading the warning labels.

With the EAR and the propagation application deployed on the target server, open the propagation application the same way as before, only with your new URL (http://mynewhost:7001/propagation), and do the following:

  1. Click Import an Inventory
  2. Log in
  3. Click the Specify the file radio button
  4. Enter the full path to the zip file you created in the export process, including the file name, i.e., I:DeveloperDotComPropagating BEA Portalsinventory.zip
  5. Click Continue (if you see The input file was not found. The application tree was loaded instead., check your path)
  6. Click Continue
  7. Click Preview Changes
  8. Click the checkbox, then click Continue
  9. Click Deployment Complete
  10. Click Continue
  11. Click Continue
  12. Scroll to the bottom and Click Continue
    1. On the Review Manual Changes page, there will probably be a list. This is why I recommend a dry run, because you may not need to do anything with this list, so click Continue the first time and out and note during your testing if anything needs to be dealt with. Note that users are not exported, and this is addressed later in this article.
  13. Click Continue
  14. Click Commit the Inventory

The next screen has you export what you have just imported. Again, for the dry run, I wouldn’t bother. For the real deal, though, it is a good best practice.

You can now go to your new portal URL and review how well things turned out for you. You will need to add your users to do much real testing. If you have an authentication method that relies on an external application, you will need to test and possibly reconfigure it for your new domain. If you use the internal LDAP, you should create your users before testing.

While not considered a best practice by BEA, it is a common practice to have the same users in Staging as Production, so I feel obligated to list the steps here to propagate these as well.

In your original domain, go to the Weblogic Server Console and navigate to your security realm and click on the Migration tab and then the Export tab.

Weblogic Server Console
Weblogic Server Console

I prefer to enter a path ending with LDAP to make it easy to find. Click export, then check the path you entered to make sure you have the five expected files.

If necessary, copy the folder you exported to to somewhere where your new deployment can access it.

Now go to the Import tab in your new domain and enter the location to import from.

Despite the dire warning in the propagation screen, you should have most of your assets up and running, except some as noted in the Manual screen.

Now, go have dinner at home rather than the pizza.

If you found this interesting, please share.

© Scott S. Nelson

How to Customize the Color Scheme for the BEA WebLogic Server 9.x Administration Console

Scott S NelsonLeave a comment

Originally published at developer.com

At last year’s BEA World many portal developers were excited to hear that the WLS Administration Console is now portal-based. As developers, we all know that what excites us doesn’t always excite those who hold the purse strings, and customizing an application that is only used by IT generally falls pretty close to the bottom of the budget approval list. At least until there is a really good reason for it. So, my first foray into customizing the WLS Administration Console didn’t come about until 9.2, and was limited to changing color schemes.

A Business Case for Customizing the Console

For those of you looking for approval to customize your console, the driver for the project this article is based on came from a case where multiple BEA domains were running installed on the same physical machine. When the maintenance team would log in to the various consoles they would occasionally make an update to the wrong domain. Doh! For those who have done support, this comes as no big surprise. Many service activities are scheduled in off hours. Off hours are defined as when most users are off the applications and most IT folks are off their par because it is too late at night. The only visual cue as to which console you are logged into is some subtle text showing the user name and domain name.

The solution for this was to color-code the header in each Administration Console. While this sounds fairly straight-forward to the average portal developer, there are a few things that made it a bit of a challenge. First, the Administration Console application is compiled (as it should be), so cracking it open was a bad option as this could have upgrade implications. Second, even if one were to crack open the Administration Console portal (we’ve all made a similar call and regretted it at the next upgrade), the application under WEBLOGIC_HOME affects all domains rather than individual domains. Finally, the steps described at http://e-docs.bea.com/wls/docs92/console_ext/rebrand.html leave out a couple of minor pieces that are only obvious to portal developers. To make a long story short (which is only ever said when it is already too late) I came up with the following steps that worked for this effort.

(If you don’t already have a portal development environment, download the latest from http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/weblogic/portal/.)

Steps to Changing the Header Colors

Create a new workspace for Eclipse for your customization project. For old-time Eclipse developers, this may sound odd. I thought it odd that the BEA best practice is a new workspace for each related group of projects and at first stuck to my old ways of one workspace for all projects. Then I made a change to the wrong project and stopped being so obstinate. Since there are similar types of projects from one group to the next, it is an easy mistake to make and thus the smart recommendation not to. Long story etc.

In your new workspace, create a new Java project named console-extension. While it doesn’t matter what you name your project, this name makes it easier to remember what it is for and to reference documentation related to console customization. Next, import [WEBLOGIC_HOME]samplesservermedrecconsole-extension into your new project. If you are unfamiliar with Eclipse imports, this is done with the File System option in the Import dialog. Once we have this tree in, we want to trim the branches that we don’t want to change by deleting the following:

workspaceconsole-extensionframeworkmarkup

workspaceconsole-extensioncommon

All in workspaceconsole-extensionframeworkskinsxray EXCEPT the following:

css

images

skin.properties

All in workspaceconsole-extensionframeworkskinsxrayimages

All in workspaceconsole-extensionframeworkskinsxraycss

All in workspaceconsole-extensionframeworkskeletonsxray

All in workspaceconsole-extensionimages

Now we want to add some files for our use. First, create a skeleton.properties file in  workspaceconsole-extensionframeworkskeletonsxray and add the following:

jsp.search.path:  ., ../default

Then do the following imports (all files in the path for each):

[WEBLOGIC_HOME]serverlibconsoleappwebappframeworkskinsdefaultimages to /console-extension/framework/skeletons/xray/images

[WEBLOGIC_HOME]serverlibconsoleappwebappimages to /console-extension/images

[WEBLOGIC_HOME]serverlibconsoleappwebappframeworkskinsdefaultcss to workspaceconsole-extensionframeworkskinsxraycss

Next, open /console-extension/framework/skins/xray/skin.properties and delete the following (spread in groups through the file):

theme.plain.search.path: plain/images, images

theme.alert.search.path: alert/images, images

theme.wlsmodules.search.path: wlsmodules/images, images

theme.wlstoolbar.search.path: wlstoolbar/images, images

theme.wlsbreadcrumbs.search.path: wlsbreadcrumbs/images, images

theme.wlschangemgmt.search.path: wlschangemgmt/images, images

theme.wlsworkspace.search.path: wlsworkspace/images, images

theme.wlsnavtree.search.path: wlsnavtree/images, images

theme.wlsmessages.search.path: wlsmessages/images, images

theme.wlsstatus.search.path: wlsstatus/images, images

theme.wlsquicklinks.search.path: wlsquicklinks/images, images

link.window-plain.href:       plain/css/window-plain.css

link.window-plain.rel:        stylesheet

link.window-plain.type:       text/css

link.window-alert.href:       alert/css/window-alert.css

link.window-alert.rel:        stylesheet

link.window-alert.type:       text/css

link.window-wlsmodules.href:       wlsmodules/css/window-wlsmodules.css

link.window-wlsmodules.rel:        stylesheet

link.window-wlsmodules.type:       text/css

link.window-wlstoolbar.href:       wlstoolbar/css/window-wlstoolbar.css

link.window-wlstoolbar.rel:        stylesheet

link.window-wlstoolbar.type:       text/css

link.window-wlsbreadcrumbs.href:       wlsbreadcrumbs/css/window-wlsbreadcrumbs.css

link.window-wlsbreadcrumbs.rel:        stylesheet

link.window-wlsbreadcrumbs.type:       text/css

link.window-wlschangemgmt.href:       wlschangemgmt/css/window-wlschangemgmt.css

link.window-wlschangemgmt.rel:        stylesheet

link.window-wlschangemgmt.type:       text/css

link.button-wlschangemgmt.href:       wlschangemgmt/css/button-wlschangemgmt.css

link.button-wlschangemgmt.rel:        stylesheet

link.button-wlschangemgmt.type:       text/css

link.window-wlsworkspace.href:      wlsworkspace/css/window-wlsworkspace.css

link.window-wlsworkspace.rel: stylesheet

link.window-wlsworkspace.type:      text/css

link.book-wlsworkspace.href:  wlsworkspace/css/book-wlsworkspace.css

link.book-wlsworkspace.rel:   stylesheet

link.book-wlsworkspace.type:  text/css

link.window-wlsnavtree.href:  wlsnavtree/css/window-wlsnavtree.css

link.window-wlsnavtree.rel:   stylesheet

link.window-wlsnavtree.type:  text/css

link.window-wlsmessages.href: wlsmessages/css/window-wlsmessages.css

link.window-wlsmessages.rel:  stylesheet

link.window-wlsmessages.type: text/css

link.window-wlsstatus.href:   wlsstatus/css/window-wlsstatus.css

link.window-wlsstatus.rel:    stylesheet

link.window-wlsstatus.type:   text/css

link.window-wlsquicklinks.href:     wlsquicklinks/css/window-wlsquicklinks.css

link.window-wlsquicklinks.rel:      stylesheet

link.window-wlsquicklinks.type:     text/css

script.skin.src:    skin.js

script.skin.type:   text/javascript

script.menu.src:    menu.js

script.menu.type:   text/javascript

script.util.src:    util.js

script.util.type:   text/javascript

script.delete.src:  delete.js

script.delete.type: text/javascript

script.float.src:   float.js

script.float.type:  text/javascript

script.menufx.src:  menufx.js

script.menufx.type: text/javascript

(note that if you want to customize any of the above UI elements for your own application leave the ones you need).

Open netuix-extension.xml and delete the following: default-window-icon=”window-icon.gif” and default-window-icon-path=”/console/images/”

To change our header appearance we need to change two files. First, open /console-extension/framework/skins/xray/css/body.css and change the value of background-color: for .bea-portal-body-header; Then, grab an image editor and change the color in /console-extension/framework/skins/xray/images/banner_bg.gif to the same value. For ascetics, you may wish to edit /console-extension/framework/skins/xray/images/banner_logo.gif as well.

Deploying Your Updates

Finally, save everything, then right-click on the console-extension project and select Export. Export as a JAR file to domain-dir/console-ext directory (or to a handy local location to later be uploaded to the domain-dir/console-ext directory). If you made any of your changes in the file system rather than in Eclipse, be sure to refresh your project before exporting or you will get errors.

The example below uses the color value of FFCC33 to replace the default:

While there may be some simpler paths to achieving this, this particular approach was the fastest solution that should have little or no impact to future upgrades within the 9.x WebLogic Server series. If most of these steps seem daunting, you can grab the workspace from here (PLEASE CREATE LINK TO workspace.zip) and find the values you want to change.

Scott Nelson is a Professional Services Principal Portal Consultant by day and a blogger with a sense of humor by night. This article illustrates the former. To confirm the latter for yourself, visit http://humor.fywservices.com/.

If you found this interesting, please share.

© Scott S. Nelson

Installing PMD Plugin for WebLogic Workshop 10gR3

Scott S Nelson3 Comments

For those that read my Cleaner Code with the PMD Eclipse Plug-In article on Developer.com, you will know that PMD is one of my favorite tools for saving time in code reviews. I recently wanted to review a project built for WebLogic Portal 10.3 and was frustrtated to find that it would not install through the Eclipse updater.  At the time I wrote the article, I was unable to find zip install for the more recent PMD versions. Today I found a new location for  the old download and unzip install files for PMD on SourceForge today at http://sourceforge.net/projects/pmd/files/, and it seems to work fine when installed with this approach.

If you found this interesting, please share.

© Scott S. Nelson