Remy told me he didn't know the reason for any restriction, but figured there probably was one if the restriction was there.
I've pinged the tomcat dev mailing list to see if anyone else there knows a reason for the restriction.
I've implemented a fix for this that seems to work fine, so it's not the case that there was an unapparent technical reason URL rewriting couldn't be handled.
Did this fix make its way into the latest 4.0.4 CR2 release? I'm seeing quite a lot of this warning/error in my logs from a 4.0.3 installation.
Where do I go to download 4.0.4CR2 release?
I am having trouble with URL rewriting (it is a requirement to turn cookies off in our application). Passing the outgoing URL through response.encodeURL() does not seem to be working (It leaves the URL unchanged). I know I am grasping at straws, but I thought the fix that Brian made for JBAS-3015 might make a difference.
You don't want 4.0.4.CR2, you want 4.0.4.GA, which is the final release.
I do think you're grasping at straws though, as I can't see how my change would affect the behavior of response.encodeURL(). :(
<Context cookies="true" crossContext="true"> <!-- Session persistence is disable by default. To enable for all web apps set the pathname to a non-empty value: <Manager pathname="SESSIONS.ser" /> To enable session persistence for a single web app, add a WEB-INF/context.xml --> <Manager pathname="" /> <!-- Install an InstanceListener to handle the establishment of the run-as role for servlet init/destroy events. --> <InstanceListener>org.jboss.web.tomcat.security.RunAsListener</InstanceListener> </Context>
The relevant part is 'cookies="false"'; the rest are just the defaults from jbossweb-tomcat55.sar/context.xml. IIRC, if 'cookies="true"' and the browser has presented a session cookie, encodeURL() knows this and skips the unnecessary session id encoding. Perhaps this is your problem.
You could also edit the jbossweb-tomcat55.sar/context.xml file itself and turn cookies off by default for the entire server.
Sorry, in the above example context.xml, it should say 'cookies="false"'.
Thanks for your reply.
I do have 4.0.4.GA installed. I looked through the release notes, and could not find a reference to JBAS-3015, so I thought JBAS-3015 might be included in a later download.
I am also using a context.xml file in WEB-INF directory which specifies cookies="false". This setting is definitely turning cookies off. The problem is that I can't seem to get the session ID to be carried in the URL.
Not sure then what the problem is. Only thing I can suggest it to step it through a debugger, and/or turn off cookies on your browser to see if you get encoded URLs. The latter of course isn't a solution for your problem; may just give you more info to figure it out.
JBAS-3015 is in the release notes in the main 4.0.4.GA binary download (readme.html); perhaps you were looking at jira.jboss.com, where the notes for a GA release don't include issues fixed for earlier betas, CRs, etc. Well, no matter :)
I found my problem. It was the placement of my call to encodeURL(). I had put it in the server-side code which we use to send the end-user to the approprate page. Assuming "url" contains the URL we want to forward the user to, we use a RequestDispatcher as follows:
RequestDispatcher rd = request.getRequestDispatcher(response.encodeURL(url));
When done like this, the url never got encoded with the session ID.
However, when I call the encodeURL() mehtod in the JSP code intead, it works.
Thanks. ... Tim
Same issue with me.
When I disable the cookies, then i do not get the SessionID in the URL and cannot maintain session between 2 browser requests.
I do not have custom code for URL rewriting.
I am using JBoss 4.0.4 Patch1, with Apache and ModJK.
Any resolution yet?
My understanding of this thread is that there was nothing left to resolve. 4.0.4.GA supports URL rewriting for distributed sessions; timward found a problem in his code that was causing his problem.
What do you mean you "do not have custom code for URL rewriting"? Are you calling HttpSessionResponse.encodeURL(url) whenever you output a URL? Or using a taglib that does it for you? If not, you're not going to get url rewriting.