Hi Antony,
I think you might have uncovered a serious bug in PortletSession.setAttribute(name,value) here.
I'm with you that *by the spec* it should store the attribute under PORTLET_SCOPE, not APPLICATION_SCOPE.
In the "old' Pluto 1.0.1 this is also what is done, but in the new Pluto 2.0 this seems to incorrectly changed when the Portlet request is
"included" or "forwarded" (e.g. about always).
I've traced this back to commit r577681 which was a merge of some patches brought in by people working on the Portlet 2.0 spec implementation.
I *think* this might be done based on an incorrect interpretation of
PLT.10.4.3 - Runtime Option javax.portlet.servletDefaultSessionScope
I'm going to further investigate this as it definitely does seem wrongly implemented and will try to fix this ASAP, both in trunk and in the
spi-refactoring branch.
Regards,
Ate
Antony Stubbs wrote:
> Ok, trying to track this down, think I've found something.
>
> Why does the Pluto PorletSessionImpl#setAttribute use application shop
> in the following situation? This really needs explanation ala javadoc
> etc. Because in the spec, it clearly says that setAttribute should use
> PORTLET_SCOPE as it does in the else block. This seems to be cause the
> session attributes set in getWindowId in the Apache Bridges to fail in
> detecting the container assigned window id, because of course the
> attribute gets put into APPLICATION_SCOPE and a window id is never created.
>
> public void setAttribute(String name, Object value, int scope) {
> ArgumentUtility.validateNotNull("attributeName", name);
> if (scope == PortletSession.APPLICATION_SCOPE) {
> httpSession.setAttribute(name, value);
> } else {
> httpSession.setAttribute(createPortletScopedId(name), value);
> }
> }
>
> Ok, yup, changing the setAttribute calls from
> PortletWindowUtils#getWindowId to call the explicit version of
> setAttribute(name,value,scope) and pass PortletSession.PORTLET_SCOPE
> lets the Apache Bridges function work correctly.
>
> I will continue to investigate. Can anyone offer an explanation? The
> Apache Bridges issue is again, here:
>
https://issues.apache.org/jira/browse/PB-84>
> Antony Stubbs wrote:
> I'm having difficulty getting my helloworld portlet running on
> pluto, with apache bridges. I am getting
> StringIndexOutOfBoundsException on PortletWindowUtils#getWindowId
>
> portletWindowId = nameRef[0].substring("javax.portlet.p.".length(),
> nameRef[0].indexOf('?'));
>
> throws StringIndexOutOfBoundsException, because the value of
> nameRef[0] comes back just as PORTLET_WINDOW_ID
>
> i.e. "org.apache.portals.bridges.util.portlet_window_id" not
> "javax.portlet.p.*" as the code implies
>
> getPortletWindowId for session: CC465B39BA9199712DEEF690F90AE2C2 (thread: 15)
> no portletWindowId yet - going to derive it.
> 17/10/2008 15:44:23 org.apache.catalina.core.ApplicationDispatcher invoke
> SEVERE: Servlet.service() for servlet default threw exception
> java.lang.StringIndexOutOfBoundsException: String index out of range: -17
>
> I'm not sure but I discussed it here and it may be related:
>
https://issues.apache.org/jira/browse/PB-84 CCE in
> PortletWindowUtils.getPortletWindowId
>
> Does the Bridges windowId code not work correctly when running on
> portlet 2.0 perhaps? I know sessio0n isolation is now an optional
> feature of portlet 2.0 - perhaps that's causing problems.
>
> ___________________________
>
http://stubbisms.wordpress.com>
> ------------------------------------------------------------------------
> View this message in context: Re: StringIndexOutOfBoundsException on
> apache bridges
> <
http://www.nabble.com/StringIndexOutOfBoundsException-on-apache-bridges-tp20055052p20079383.html>
> Sent from the Pluto - User mailing list archive
> <
http://www.nabble.com/Pluto---User-f200.html> at Nabble.com.
