WSRP Portlets and Sessions

Wednesday, August 27, 2008

One question that comes up from time to time when using WSRP with WebLogic Portal is how are sessions handled with respect to portlets. When using portlets from the same producer, the question is are the portlets sharing the same session and if so is it a good practice for the portlets to share information using the session as a communication mechanism.

Let's deal with the first topic first, do portlets from the same producer share the same session. The answer is that it depends on how your consumer portal is configured. If you look at the file wsrp-producer-registry.xml in WEB-INF, you will see that each producer has a section called requires-initCookie. The values allowed in this XML setting include None, perUser and perGroup. A value of None is straight forward and means that the portlet does not use a session. The perUser value means that every portlet for every user gets its own session and thus no sessions are shared. A value of perGroup means that sessions are shared when portlets are from the same producer and in the same group. The group is determined by the portlet's groupId in the portlet definition (aka the .portlet file). Thus, portlets with the same groupId will share the same session for the same user if they are from the same producer.

As an aside, how cookies, and thus sessions, are handled from consumer to producer is actually part if the WSRP specification. If you check page 24 of the specification here, you will find the following under CookieProtocol Type:

This type is a restriction on the string type that is constrained to the values “none”, “perUser” or “perGroup”. These values carry the following semantics:

• ”none”: The Producer does not need the Consumer to ever invoke initCookie().
• ”perUser”: The Consumer MUST invoke initCookie() once per user of the Consumer, and associate any returned cookies with subsequent invocations on behalf of that user.
• ”perGroup”: The Consumer MUST invoke initCookie() once per unique groupID from the PortletDescriptions for the Portlets it is aggregating on a page for each user of the Consumer, and associate any returned Cookies with subsequent invocations on behalf of that user targeting Portlets with identical groupIDs.

Now for the second question, using the session as a communication mechanism. In general I believe this is a bad practice because it couples the portlets in a way that is fragile and not obvious to the consumer. Since the consumer controls how the sessions are managed, coupling portlets via the session means you are dependent on the consumer to use the right configuration. Another problem is when things are coupled such that Portlet B depends on a session value from Portlet A, what happens if the consumer elects to display B first?

Thus in general when communicating between portlets in WebLogic Portal containers prefer Inter-Portlet Communication as the preferred means for communicating between portlets. IPC decouples the portlets since the communication is event driven and not targeted at specific portlets.

Session sharing can be useful in certain cases, for example if both portlets are accessing the same information that is static for the lifespan of the session then this could be cached in the session. As an example, if we have two portlets that work with a customer object that is expensive to retrieve then there is benefit to sharing access to it in the session. However the portlets are not coupled because either portlet can retrieve the customer object directly if it is not in the session at the moment using a lazy initialization type pattern.

As with anything there is always exceptions. If for some reason your portlets need to pass a 500K piece of data back and forth it would be pretty inefficient to use IPC for this since the data would be sent over the wire up to the consumer and back down to the producer. But in general the exceptions are few and far between so stick with IPC for sharing information and do not use the session for this purpose.

Posted by Gerald Nunn at 12:25 PM | Categories: WebLogic | | | Permalink

Rules for Working with Exceptions

Monday, August 04, 2008

Since I work on the consulting side of Oracle I tend to see a lot of code from clients and it surprises me how often I still see developers making basic mistakes when working with exceptions, both when throwing them and when consuming them. At the risk of beating a dead horse, since this topic has been covered to death, here are some basic rules I try to live by when working with exceptions.

Rule #1. If you catch an exception and wrap it in a new thrown exception, make sure to chain the exception by including it in the constructor of the newly thrown exception. For example:

try {
blah..blah..blah
} catch (IOException e) {
   throw new MyApplicationRuntimeException(e);
}

Rule #2. Include meaningful information in the exception, specifically include whatever information is necessary in order to track down the issue if someone needs to look into it further. Nobody likes dealing with exceptions that have something stupid like "Unexpected error" set as the message. As a positive example, if you're writing code for a financial application and an account creation operation fails, include the account number along with other relevant information in the exception that would enable support or operations staff to diagnose the issue. This additional information can be wrapped in fields of a custom exception class or simply included in the exception message.

Rule #3. Log exceptions where they are handled not where they are thrown. I'm sure we have all seen examples of applications where the developers log the same exception over and over again as it traverses up the stack. Applications should only log an exception once and the easiest and most practical way to enforce this is to only log the exception where it is handled. In other words, if your code simply catches the exception and rethrows it as a wrapped exception then do not log it, rely on the code above you to log the exception properly.

