Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
1.3.0-rc1
-
None
-
None
Description
Currently the new portlet support is enabled automatically at runtime when WicketFilter detects the javax.portlet.PortletContext class.
When it does find this class, some of the Wicket settings are adjusted/overridden specifically for portlet support, like setting the RenderStrategy to REDIRECT_TO_RENDER.
But not always portlet support is used or needed, even if deployed in a portlet supporting web container. The automatic settings changes then can result in unexpected/invalid behavior.
To fix this, the default behavior for portlet support will be reverted back to disabled and will need to be specifically enabled.
To support transparent configuration of the portlet support, e.g. if needed even without having to change the application web.xml, a flexible layer of configuration settings will be provided:
if a Wicket filter parameter "detectPortletContext" is specified:
-> detect PortletContext if parameter value == "true"
else if a web.xml context parameter "org.apache.wicket.detectPortletContext" is specified:
-> detect PortletContext if parameter value == "true"
else if a org/apache/wicket/protocol/http/portlet/WicketPortlet.properties resource can be found on the classpath:
-> detect PortletContext if it specifies property/value "org.apache.wicket.detectPortletContext=true".
Note: the WicketPortlet.properties resource is already used by WicketPortlet itself to determine the ServletContextProvider and/or PortletResourceURLFactory class (if not specified otherwise).
This provides a 100% save solution while still allowing transparent enabling portlet support for Portals like Jetspeed-2 which provide a WicketPortlet.properties with appropriate values out-of-the-box.
Using this solution, the Wicket Examples still runs without needed changes in Jetspeed-2 but the default behavior will be reverted back to not automatically look for a PortletContext and thus by default not provide portlet support.