jsessionid problem fix for weblogic servers

["Braun, James F" <BR...@polaroid.com>]

I had a problem with jsessionid trashing all my images and urls until I
refreshed my browser. Ted Husted points out this phenomenon on page 66
of SIA. 

The symptom is that ;jsessionid=<~long id string here> is appended to
urls which confuses the weblogic app server.

The fix for weblogic is to add the following to the weblogic.xml file

  <session-descriptor>
    <session-param>
      <param-name>URLRewritingEnabled</param-name>
      <param-value>false</param-value>
    </session-param>
  </session-descriptor>

I'm sending out this solution because it has been a repeated subject on
this list. Should I put it in the wiki?

J.

J. Braun
Polaroid Corp.
Waltham MA USA
+1 (781) 386 6871
braunj@polaroid.com

java, sql, xml, jsp, eeuts


-- 
This transmission is intended only for use by the addressee(s) named herein and may contain information that is proprietary, confidential and/or legally privileged. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: jsessionid problem fix for weblogic servers

[Ed Griebel <ed...@gmail.com>]

I don't have a copy of SIA, so I'm not sure what it says, but as I
understand URL rewriting, it is always used on the struts URLs on the
first page returned after a session is initiated, and for links in
subsequent pages when the browser doesn't return a cookie with the
session ID. By turning this off, sessions will not be maintained with
browsers whose cookies are turned off or not supported.

I'm sure you've tried a lot of things already, but using
hardcoded/hand-generated links instead of <html:rewrite> or
<html:link> tags would probably work (maybe with the path embedded as
config-params in web.xml), or if your app server is fronted by Apache
you could use mod_rewrite to strip the jsessionid= from URLs. Or,
maybe if you put the images in the WAR but not under /do/* (or
whatevers configured as the struts servlet prefix in servlet-mapping)
the links would not be rewritten. The first idea is the one that I'm
using on a project now.

-ed

On 5/2/06, Braun, James F <BR...@polaroid.com> wrote:
> I had a problem with jsessionid trashing all my images and urls until I
> refreshed my browser. Ted Husted points out this phenomenon on page 66
> of SIA.
>
> The symptom is that ;jsessionid=<~long id string here> is appended to
> urls which confuses the weblogic app server.
>
> The fix for weblogic is to add the following to the weblogic.xml file
>
>   <session-descriptor>
>     <session-param>
>       <param-name>URLRewritingEnabled</param-name>
>       <param-value>false</param-value>
>     </session-param>
>   </session-descriptor>
>
> I'm sending out this solution because it has been a repeated subject on
> this list. Should I put it in the wiki?
>
> J.
>
> J. Braun
> Polaroid Corp.
> Waltham MA USA
> +1 (781) 386 6871
> braunj@polaroid.com
>
> java, sql, xml, jsp, eeuts
>
>
> --
> This transmission is intended only for use by the addressee(s) named herein and may contain information that is proprietary, confidential and/or legally privileged. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org