Hi Ate, Thanks a lot for your prompt response. Tomcat 4 is a definite 'no' for us. We are currently on 5.0.28 and is likely to switch to 5.5. So I guess I'll have to look into the option of using getCurrentRequestContext(). I'll try it out with our application, and may have more followup questions on it. Again, thanks for the information.
Hema On Sat, 11 Dec 2004 10:13:17 +0100, Ate Douma <[EMAIL PROTECTED]> wrote: > > > > > Hema Menon wrote: > > 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hema Menon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
