Hi,The encoding is only for render parameters which also includes the targeted portlet of an action
i'm using JS 1.6 with JSR168 portlets and i have problems with portlet sessions.
The Java porllet api says that portlets, servlets and jsps that are in one web-app share the same session. But this is not the behaviour that my JS 1.6 build shows.
Okay, i'll try to explain, what exactly happens :
I have a portlet-application, lets call it myportlets, that contains portlets, servlets and jsps.
My portlet shows a html-fragment that contains links, images and iframes to resources inside my portlet-application. These resources should be delivered through a servlet. So an <img> would look like this :
<img src="http://localhost/myportlets/myservlet?show=resource";>
To perform this action my servlet needs some information that is stored in the session by the portlet and here the trouble begins :
When i login to the portal, the browser receives a session cookie for localhost and path jetspeed. Thats fine. When i acces one of my jsr168 portlets i see that the created portlet-urls look like this :
http.//localhost/jetspeed/portal/_ns:base64OrSomethingLikeThatEnocodedString
That means that a request to a portlet is not send to the portlet directly, but to the portal. The portal receives the request and decodes some kind of portlet identifier from the encoded string and calls the appropriate methodIf you need to use the servlet's session rewriting feature, all of your URLs will need to be rewritten
of the portlet. And it means that the browser will send the session cookie ( with path /jetspeed ), so the portal knows to which session the request belongs.
But when the browser trys to load the above-mentioned resources ( i.e. <img src="http://localhost/myportlets/myservlet?show=resource";> )
it does _not_ send the session cookie with the request ( as it is another path) , thus the server creates a new session and the servlet cannot access the information that were stored in the session by the portlet.
Jetspeed does not get involved with the implementation of sessions and cookies. Your app server is handling that
I am now a bit unsure if my understanding of the portlet spec is right. But i think the problem could be that a PortletUrl points to the portal and notI don't think thats the problem.
to the portlet. If a PortletUrl would look like this : http.//localhost/myportlets/portletname?parameter=... and if there were session cookies for each portlet-application the browser would send the appropiate session cookie for each request to a servlet/jsp inside the same portlet-application and no new session would be created and all the things stored by portlets would be available. I know that a portlet cannot be used standalone, but there could
be something like a proxyservlet that receives the request to a portlet ( ie.http.//localhost/myportlets/portletname?parameter=... ) and maps that request to the portal.
Action and Render URLs are written back to the portal.
The portal figures out that an action is requested for a given portlet (in the ns: url the action is encoded), dispatches to the portlet to execute the action, and then renders the whole page
The servlet spec says that:
HttpSession objects must be scoped at the application (or servlet context) level.
The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container.
So you should not be able to see the session attributes from jetspeed's webapp, nor any other portlet app
However your servlet should see session attributes from other portlets using application scoped session attributes (they can also see the encoded portlet scoped attributes)
All that theory is fine, but I just ran a test of this and failed to see any session variables in my test servlet, where im pretty sure my portlets are using the session....so you may be on to something here
Not much dev on Fusion these days Im afraid you have the latest
I took my JS/Fusion from cvs head 3 month or so ago - maybe the problem is already fixed in the head ? Do you actually consider this behaviour as a problem ? For me the portlet spec says clearly that portlets, servlets and jsps that belong to the same
portlet-application share the same session, but maybe i got it wrong...
Why don't you create PortletUrls that point directly to the portlet-application instead of encoding the portlet id and parameter into an URL that points to
the portal ?
well im just swamped with work lately, 1.6 is pretty much ready to go
PS: When will JS1.6 Fusion be released ?
maybe i can find some time next week...
im sorry, but someone else could step up, because im currently in full swing of a very aggressive project development cycle and im finding it difficult to find time to even respond to this list these days
-- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
