Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
1.1.0
-
None
-
None
Description
The Portlet Integration Framework created a dependency on the portlet jar. Shortly after the code was integrated, someone removed the dependency by catching and ignoring the NoClassDefFoundError that results if you don't have the portlet jar in your classpath.
While it is good that we remove the dependency for JSF applications that are not running in a portal, the current fix is very inefficient because it causes multiple exceptions to be thrown, caught, and ignored with virtually every request.
Example of current fix:
try{
if (externalContext.getRequest() instanceof PortletRequest)
}catch(NoClassDefFoundError exception){
// Portlet api jar isn't in the classpath.
}
What is needed is a better way to determine if the request is coming from a portlet. The solution must not rely on the Portlet API and also must never generate exceptions.
My proposed soultion is to put a flag in the portlet session. The flag will be set in the MyFacesGenericPortlet. So the new code will look something like this instead:
if (externalContext.getSessionMap().get(MyFacesGenericPortlet.PORTLET_REQUEST_FLAG) != null)
if (externalContext.getRequest() instanceof PortletRequest) { externalContext.dispatch(viewId); return; }
}
What would be even better is a solution that factors out the if statements and solves the problem using polymorphism. However, that would incur a major refactoring of many components. At some point this major refactoring should be done so that MyFaces could support requests that come from a third source (Servlet, Portlet, and something else). But I do not recommend the refactoring at this time. For now, the instances where MyFaces needs to check for a portlet request or response is confined to two source files. It is manageable.
I'll leave this out for comment for a few days before submitting a patch.