cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: jsr 168 portlet file download
Date Thu, 20 Sep 2007 01:09:33 GMT
On 19.09.2007 10:09 Uhr, Carsten Ziegeler wrote:

> Currently there is no way I know of to achieve what you want. The only
> thing I can think of is using a servlet inside your portlet application
> to serve resources. But in this case you don't have access to the
> portlet information and you have to code every information into the url
> of the resource.

But only when you deploy the servlet in a separate web application than 
the portal, isn't it? Otherwise you should have (everything is still 
completely spec-conform) access to the same session in both the servlet 
and the portlets. The latter can use the application scope instead of 
the portlet scope when putting stuff into the session.

Only when you deploy the portlets in a one web application and the 
portal in another one it becomes trickier. (The portlets and the servlet 
always have to be deployed in the same web application, otherwise they 
can't access the same session. This is forbidden in the servlet spec.)

Tomcat allows to set emptySessionPath="true" on the connector in the 
server.xml. So the same session *id* is used for both the portal and the 
servlet. This means a cookie is registered for / and not one for /portal 
and a second one with a different session id for /downloadServlet. They 
both have a different session though following the servlet spec! But 
since the portlets run in the same web application as the servlet they 
also share the same session. So when the portlets put their stuff into 
the application scope of the session (in contrary to the portlet scope) 
it's available in the servlet as well.

I use this "feature" in a Liferay-based portal where I generate charts 
dynamically and make use of Spring's session scope. Since they contain 
sensitive data I could not just add everything to the url.

> (With 2.0 of the portlet spec things will change as the portlet then
> supports resource streaming for exactly these purposes).

I'm really looking forward to this stuff and hope there will be 
implementations anytime soon! The above limitations contradicts the 
whole idea of encapsulated functionality modules what portlets are 
supposed to be. You also need all the infrastructure like security again 
for the servlets.

Joerg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message