You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kyle Tippetts <k....@center7.com> on 2001/04/03 17:48:44 UTC
RE: 2nd Post: Servlets and mod_jk problem -- thanks!
Just want to thank everyone for their help and discussion on this problem.
And, I wanted to let everyone know what I found out. Milt, it was your
question about my Web-inf directory and whether it was all uppercase or not
that cracked it.
I originally created that directory as "Web-inf" but apparently on Linux,
Tomcat expects this directory to be
"WEB-INF." Once I renamed this directory and changed the <Location> tag in
mod_jk.conf appropriately, I was able to get the servlet mappings for the
context I added to work.
One thing to note, Tomcat for NT is not picky about this, because on my NT
deployment of Tomcat, I have the WEB-INF directory named "web-inf" and
everything works fine.
In summary, here are the two things that I had to fix to get my context's
servlet mappings working on Linux:
* add "JkMount /[deployment directory]/* ajp13" to the mod_jk.conf file.
(This originally solved the problem of the /test servlets not working, and I
had to add it to my context as well.)
* ensure that WEB-INF is all uppercase.
Thanks again,
--Kyle
-----Original Message-----
From: Milt Epstein [mailto:mepstein@uiuc.edu]
Sent: Sunday, April 01, 2001 9:44 PM
To: 'tomcat-user@jakarta.apache.org'
Subject: RE: 2nd Post: Servlets and mod_jk problem
On Fri, 30 Mar 2001, Kyle Tippetts wrote:
> Milt,
>
> I made the changes that Jeff did and I can now get to the /test
> servlets, but whenever I add my own context and try it (I even
> simulated one of the examples in the /test directory, I still get a
> 404 not found from tomcat. Here's what I have in my simulation
> (note that the context does in fact get added when tomcat
> starts....)
We may be going around in circles here, but:
What was the URL you tried? mydomain.com/tst/foo/bar/myServlet? And
what is the full text of the tomcat log 404 error message?
Also, I note you have "Web-inf" in the full path of your
servlet/classes directory below -- is that really what it is, or are
you just being lazy typing "WEB-INF" (because I believe it's supposed
to be ALL CAPS)?
Not sure what else to suggest at this point. Must be some little
thing we're missing.
> * mod_jk.conf
> Alias /tst "/opt/jakarta-tomcat-3.2.1/webapps/tst"
> JkMount /tst/* ajp13
> JkMount /tst/servlet/* ajp13
>
> * web.xml
> <webapp>
> <servlet>
> <servlet-name>
> test
> </servlet-name>
> <servlet-class>
> com.tst.TestServlet
> </servlet-class>
> </servlet>
>
> <servlet-mapping>
> <servlet-name>
> test
> </servlet-name>
> <url-pattern>
> /foo/bar/*
> </url-pattern>
> </servlet-mapping>
> </webapp>
>
> * TestServlet.class sits at
> /opt/jakarta-tomcat-3.2.1/webapps/tst/Web-inf/classes/com/tst
>
> Thanks
> --Kyle
>
> -----Original Message-----
> From: Milt Epstein [mailto:mepstein@uiuc.edu]
> Sent: Friday, March 30, 2001 3:48 PM
> To: 'tomcat-user@jakarta.apache.org'
> Subject: RE: 2nd Post: Servlets and mod_jk problem
>
>
> On Fri, 30 Mar 2001, Kyle Tippetts wrote:
>
> > Yes, tried this:
> > mydomain.com/test/foo/bar/myServlet
> > and it still didn't work. Now, if I do
> > mydomain.com/test/servlet/requestMap.Servlet1, I can access it
> > (obviously), but again, it really appears that servlet mappings
> > aren't working....
>
> Now again, when this doesn't work, is it an apache thing or a tomcat
> thing? What I'm trying to get at is, is apache forwarding the request
> to tomcat. That will help isolate where the problem is at. In
> particular, if it's an apache thing, it means the request isn't even
> getting to tomcat, so it probably has to do with the relevant Mount
> (ApJServMount, ApJkMount) directives in the tomcat/apache conf file
> (or, more accurately, the lack of such). This is a problem I ran into
> when I was setting up some stuff.
>
> Did you see Jeff Kilbride's recent post? Apparently he was able to
> get it to work by adding an appropriate ApJkMount directive.
>
> This does seem to be one of the less clear/less well-documented
> aspects of setting tomcat up.
>
>
> > -----Original Message-----
> > From: Milt Epstein [mailto:mepstein@uiuc.edu]
> > Sent: Friday, March 30, 2001 2:43 PM
> > To: tomcat-user@jakarta.apache.org
> > Subject: Re: 2nd Post: Servlets and mod_jk problem
> >
> >
> > On Fri, 30 Mar 2001, Jeff Kilbride wrote:
> >
> > [ ... ]
> > > Here's the servlet-mapping from web.xml file that comes with the
> > > distribution:
> > > <servlet>
> > > <servlet-name>
> > > servlet1
> > > </servlet-name>
> > > <servlet-class>
> > > requestMap.Servlet1
> > > </servlet-class>
> > > </servlet>
> > >
> > > <servlet-mapping>
> > > <servlet-name>
> > > servlet1
> > > </servlet-name>
> > > <url-pattern>
> > > /foo/bar/*
> > > </url-pattern>
> > > </servlet-mapping>
> > >
> > > Here's a snippet from my tomcat.log when I try to pull up
> > > mydomain.com/test/servlet/foo/bar/myServlet:
> > > 985983892264 - Ctx( /test ): 404 R( /test + /servlet/foo +
> /bar/myServlet)
> > > null
> >
> > Did you try the URL:
> >
> > mydomain.com/test/foo/bar/myServlet
> >
> > i.e. without the "/servlet"? My impression is that the url-pattern's
> > in servlet-mapping's are meant to follow the context part of the URL,
> > and that you don't need to include "/servlet" (although you do need to
> > include it if you are just using the servlet-name or the fully
> > qualified servlet-class). That is, part of the point of using
> > servlet-mapping's is so you don't need to have the "/servlet" in the
> > URL. This might explain some of your apparent anomalies when using
> > "test" (you had it both as the servlet-name and the url-pattern in a
> > servlet-mapping, IIRC).
> >
> >
> > > This mapping is supposed to map everything under /servlet/foo/bar/ to
> > > servlet1 -- but as you can see, Tomcat is saying /servlet/foo, with
> extra
> > > path info /bar/myServlet, doesn't exist. When I pull up
> > > mydomain.com/test/servlet/requestMap.Servlet1 or
> > > mydomain.com/test/servlet/servlet1, everything works as it should. So,
> > > Tomcat is not paying attention to the servlet-mapping entry.
> > >
> > > I think this is a problem, unless somebody has an explanation. I'm out
> of
> > > ideas.
> > [ ... ]
>
> Milt Epstein
> Research Programmer
> Software/Systems Development Group
> Computing and Communications Services Office (CCSO)
> University of Illinois at Urbana-Champaign (UIUC)
> mepstein@uiuc.edu
>
Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu
RE: 2nd Post: Servlets and mod_jk problem -- thanks!
Posted by Milt Epstein <me...@uiuc.edu>.
On Wed, 4 Apr 2001, Jim Cheesman wrote:
> At 09:53 PM 4/3/2001, you wrote:
> > > One thing to note, Tomcat for NT is not picky about this, because on
> > > my NT deployment of Tomcat, I have the WEB-INF directory named
> > > "web-inf" and everything works fine.
> >[ ... ]
> >
> >You must come from a Windows background :-) -- under UNIX, everything
> >has always been case-sensitive. And on Windows, it generally isn't.
> >Although I thought I saw some Tomcat-related documentation that
> >indicated that Tomcat is, or is going to be, case-sensitive on all
> >platforms. Maybe that's for 4.0.
>
> Didn't it change between 3.1 and 3.2? I seem to recall having fun
> with that one, especially on the URLs.
Maybe so, I don't remember exactly, I just remember seeing it somewhere.
Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu
RE: 2nd Post: Servlets and mod_jk problem -- thanks!
Posted by Jim Cheesman <jc...@msl.es>.
At 09:53 PM 4/3/2001, you wrote:
> > One thing to note, Tomcat for NT is not picky about this, because on
> > my NT deployment of Tomcat, I have the WEB-INF directory named
> > "web-inf" and everything works fine.
>[ ... ]
>
>You must come from a Windows background :-) -- under UNIX, everything
>has always been case-sensitive. And on Windows, it generally isn't.
>Although I thought I saw some Tomcat-related documentation that
>indicated that Tomcat is, or is going to be, case-sensitive on all
>platforms. Maybe that's for 4.0.
Didn't it change between 3.1 and 3.2? I seem to recall having fun with that
one, especially on the URLs.
Jim
--
* Jim Cheesman *
Trabajo: jchees@msl.es - (34)(91) 724 9200 x 2360
Personal: mogrim@arrakis.es (34) 606 770 244
Practice safe eating -- always use condiments.
RE: 2nd Post: Servlets and mod_jk problem -- thanks!
Posted by Milt Epstein <me...@uiuc.edu>.
On Tue, 3 Apr 2001, Kyle Tippetts wrote:
> Just want to thank everyone for their help and discussion on this
> problem. And, I wanted to let everyone know what I found out. Milt,
> it was your question about my Web-inf directory and whether it was
> all uppercase or not that cracked it.
I figured if I kept throwing ideas out there, something was bound to
connect :-).
And now I've got my own problem I'm trying to debug -- I'll post about
it separately, and maybe someone can help me come up with some ideas
to figure that out :-).
> I originally created that directory as "Web-inf" but apparently on
> Linux, Tomcat expects this directory to be "WEB-INF." Once I renamed
> this directory and changed the <Location> tag in mod_jk.conf
> appropriately, I was able to get the servlet mappings for the
> context I added to work.
>
> One thing to note, Tomcat for NT is not picky about this, because on
> my NT deployment of Tomcat, I have the WEB-INF directory named
> "web-inf" and everything works fine.
[ ... ]
You must come from a Windows background :-) -- under UNIX, everything
has always been case-sensitive. And on Windows, it generally isn't.
Although I thought I saw some Tomcat-related documentation that
indicated that Tomcat is, or is going to be, case-sensitive on all
platforms. Maybe that's for 4.0.
Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu
Re: Session problem -- sessions being recreated, browser related?
Posted by Milt Epstein <me...@uiuc.edu>.
On Tue, 3 Apr 2001, Jeff Kilbride wrote:
> Hi Milt,
>
> Are you using ajp12 or ajp13 as your connector protocol? Apparently,
> ajp13 has known bugs that cause dropped sessions.
>
> I got this from Mike Slinn after visiting his site
> (http://tomcat.mslinn.com) and noticing that he said "Tomcat v3.2.1
> works better with this [AJP12] connector than with AJP13" in his
> server.xml explanation. I sent him an email to ask him why and he
> replied "ajp13 has bugs that cause dropped sessions."
>
> If this is true, I'm surprised it's not more widely known. The docs
> talk about ajp13 being much faster due to it's connection re-use, so
> obviously it was my first choice. I'm not using sessions anywhere,
> yet, but if I do I'm going to implement ajp12 instead of ajp13. I'd
> be really interested to find out if this is the cause of your
> problems.
Thanks for the response. I'm using mod_jserv, which means ajp12
(ajp13 is only available with mod_jk). So I guess that can't be the
cause of my problems.
I don't think it's anything so complicated as dropped sessions. I
think it just has something to do with the cookie handling that is
getting screwed up. Like apache/tomcat not getting the session cookie
back, so it thinks there's no session. (And recall that this is
something that was apparently working fine a few weeks ago when we
were using NES/ServletExec, so that restricts how general a problem
this is somewhat.)
> ----- Original Message -----
> From: "Milt Epstein" <me...@uiuc.edu>
> To: <to...@jakarta.apache.org>
> Sent: Tuesday, April 03, 2001 1:06 PM
> Subject: Session problem -- sessions being recreated, browser related?
>
>
> >
> > On a servlet-based application I have, I'm getting sporadic reports of
> > problems from users. The symptoms are similar to what happens when
> > cookies are disabled (but they aren't, because I had the users check).
> > Basically, they can't get past the front page of the application,
> > because it won't let them without a valid session (recall that session
> > access is handled via cookies -- I'm not using URL Rewriting). And
> > each time they try, Tomcat is creating a new session for them (and
> > giving them a new cookie). Apparently, it's not recognizing the
> > existing session.
> >
> > Now, this is only happening to a small subset of the users. I haven't
> > isolated a pattern yet, but it may only be happening from certain
> > machines. And the couple of machines I have found the problem on so
> > far are both using Internet Explorer version 4.0. So that might be a
> > factor. (I don't have 4.0 myself, but I did find an old copy of 3.02,
> > and it works OK with that.)
> >
> > Oh, a bit of background -- we switched over from using Netscape
> > Enterprise Server and ServletExec to Apache/Tomcat a couple of weeks
> > ago, and the problem seems to have only started occurring since then.
> > So it does appear to be something Apache/Tomcat-specific.
> >
> > Thanks.
> >
> > Milt Epstein
> > Research Programmer
> > Software/Systems Development Group
> > Computing and Communications Services Office (CCSO)
> > University of Illinois at Urbana-Champaign (UIUC)
> > mepstein@uiuc.edu
> >
>
Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu
Re: Session problem -- sessions being recreated, browser related?
Posted by Jeff Kilbride <je...@kilbride.com>.
Hi Milt,
Are you using ajp12 or ajp13 as your connector protocol? Apparently, ajp13
has known bugs that cause dropped sessions.
I got this from Mike Slinn after visiting his site
(http://tomcat.mslinn.com) and noticing that he said "Tomcat v3.2.1 works
better with this [AJP12] connector than with AJP13" in his server.xml
explanation. I sent him an email to ask him why and he replied "ajp13 has
bugs that cause dropped sessions."
If this is true, I'm surprised it's not more widely known. The docs talk
about ajp13 being much faster due to it's connection re-use, so obviously it
was my first choice. I'm not using sessions anywhere, yet, but if I do I'm
going to implement ajp12 instead of ajp13. I'd be really interested to find
out if this is the cause of your problems.
Thanks,
--jeff
----- Original Message -----
From: "Milt Epstein" <me...@uiuc.edu>
To: <to...@jakarta.apache.org>
Sent: Tuesday, April 03, 2001 1:06 PM
Subject: Session problem -- sessions being recreated, browser related?
>
> On a servlet-based application I have, I'm getting sporadic reports of
> problems from users. The symptoms are similar to what happens when
> cookies are disabled (but they aren't, because I had the users check).
> Basically, they can't get past the front page of the application,
> because it won't let them without a valid session (recall that session
> access is handled via cookies -- I'm not using URL Rewriting). And
> each time they try, Tomcat is creating a new session for them (and
> giving them a new cookie). Apparently, it's not recognizing the
> existing session.
>
> Now, this is only happening to a small subset of the users. I haven't
> isolated a pattern yet, but it may only be happening from certain
> machines. And the couple of machines I have found the problem on so
> far are both using Internet Explorer version 4.0. So that might be a
> factor. (I don't have 4.0 myself, but I did find an old copy of 3.02,
> and it works OK with that.)
>
> Oh, a bit of background -- we switched over from using Netscape
> Enterprise Server and ServletExec to Apache/Tomcat a couple of weeks
> ago, and the problem seems to have only started occurring since then.
> So it does appear to be something Apache/Tomcat-specific.
>
> Thanks.
>
> Milt Epstein
> Research Programmer
> Software/Systems Development Group
> Computing and Communications Services Office (CCSO)
> University of Illinois at Urbana-Champaign (UIUC)
> mepstein@uiuc.edu
>
Re: Session problem -- sessions being recreated, browser related?
Posted by Dave Ferguson <df...@touchnet.com>.
Hi Milt,
I've been testing Tomcat recently and found something similar. Like you, I was successfully using ServletExec and switched to Apache/Tomcat. Suddenly sessions were getting lost for no apparent reason. It was happening for all browsers, not just IE 4 and it was happening on both Tomcat 3.1 and 3.2.2b3.
I finally figured it out. It was because Tomcat and ServletExec return different things for request.getServerName(). In my case, I had an initial JSP which did a request to a controller servlet (Model 2). The controller servlet called sendRedirect( someURL ), where "someURL" was constructed (in part) by called req.getServerName(). I happened to access the first JSP with http://localhost/, which means the cookie was set with "localhost" as the server name. Well, Tomcat does some sort of DNS lookup because it returned "name.domain.com" for getServerName(), not "localhost". Thus calling sendRedirect() with a different server name caused the browser to NOT send the cookie and thus the previous session was lost.
The same behavior results if you access the first JSP with the IP address. The problem goes away if you access the first JSP with "name.domain.com". Thought I'd share my experience. Maybe that is what's happening to some of your users.
Dave F.
Milt Epstein wrote:
> On a servlet-based application I have, I'm getting sporadic reports of
> problems from users. The symptoms are similar to what happens when
> cookies are disabled (but they aren't, because I had the users check).
> Basically, they can't get past the front page of the application,
> because it won't let them without a valid session (recall that session
> access is handled via cookies -- I'm not using URL Rewriting). And
> each time they try, Tomcat is creating a new session for them (and
> giving them a new cookie). Apparently, it's not recognizing the
> existing session.
>
> Now, this is only happening to a small subset of the users. I haven't
> isolated a pattern yet, but it may only be happening from certain
> machines. And the couple of machines I have found the problem on so
> far are both using Internet Explorer version 4.0. So that might be a
> factor. (I don't have 4.0 myself, but I did find an old copy of 3.02,
> and it works OK with that.)
>
> Oh, a bit of background -- we switched over from using Netscape
> Enterprise Server and ServletExec to Apache/Tomcat a couple of weeks
> ago, and the problem seems to have only started occurring since then.
> So it does appear to be something Apache/Tomcat-specific.
>
> Thanks.
>
> Milt Epstein
> Research Programmer
> Software/Systems Development Group
> Computing and Communications Services Office (CCSO)
> University of Illinois at Urbana-Champaign (UIUC)
> mepstein@uiuc.edu
Re: Session problem -- sessions being recreated, browser related?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 3 Apr 2001, Milt Epstein wrote:
>
> On a servlet-based application I have, I'm getting sporadic reports of
> problems from users. The symptoms are similar to what happens when
> cookies are disabled (but they aren't, because I had the users check).
> Basically, they can't get past the front page of the application,
> because it won't let them without a valid session (recall that session
> access is handled via cookies -- I'm not using URL Rewriting). And
> each time they try, Tomcat is creating a new session for them (and
> giving them a new cookie). Apparently, it's not recognizing the
> existing session.
>
> Now, this is only happening to a small subset of the users. I haven't
> isolated a pattern yet, but it may only be happening from certain
> machines. And the couple of machines I have found the problem on so
> far are both using Internet Explorer version 4.0. So that might be a
> factor. (I don't have 4.0 myself, but I did find an old copy of 3.02,
> and it works OK with that.)
>
> Oh, a bit of background -- we switched over from using Netscape
> Enterprise Server and ServletExec to Apache/Tomcat a couple of weeks
> ago, and the problem seems to have only started occurring since then.
> So it does appear to be something Apache/Tomcat-specific.
>
One potential behavior difference might be in how the session cookies are
generated. Tomcat sets the path of the cookie to be equal to the context
path of the web application to which this cookie belongs -- I don't know
if NES and ServletExec do that. If they don't, you might see the same
session cookie come back in on a URL that is not really part of the same
webapp, where that would *not* happen with Tomcat.
A potential client-side issue can happen if you have two context paths
with one being the proper prefix of another (i.e. "/foo" and
"/foo/bar" both being webapps). If a user has sessions in both, then
*two* session cookies will be included on requests received by the
/foo/bar webapp. Tomcat relies on the client to follow the RFC rules and
list the cookie for the longer path first (since there is no other way to
distinguish the two). You might want to put a network trace on and make
sure your clients really do that, if you have webapps like this.
> Thanks.
>
> Milt Epstein
> Research Programmer
> Software/Systems Development Group
> Computing and Communications Services Office (CCSO)
> University of Illinois at Urbana-Champaign (UIUC)
> mepstein@uiuc.edu
>
>
Craig McClanahan
Session problem -- sessions being recreated, browser related?
Posted by Milt Epstein <me...@uiuc.edu>.
On a servlet-based application I have, I'm getting sporadic reports of
problems from users. The symptoms are similar to what happens when
cookies are disabled (but they aren't, because I had the users check).
Basically, they can't get past the front page of the application,
because it won't let them without a valid session (recall that session
access is handled via cookies -- I'm not using URL Rewriting). And
each time they try, Tomcat is creating a new session for them (and
giving them a new cookie). Apparently, it's not recognizing the
existing session.
Now, this is only happening to a small subset of the users. I haven't
isolated a pattern yet, but it may only be happening from certain
machines. And the couple of machines I have found the problem on so
far are both using Internet Explorer version 4.0. So that might be a
factor. (I don't have 4.0 myself, but I did find an old copy of 3.02,
and it works OK with that.)
Oh, a bit of background -- we switched over from using Netscape
Enterprise Server and ServletExec to Apache/Tomcat a couple of weeks
ago, and the problem seems to have only started occurring since then.
So it does appear to be something Apache/Tomcat-specific.
Thanks.
Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu