Handling Global Parameters and Events in WLP 9.2

Monday, February 19, 2007

When building a portal, there is often a need to handle certain specific request parameters and inter-portlet events at a global level rather then at a portlet level, this blog post describes one technique for accomplishing this.

Inter-portlet communication (IPC) is a powerful technique for exchanging messages between portlets in a loosely coupled fashion, it allows portlets to work together with no knowledge of where each other is located in the Portal structure. However like most things, except for maybe Chuck Norris, it does have one achille's heel and that is the fact that only portlets can send and receive IPC events.

This issue becomes evident on larger portal projects when you may find quite a few instances where you would like to be able to send or receive an event on a global basis. As an example, when certain parameters are posted to the portal from an external web site you may want to send an event to initiate an action. Or maybe you want to have an event handled at a global level since it affects the portal itself rather then an individual portlet.

A common technique for doing this is to simply place a dummy portlet on a non-visible page. This works well with respect to sending and receiving events, but will not work if you want to send an event in response to posted parameters unless you force the hidden page to be active. Additionally, another weakness with this technique is that with streaming portals it is possible for an administrator to accidentally remove the portlet without understanding what it is doing.

An alternative technique that I prefer is to create a controller portlet that is embedded in the shell. Embedding the portlet in the shell ensures that the portlet will participate in every request and always be present. Additionally, the administrator can only remove the portlet by changing the shell which is not likely to happen and can be avoided by embedding the portlet in all available shells.

Embedding the portlet in the shell is straightforward, simply open the target .shell file and then use the netuix:portletInstance element to embed the portlet within the netuix:header element. Here is an example:

<netuix:header>
    <netuix:portletInstance 
        instanceLabel="_eventController" 
        markupType="Portlet"     
        contentUri="/portlets/controller/controller.portlet"/>
</netuix:header>

Another thing I have been exploring is to combine this technique with Spring to register backing file services for use with the controller portlet. Instead of having one large backing file that handles everything, I have many small service classes that are injected into the backing file of the controller portlet. I’ll post more about this later.

Posted by Gerald Nunn at 4:02 PM | Categories: WebLogic | | | Permalink

Creating a Print Optimized Portal in WLP 9.2

Thursday, February 15, 2007

Creating a print optimized version of your WebLogic Portal in 9.2 is easy with the use of cascading style sheets and ensures your users get the best results when printing.

A common business requirement for portals is that they have an optimized version for printing. Typically a print optimized version means that when a user goes to print the portal it should print without superfluous elements like the header, footer, left navigation, etc. Additionally some formatting elements may change to better suit the printed page.

In most standard websites this is typically done by using Cascading Style Sheets (CSS). As most of you know, CSS controls how various elements look on the screen in terms of their color, font, etc. CSS has the notion of a media type that determines which CSS is used for which media. Common media types include screen and print and a full list is available here http://www.w3.org/TR/REC-CSS2/media.html.

Browsers will automatically take advantage of the media type when specified. Thus when printing a page that has print CSS files specified, the browser will automatically incorporate those styles when printing. This gives the developer a lot of control over how the content is rendered for printing purposes and eliminates having to hit the server again to retrieve a page formatted for printing.

Also, keep in mind that CSS can also be used to determine if elements are displayed or hidden as well and it is this capability that we can leverage to create a print version of our portal. Using the display style in CSS you can easily turn off the header, footer, left navigation and other elements that you do not want to appear in the printed page.

Fortunately for us WLP is heavily based on CSS and we can use the same mechanism within a portal. The file skin.xml controls what CSS files are used as part of the CSS and skin.xml fully supports the media attribute in WLP 9.2. By creating an additional print.css stylesheet we can easily turn off the display of headers and footers when the page is printed. Alternatively, for more complex requirements you could also have a parallel set of stylesheets specifically tuned for the print media type.

As an example, here is a reduced screenshot of a sample web site I have as part of a dev2dev codeshare project I am working on.

To remove the header and footer when printed, I created a stylesheet called print.css which contains the following css:

.bea-portal-body-header, .bea-portal-body-footer {
	display: none;
}

Next I added my new stylesheet to the skin.xml that resides in the skin directory of my look and feel. The skin.xml file is a new feature that provides the developer with fine grained control over the skin definition, it replaces the skin.properties file that was used in 8.1. Adding our new stylesheet to the list of dependencies is trivial and the new line appears as follows:

<ns:link href="css/print.css" 
               rel="stylesheet" 
               type="text/css" 
               media="print"/>

Now that we have this new stylesheet in place, if we open Firefox and do a print preview we can see that the header and footer have now disappeared when printing.

Posted by Gerald Nunn at 4:02 PM | Categories: | | | Permalink

Using XStream to Troubleshoot Sessions

Monday, February 12, 2007

XStream is a great library that serializes and deserializes objects to and from XML, here we use it to troubleshoot a problem with HTTP sessions.

Finding and detecting problems with session state is one of the more difficult troubleshooting tasks. It tends to be difficult because objects in the session often have complex graphs with many nested objects. Factor in replication and things can get nasty quite quickly.

Last year I was helping a client troubleshoot a session problem where it appeared that certain attributes in the session were not being persisted after changes. The client was coming from a Websphere background where the session state can optionally be serialized after every request automatically. They had already corrected the obvious deficiency and ensured that setAttribute was called after each change to an object in the session.

Since I was unfamiliar with the application I needed a way to dump the session in a way that was human readable. While reflection is one option it turned that the work had been done for me already. XStream is an open source toolkit that enables any object graph to be serialized and deserialized to and from XML. With XStream viewing the session in a human readable format, XML, is child's play and makes it easy to see exactly what is in the session.

Thus the problem became immediately obvious when using XStream to dump the session. What we found was that the same object instance was being stored in the session using multiple attributes. On a single machine this was not an issue since a change to the object through any attribute affected all attributes as the object was a single instance. Replication throws a spanner in the works though.

As you probably know, WebLogic replicates only the attributes that have changed which means that WebLogic serializes and deserializes each object individually unlike Websphere which has an inefficient option to serialize and deserialize the entire session after each request.

This means that under Websphere the object would maintain its singleton nature since the whole session graph is serialized and deserialized in one go. Under WebLogic when the objects against each attribute are serialized and deserialized individually they become separate object instances. Changes to an object against one attribute are no longer reflected when the object is accessed through a different attribute.

What the client was experiencing was that occasionally a request would blip causing a failover to the secondary server. Once on the secondary server instead of dealing with a single object instance in the session they were now dealing with multiple copies of the same object all being in a different state. Updates to one object would not be reflected in others thus making them think that the session was not being persisted.

In short, XStream was invaluable for detecting this problem, being able to view the session in a human readable format saved me a ton of time and I’d recommend it to others dealing with issues that require being able to follow a complex object graph.

Posted by Gerald Nunn at 4:02 PM | Categories: WebLogic | | | Permalink