[
https://issues.apache.org/jira/browse/PB-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641169#action_12641169
]
Antony Stubbs commented on PB-84:
---------------------------------
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.
{code}
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);
}
}
{code}
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.
This points towards a Pluto issue now, not a bridges issue, so I will create
another jira issue for pluto.
For a work around, I have changed getWindowId to use
{code}
session.setAttribute(PORTLET_WINDOW_ID, ...., PortletSession.PORTLET_SCOPE);
{code}
in both places where it is used, and the windowId now appears to be generated
on the attribute, and detected correctly.
I have created a Pluto issue here:
https://issues.apache.org/jira/browse/PLUTO-516
> CCE in PortletWindowUtils.getPortletWindowId
> --------------------------------------------
>
> Key: PB-84
> URL: https://issues.apache.org/jira/browse/PB-84
> Project: Portals Bridges
> Issue Type: Bug
> Components: common
> Affects Versions: 1.0
> Environment: Mac OS, Wicket Portlets, OpenPortal Portlet Container
> Reporter: Tim Boudreau
> Attachments: portals-bridges-common-1.0.4.jar
>
>
> I'm trying to get wicket portlet support working over OpenPortal. I've
> hacked together implementations of ServletContextProvider and
> PortletResourceURLFactory - just required exposing WicketFilter from the
> Application to get the necessary data. I can deploy a portlet, but...
> I'm getting this exception.
> java.lang.ClassCastException: java.lang.Double
> at
> org.apache.portals.bridges.util.PortletWindowUtils.getPortletWindowId(PortletWindowUtils.java:45)
> Looking at the code, this seems like a clear bug: The method casts to String
> here:
> (String)session.getAttribute(PORTLET_WINDOW_ID);
> and if null fills in the value with an instance of Double. If it's going to
> put a Double there, it should probably not expect a String - this exception
> will occur any time this method is called twice for a PortletSession, it will
> throw the CCE the second time it is called.
> Since the value is not used, probably simply changing it to
> Object portletWindowId = session.getAttribute(PORTLET_WINDOW_ID);
> would fix it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
