Jeff Sheets wrote:
I just want to clarify one point of your post.
You're saying that all of the portlets in one war file, thus a part of the same application, share the same session. But it's not true that each "portlet" has it's own session, just each portlet application [war], right?
Correct.
At least that's how I understood it, but I just wanted to get some clarification from the experts :-)
-- Jeff Sheets
On Sat, 11 Dec 2004 10:13:17 +0100, Ate Douma <[EMAIL PROTECTED]> wrote:
Hema Menon wrote:
Hi,
How can a struts application deployed as a JSR 168 portlet in Jetspeed 1.6 with fusion get the user information and other session variables in Jetspeed's context? In other words we have some jetspeed 1.5 which are running under jetspeed 1.6 with fusion. We converted an existing struts application to be deployed as a portlet in Jetspeed. We have authentication done thru sybase and when the user logs in user information and some other relevant information are added to the session. These variables are available to all the portlets in jetspeed. However when a struts portlet is added to jetspeed, the context seems to be different even though it resides in the jetspeed portal. The question is 1. Is it possible for the struts application to access the session variables that are added on login?
Yes :-)
2. If it is how can it be done?
There are several factors at play here. First of all, cross-context restrictions. In contrast to other (non-JSR168) portlets, Jetspeed-2 (fusion) deploys its portlet applications as separate web applications and accesses them using the cross-context feature of Tomcat. According to the servlet specs, each web application *must* have its own session, so formally, access to cross-context session is not supported. But, there are two solutions to this problem I know of (if you find more I'd would like to know about it).
1) Use Tomcat 4 Tomcat 4 has the annoying bug in that it does *not* create separate sessions for cross-context access. Normally, this is quite a security breach and one of the reasons why I'm never going to use Tomcat 4 again. But, it might be helpful in your situation. Then, you should have direct access to your login variables.
2) Make use of (J2) org.apache.jetspeed.Jetspeed.getCurrentRequestContext(). That returns a RequestContext instance which gives you access to the session of the portal (getSessionAttribute() and setSessionAttribute()).
Note: while the RequestContext is defined in the public (J2) jetspeed-api package, the Jetspeed class is *not*. So, you will have to build against the J2 portal. Furthermore, this is not (yet) a formal supported feature of Jetspeed-2: we (the team) might conclude that this is too much of a security breach and close that backdoor in the future. But, in that case I expect us to at least leave read-only access in place as we rely on it ourselves for the J2 management portlets.
Good luck, Ate
Any inputs very much appreciated.
Thanks, Hema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hema Menon
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
