Eelco Hillenius wrote:
I suggest a three state init parameter (non-portlet / portlet / autodetect)
and 'autodetect' could be the default option.
That sounds like a good idea to me. Though I think an explicit (not
autodetect) default might be safer.
I agree.
To solve this in a transparent manner, I'll do the following (I will create a
JIRA issue for it too):
- default behavior will be changed to *not* lookup javax.portlet.PortletContext
- if a 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).
AFAICS, this provides the most flexible and 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.
So, using this solution, the Wicket Examples still runs without needed changes
in Jetspeed-2 but the default behavior
will be reverted back to *not* look for a PortletContext.
I'm already testing the above solution and plan to commit this shortly.
Regards,
Ate
Eelco