Rule #4. In general, prefer unchecked exceptions except in cases where there is a reasonable chance the receiver of the exception can do something meaningful in response, in these cases use checked exceptions. There has been a lot of debate over the usage of checked vesus unchecked exceptions over the years, I tend to fall somewhat in the middle of the debate in that I feel both types are useful. When throwing an exception, the key to knowing which type to throw is to ask youself "Can someone do something useful in response to this exception?". If the answer is yes, then use a checked exception. If the answer is no or you are in doubt then use an unchecked exception. In general the vast majority of thrown exceptions in an application should be unchecked.

Ruke #5. Always document the use of unchecked exceptions in javadoc through the use of the @throws clause.

Posted by Gerald Nunn at 7:29 PM | Categories: Java | | | Permalink

Short Review of Logitech Dinovo Mini

Thursday, July 31, 2008

One thing that has always bothered me about my HTPC was the need to use the mouse and keyboard. While I have it configured for the remote control for MythTV and Elisa, there is no getting around the fact that sometimes you need a keyboard and mouse for performing regular PC duties like finding a torrent or browsing the web. I was using the standard wireless HP keyboard and mouse that came with my HTPC and while they worked well, it was never very comfortable hunching over the coffee table to perform these tasks.

Enter the Logitech Dinovo Mini keyboard/trackpad combination.

The basic premise behind the Dinovo Mini, as you can see from the picture above, is that you can use it comfortably from a couch or armchair without having to balance a keyboard in your lap or sit at a desk. Given that I have a home theater system because I like keeping my butt planted on the sofa this works for me. The first thing you notice when you unbox the Mini is how small it is, the device is very comfortable to hold and any Blackberry user is going to be instantly conmfortable with the two hand grip/thumbs over the keyboard style used with the Mini. The unit itself has a high wife acceptance factor as it is very attractive and the smoked plastic cover means it doesn't look out of place when lying on a coffee table.

The keyboard on the Mini is an absolute delight to use, it is responsive to the touch and has a very comfortable feel when banging out short bursts of text. You wouldn't want to write War and Peace on this keyboard but for HTPC use it is a very good fit. The backlighting on the keyboard is excellent as well though I wish there were some configuration options to control how long the backlighting stays on. One problem with the keyboard is that Logitech chose to omit certain standard keys, such as the function keys, in favor of various custom keys such as PVR controls. I can understand why they did it but personally I'd prefer the standard keys as I use a remote for controlling media center operations and I would want the Mini to be the best keyboard possible, not duplicate my already existing remote functionality.

The touchpad supports two modes, in the first mode it operates as a standard mouse touchpad similar to what you find on most laptops. In the second mode it operates as a directional pad for navigation in various media center front ends. The mode switch is quite seamless and the backlighting switches color from orange to green so it is easy to see what mode you are in. In mouse mode you can click the pad itself to perform a left click, however this can also be done by using the OK button on the left of the Mini. I found the OK button a much better solution for left clicking since pressing the touchpad down invariably moved the pointer out of range of what you were trying to click.

Unfortunately in mouse mode the touchpad is nowhere near as good as the keyboard. Trying to use the touchpad with my thumb was an exercise in frustration as the mouse cursor moved along in fits and starts no matter what I chose for sensitivity settings. At this point I was strongly considering returning the Mini however a reviewer on Amazon mentioned that he had much better luck with it using his index finger rather then his thumb. His reasoning was that the touchpad is quite small and a thumb cuts a large swatch across it, a smaller finger allows it to react better.

Giving the index finger a shot I found that the touchpad was in fact much easier to use with a finger then a thumb. I'd prefer the thumb since it is already in the right position when holding the Mini but switching to a finger is no big deal given the nice form factor of the Mini. I do think the touchpad is something Logitech really needs to address in the next version, for me I'd much rather use a thumbstick then a touchpad for the mouse.

In terms of Linux support the Dinovo Mini works well on Mythbuntu 8.1. The keyboard works out of the box, however for the touchpad I did need to make some changes to modprobe.d/options as per the instructions in the AVS Forum post called Logitech diNovo Mini Wireless Keyboard- Holy Grail for HTPC?. My next job is to see if the various custom keys on the Mini can be configured for Linux but I have not taken a shot at it yet.

