Implementing ActionRequest and RenderRequest in the same class

[John Lewis]

I'd like to get an opinion from the Pluto developer community on an issue that has come up with Spring Portlet MVC.

Thanks in advance for your opinions on this topic.

John Lewis

In a few places in the framework, we have code that generally handles PortletRequest objects, but then may need to do some special logic depending on if it is an ActionRequest or RenderRequest. In those cases, we test it with instanceof and proceed accordingly. Some other frameworks also use this technique, such as the FacesPortlet and StrutsPortlet classes in the Apache Portal Bridges project and the PortletFileUploadInterceptor class in BEKK's PortletWork project. In JSF itself, the only way to retrieve the PortletRequest is via the ExternalContext.getRequest method, which returns an Object. The javadoc for this method states that in a portlet this method returns "the current request's javax.portlet.PortletRequest instance, which will be either an ActionRequest or a RenderRequest depending upon when this method is called." In most portals all this is fine since ActionRequest and RenderRequest are implemented as subclasses of an implementation of PortletRequest. We've now run across a JSR-168 portal (that has passed the TCK) where the ActionRequest and RenderRequest interfaces are both implemented in the same class and that class is used for all PortletRequest objects. So anywhere that we test the PortletRequest using instanceof, the result is always true regardless of which request type it really represents. Clearly the TCK does not test this issue and the JSR-168 spec does not include a prohibition on implementing both interfaces in the same class. However, it does seem to be a common assumption that a given request object will only implement one of the two interfaces. Can anyone suggest a better way to detect what kind of request is being processed when working with a PortletRequest? Is the way that a lot of existing code is doing it reasonable and should this portal look to change it's class structure? Should there be an errata against the current spec about this issue? Should this be clarified in the JSR-286 spec?

smime.p7s
Description: S/MIME Cryptographic Signature