Dear Jeromy,
Jeromy Evans - Blue Sky Minds wrote: > > Out of interest, which container and browser are you testing with and > how is the browser sending the JSessionID to your container? > Within the browser you can determine whether you are using the same > JSessionID or a new one by monitoring the raw requests. If the Session > was lost, you'd have a new JSessionID. > I'm using Tomcat 5.5.23 and I tried with Internet Explorer 7.0 and Firefox 3.0. Yes, I can do that, to monitor the raw http requests in Eclipse. Jeromy Evans - Blue Sky Minds wrote: > > A redirect result and a redirectAction result are the same as far as the > browser is concerned. They both return a 30x http status with a location > header providing the next URL to GET. In the case of redirectAction, > the result calculates the URL based on the name of the action. In the > redirect case, the result uses the location value directly. In both > cases, the URL performs a GET to the new URL, including the JSessionID > if appropriate (if it's in a cookie, or included in the URL) > O.K. Jeromy Evans - Blue Sky Minds wrote: > > It is feasible that your JSessionID is indeed reset as the result of a > redirect if cookies are disabled and JSessionID is not automatically > appended to the new location by the container/struts2. > No, my cookies are enabled all the time. But if my JSessionID is not automatically appended to the new location by container/struts2 in case of redirect action, why ? -- Best regards, Milan Jeromy Evans - Blue Sky Minds wrote: > > Milan Milanovic wrote: >> Dear Al and Dave, >> >> I tried to fix that error with session variable all weekend and I didn't >> managed to fix it. When action is defined as redirect action to another >> namespace, and when that action is called, another action called method >> doesn't see my session variables. I just changed this redirect action to >> that another namespace, as standard action (not redirect) and I now see >> my >> variables! I don't have any idea why it doesn't work with redirect >> action, >> but I'm SURE that there is some problem. >> > > Out of interest, which container and browser are you testing with and > how is the browser sending the JSessionID to your container? > Within the browser you can determine whether you are using the same > JSessionID or a new one by monitoring the raw requests. If the Session > was lost, you'd have a new JSessionID. > > A redirect result and a redirectAction result are the same as far as the > browser is concerned. They both return a 30x http status with a location > header providing the next URL to GET. In the case of redirectAction, > the result calculates the URL based on the name of the action. In the > redirect case, the result uses the location value directly. In both > cases, the URL performs a GET to the new URL, including the JSessionID > if appropriate (if it's in a cookie, or included in the URL) > > It is feasible that your JSessionID is indeed reset as the result of a > redirect if cookies are disabled and JSessionID is not automatically > appended to the new location by the container/struts2. > > regards, > Jeromy Evans > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/-S2--Refactoring-Action-classes-tp18813229p18851558.html Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