All in all I would have to say the Dinovo Mini represents the best keyboard currently available for HTPC use in terms of fitting in well with the typical environment home theater environment, aka the living room. Despite the touchpad being less then ideal I would still highly recommend this device.

Posted by Gerald Nunn at 9:55 AM | Categories: Home Theater | | | Permalink

More on InvalidSessionException

In a previous post, WSRP Error Handling and InvalidSessionException, I talked about the need to trap and handle InvalidSessionException differently then other faults in a WSRP interceptor. This struck me as a bit odd because a developer should not have to worry about the type of fault thrown when writing an error handling interceptor. As a result I opened a support case with Oracle support for this issue in order to get clarification.

It turns out that the issue I was having with InvalidSessionException was due to a patch that we had deployed for another issue in WLP 10 GA. This patch, YTRS, was needed to fix an issue where InvalidSessionException would be generated if a portlet received a handleEvents or getRenderDependencies request first. Unfortunately it appears that it also broke the default InvalidSessionException handling when an interceptor is deployed.

This patch was fixed in 10.2 so this issue may be there as well, just keep this in mind when deploying an error handling interceptor.

Posted by Gerald Nunn at 9:11 AM | Categories: WebLogic | | | Permalink

WSRP Error Handling and InvalidSessionException

Friday, July 18, 2008

A common use case for interceptors in the WebLogic Portal framework is error handling. Using an interceptor allows a developer to trap error messages and display a more appropriate message to the end user while logging the error. The WebLogic Portal documentation contains an example of an error handler that can be found here http://e-docs.bea.com/wlp/docs100/federation/Chap-Interceptors.html#wp1031141.

There are two problems with that example though that developers should be aware of. First, the implementation shown is just an example and is thus somewhat naive. Specifically the example always returns HANDLED for faults and IO failures and thus never retries the request. In a production system under load where glitches do occur from time to time, eliminating all retries is not optimal and should be dealt with more intelligently.

The second issue is that there is one exception in particular that should be handled differently, this is com.bea.wsrp.faults.InvalidSessionException. This exception can occur when the producer session is missing some key information and typically is raised when the producer does not have the necessary templates from the consumer to format URLs. This can happen for a variety of reasons, such as fail over however the key point to understand is that Portal will automatically and seamlessly send a second request with the missing information. Thus the user never sees that an error occurred when this exception occurs.

So now that we have a grounding in InvalidSessionException, what does it have to do with error handling interceptors? The problem with this exception is that it is passed as a fault to interceptors just like any other fault. However, if the interceptor treats it as a normal fault and returns RETRY or HANDLED Portal will not send a new request with the missing information. In the case of HANDLED, no second request is sent while in the case of RETRY the original request is resent The only return value that causes Portal to deal with this fault correctly is CONTINUE_CHAIN.

Thus if you are writing an interceptor that handles faults it is highly recommend that you check the type of the Throwable being passed and if it is InvalidSessionException just return CONTINUE_CHAIN. Here is an example for an interceptor implementation of IBlockingInteractionInterceptor:

public OnFault onFault(IBlockingInteractionRequestContext requestCtx,
        IBlockingInteractionResponseContext responseCtx, Throwable t) {

    if (t instanceof InvalidSessionException) {
        if (LOGGER.isInfoEnabled()) {
            LOGGER.info("IvalidSessionException was generated and chain continued");
        }
        return OnFault.CONTINUE_CHAIN;
    }
    //.. rest of error handler here
}

I do have a support case open for this issue as this strikes me as a bit of a bug, developers should not have to code special handling for situations like this and RETRY should be considered semantically equivalent to CONTINUE_CHAIN for this situation in my opinion.

Posted by Gerald Nunn at 9:43 AM | Categories: WebLogic | | | Permalink

Graham Norton on BBC Kids

Monday, July 14, 2008

Is there anything weirder then watching The Graham Norton Show on BBC Kids? If you have not seen this show, it appears on BBC Kids on Rogers Cable at 10pm on Sunday evenings and is somewhat raunchy in nature. Seeing it on BBC kids makes for an odd experience though as you go straight from some rather coarse sexual innuendo to a commercial for bubble-gum squarely targetted at a 10 year old audience.

