Hello. We've been trying desperately to use session vars from different portlets, where we've been only succesful for portlets deployed within the same war file, by using PortletSession.getAttribute(PortletSession.APPLICATION_SCOPE) or PortletSession.getAttribute(PortletSession.PORTLET_SCOPE), wich in turn just wrap HttpSession with a prefix; another portlet deployed on another war displayed in the same page PortletSession and HttpSession as empty. What we want to do is to propagate, or use a bigger session scope to have common vars for al portlets wether they are or not deployed on same war.
... those pages state there is a " Portal Session " wich I don't understand, is it the HttpSession associated with the portal App ? Or is it the bigger scoped Session I've been looking for ?
2006-03-09 18:28:33,425 DEBUG [org.jboss.web.tomcat.tc5.session.ClusteredSession] processSessionRepl(): session is dirty. Will increment version from: 7 and replicate.
... yet the portlet being displayed from the other war does not see anything in session, nor portlet-scoped portlet, application-scoped portlet, nor http session.
Any idea on how to propagate portlet session vars would be really nice.
JSR168 states that portletsession is portlet or applciation scope. Application in here is one war file. This is how all portals behave and must behave. If jboss would make it possible to share sessions in 'portal scope' it would break JSR168 spesification.
I see this good thing because sharing portlet session openly to other applications in same portal is Security issue. Even if you mean only to share you info with some spesific application, it is exposed fully to others too. Sessions can contain all kinds of sensitive data that should not be visible to other applicions. If you need to share information among several web applications securely it is very easy to set up database for that.
Until there is common and secure way to implement interportlet communication, you should stick with this... share information in portletsession in same application and use database if you need to distribute info to other applications. All kinds of 'proprietary' interportlet commucation methods will be outdated once they some standards out.
It certainly is against specification, but there must be a way, it's stated that it will be available until the next specification, if in the mean time vendor-specific techniques are made available I'll be happy with it.
I believe using a database for such kind of communication is way worse than using vendor-specific techniques.
Of course it is a security issue to share info between portlets, or between anything, but what are apps for without info ? they will eventually become useless, unless we manage some method to share info between them, and try to make it safely.