Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <421E6246.9050402@bluesunrise.com>
Date: Thu, 24 Feb 2005 15:24:54 -0800
From: David Sean Taylor <david@bluesunrise.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Jetspeed Developers List <jetspeed-dev@jakarta.apache.org>
Subject: Re: Question about Portlet-URLs and PortletSessions
References: <77A5EB55ECC00F47BBB8B391AAF4E24357210E@hamexchange.evodion.de>
In-Reply-To: <77A5EB55ECC00F47BBB8B391AAF4E24357210E@hamexchange.evodion.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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