My wife and I got hooked on Graham's previous show when we lived in the UK in 1999. Like Leno and Letterman it is a talk show with celebrities but the similarities end there. For one, his show is quite raunchy with many jokes of a sexual nature and since Graham Norton is openly gay many of the sexual jokes stray to that side of the fence as well. For a second, Graham typically has two guests on for the whole hour and includes them in various bits and scenes often with hilarious results.

One of the best scenes was when he had Martin Sheen on and they did a bit called protect the President. The idea was to have a cardboard cutout of Sheen off stage and audience volunteers would jump in front of the cutout to intercept a paintball in order to protect the President. Ed Byrne, an Irish comedian who was also on, wanted to have a go himself and this prompted Sheen to actually stand-in for the cutout as well. You can view the clip on YouTube. This example highlights why this show is so good, you get to see a side of celebrities that you don't see on American talk shows. As another example, try to catch the episode with Dustin Hoffman and his wife.

In addition to Graham Norton, we usually watch Top Gear as well making Sunday nights a BBC evening. If the CBC would put out programming half as good as its British counterpart no one would complain about its budget.

Posted by Gerald Nunn at 9:03 AM | Categories: Home Theater | | | Permalink

Hey Rogers, 1999 called...

Friday, July 11, 2008

... and it wants its GUI interface back.

Posted by Gerald Nunn at 9:42 AM | Categories: Home Theater | | | Permalink

Elisa Media Center

The media center project is going strong and I finally moved the Mythbuntu HTPC downstairs to the living room where my wife could start using it (and providing QA!). My wife found that Myth was very easy to use for recording TV and playing it back but that it was pretty lacking in other areas such as video, music and picture handling. I don't think it is any secret that Myth is pretty awful in these areas but it is understandable since the focus of Myth is the recording of TV and these other plugins came after.

So looking for an alternative solution I came across the Elisa Media Center. While Elisa is still relatively new, at version 0.35, it boasts an impressive amount of usability and eye candy for a program still in the early stages. Installing Elisa was a snap as it is available in the Synaptic package manager that comes with Mythbuntu. Once it is up and running you are presented with the lovely interface pictured below.

Configuring Elisa was a little more complicated, since it is still in early days no GUI exists for performing this task. Instead configuring Elisa requires editing elisa.conf which is fortunately pretty straight forward. It only took me a few minutes to add the locations for my videos, music and pictures to make them easily accessible within Elisa.

Adding support for the remote control was more of a pain though. By default Elisa uses a lirc mapping file called streamzap.lirc which is located in Elisa's python directory. Unfortunately it looks like there is a bug in that you can only change the name of the file, you cannot point it to a new location. As a result I copied streamzap.lirc to a new file and then modified it to meet my needs.

The remote control support at this stage, while usable is still pretty primitive in that there are only a small set of commands that can be mapped to the remote. Additionally I was unable to get the Play/Pause buttons on my remote working at all, however the Enter button acts as a toggle for these functions so that was an acceptable alternative. Once the remote was configured my wife much preferred using Elisa to the Myth front-end and now my next task is to figure out a way to rename and move Myth recorded shows to an Elisa directory automatically.

To summarize, Elisa has the potential to be a killer media front end and even at this early stage it shows a lot of polish and usability A very good effort by the developers so kudos to them.

As a footnote, Elisa is written in Python which is a language often criticized for poor performance. Elisa certainly goes some way to correcting my perception of Python and even makes me interested in having a go at creating a plugin in Python.

Posted by Gerald Nunn at 9:36 AM | Categories: Home Theater | | | Permalink

WebLogic Portal Statement of Direction

Thursday, July 10, 2008

In case readers missed it, a Statement of Direction was made available on the Oracle WebLogic Portal site after the July 1st middleware briefing by Thomas Kurian. All WebLogic Portal customers should review it closely, in particular the recommendations section at the end.

Posted by Gerald Nunn at 9:07 AM | Categories: WebLogic | | | Permalink

Building Site Maps for WebLogic Portal

Tuesday, July 08, 2008

I have added a new article that discusses two different options for building site maps in WebLogic Portal. With the addition of tree optimization back in 8.1 SP4, building a site map is no longer as trivial as it used to be and this is a topic I've been meaning to tackle for awhile. This article discusses a couple of different options for building the site map while keeping tree optimization on.

Click Building a Site Map in WebLogic Portal to read the article.

Posted by Gerald Nunn at 2:12 PM | Categories: WebLogic | | | Permalink