John,
I agree the current bridges (struts and jsf) usage of instanceof to distinguish
is wrong!
One should never use instanceof on interfaces to distinguish which is
implemented by an instance.
I created a JIRA issue for this and already fixed the jsf and struts bridge in
svn, see:
http://issues.apache.org/jira/browse/PB-45
I suggest you do the same with Spring Portlet MVC.
Thanks for bringing this up.
Regards,
Ate
John Lewis wrote:
I'd like to get an opinion from the Pluto developer community on an
issue that has come up with Spring Portlet MVC.
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?
Thanks in advance for your opinions on this topic.
John Lewis
