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.
