You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Heins, Hendrik" <he...@evodion.de> on 2005/02/24 14:48:51 UTC
Question about Portlet-URLs and PortletSessions
Hi,
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 method
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.
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 not
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.
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 ?
Please advice
Best regards
Hendrik Heins
PS: When will JS1.6 Fusion be released ?
Re: Question about Portlet-URLs and PortletSessions
Posted by David Sean Taylor <da...@bluesunrise.com>.
Heins, Hendrik wrote:
> Hi,
>
> 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
>
The encoding is only for render parameters which also includes the
targeted portlet of an action
> 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 method
> 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.
>
If you need to use the servlet's session rewriting feature, all of your
URLs will need to be rewritten
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 not
> 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.
I don't think thats the problem.
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
>
> 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 ?
>
Not much dev on Fusion these days Im afraid you have the latest
>
> PS: When will JS1.6 Fusion be released ?
>
well im just swamped with work lately, 1.6 is pretty much ready to go
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
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org