j_security_check and RequestDispatcher forward
Hi, I am using a servlet to intercept form based authentication in order to insert attribute into the request and then to redirect the request to j_security_check using RequestDispatcher. But I'm getting a 404 page with the following error: type Status report message /myApp/j_security_check description The requested resource (/MyApp/j_security_check) is not available. If I'm going directly to /MyApp/j_security_check using my browser - j_security_check is found Here is the code snippet: String params = j_username= + request.getParameter(j_username) + j_password= + request.getParameter(j_password); String encodedSecurityURL = response.encodeRedirectURL(/j_security_check? + params); RequestDispatcher dispatcher ; dispatcher = getServletContext().getRequestDispatcher(encodedSecurityURL); dispatcher.forward( request, response); Does anyone know why the code does not work but the direct call using the browser does work? Regards, Chen Paz
RE: j_security_check and RequestDispatcher forward
From: Chen Paz [mailto:chen@expand.com] Subject: j_security_check and RequestDispatcher forward I am using a servlet to intercept form based authentication in order to insert attribute into the request and then to redirect the request to j_security_check using RequestDispatcher. I wouldn't expect that to work, due to the special handling requirements of j_security_check, in particular that the container remember the original request of the protected resource and replay it automatically when authentication is successful. What you might want to try is a filter rather than a servlet, and have the filter modify the j_security_check request when it comes through. (Not completely sure that's possible, either.) Another option is to use a ServletRequestListener to manipulate requests as needed. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: j_security_check and RequestDispatcher forward
Filter is not possible. AFAIK you can not use filter before j_security_check in Tomcat... -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Monday, August 15, 2011 4:50 PM To: Tomcat Users List Subject: RE: j_security_check and RequestDispatcher forward From: Chen Paz [mailto:chen@expand.com] Subject: j_security_check and RequestDispatcher forward I am using a servlet to intercept form based authentication in order to insert attribute into the request and then to redirect the request to j_security_check using RequestDispatcher. I wouldn't expect that to work, due to the special handling requirements of j_security_check, in particular that the container remember the original request of the protected resource and replay it automatically when authentication is successful. What you might want to try is a filter rather than a servlet, and have the filter modify the j_security_check request when it comes through. (Not completely sure that's possible, either.) Another option is to use a ServletRequestListener to manipulate requests as needed. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
Yes, the space before servlet is a copy/paste error.
I made the LogFormat additions to httpd.conf, set the mod_jk logging level to
debug and ran some additional tests.
The session id did appear in the access_log I generated:
2000-1-200-ap-1313413815567
In the mod_jk.log, I also noted several references to the session id, which are
included below. Please note that the original client request went to worker
tomcat7A, but subsequent requests were routed to tomcat7C
[Mon Aug 15 09:10:15.614 2011] [3275:1] [debug]
ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [Set-Cookie] =
[JSESSIONID=2000-1-200-ap-1313413815567]
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] service::jk_lb_worker.c (1118):
service sticky_session=1 id='2000-1-200-ap-1313413815567'
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug]
get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial
sessionid 2000-1-200-ap-1313413815567
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug]
get_most_suitable_worker::jk_lb_worker.c (1001): found best worker tomcat7C
(tomcat7C) using method 'Request'
You can see from the log snippets that .worker_name is not being appended
to the session as expected.
-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: Saturday, August 13, 2011 8:11 AM
To: users@tomcat.apache.org
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 12.08.2011 15:30, Lataxes, Karl wrote:
The jvmRoute's for both server.xmls are properly set to the worker names and
are not commented out. This was the first thing I verified.
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat7A
Engine name=Catalina defaultHost=localhost
jvmRoute=tomcat7C
Here are the settings in workers.properties (worker tomcat7A identical to
tomcat7C except for port, since both are running on the same server for
testing. In production, we will probably install them on separate boxes):
worker.list=loadbalancer,jkstatus
worker.tomcat7C.type=ajp13
worker.tomcat7C.host=host_name
worker.tomcat7C.port=4931
worker.tomcat7C.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat7A,tomcat7C
worker.loadbalancer.sticky_session=1
worker.jkstatus.type=status
OK
Here are the JkMount settings in mod_jk.conf:
JkMount /jkmanager/* jkstatus
JkMount / servlet/* loadbalancer
I hope the space before servlet is a copy and paste error and not in the
original config ...
Load balancing is working, but subsequent requests from a single client are
being routed to the other Tomcat instance despite sticky_session being set to
1.
OK, then maybe your cookie header is not OK. To debug:
- Add %{Cookie}i to the LogFormat you are using in Apache. It will log all
cookies. Check the values.
- Add %{JSESSIONID}C to the same LogFormat. It will log the value of the
JSESSIONID cookie found by the web server. Check the values.
- Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the setting
of the cookie (sending a cookie from the server to the client).
Probably of no use for you, since you seem to parse that info in some other way.
- Increase log level of mod_jk to debug or even trace (not in
production) and look at the log lines written when your client sends a request,
which isn't handled sticky.
Regards,
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot make war file as default app
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 G, On 8/12/2011 4:59 PM, exquisite wrote: Now when i renamed my war to ROOT.war and drop it in webapps folder (without any context in server.xml), it deploys fine for the first time as the root app (Creates a ROOT folder in webapps), but if i make any change to any of my jsps and drop the new ROOT.war file, it says its deploying ROOT.war but it does not pick the changes after restart. It keeps showing me the old jsp when i run. I tried with autoDeploy=true in Host config but there is no change. You shouldn't have to do anything strange to get this working. Tomcat's default configuration is to auto-deploy WARs and directories in the webapps/ directory and also to re-load them if they change. The only thing that can get out-of-sync is the Tomcat deployment descriptor (context.xml) that gets copied from the WAR file (or directory) into conf/[Service]/[Hostname]/[appname].xml. You will have to undeploy/deploy (or just delete the file) in order to update it. Do i have to manually delete the ROOT folder that tomcat creates, everytime before the fresh deployment? No, but it might be a good idea to completely shut-down Tomcat, delete the entire work directory as well as an exploded WAR directories in webapps/ and any files in conf/[Service]/[Host]. Then, start Tomcat normally and everything should run smoothly from there on out. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5JOWIACgkQ9CaO5/Lv0PAmsACgtCAzkxGLVfTIO9uQa552xpZd gQoAn2qOmcqxgc3WUSOTEp1MRIbvTCc+ =ASxn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: j_security_check and RequestDispatcher forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 8/15/2011 9:49 AM, Caldarale, Charles R wrote: From: Chen Paz [mailto:chen@expand.com] Subject: j_security_check and RequestDispatcher forward I am using a servlet to intercept form based authentication in order to insert attribute into the request and then to redirect the request to j_security_check using RequestDispatcher. I wouldn't expect that to work, due to the special handling requirements of j_security_check, in particular that the container remember the original request of the protected resource and replay it automatically when authentication is successful. What you might want to try is a filter rather than a servlet, and have the filter modify the j_security_check request when it comes through. (Not completely sure that's possible, either.) Another option is to use a ServletRequestListener to manipulate requests as needed. This may have changed in 7.0.x, but IIRC you can't intercept a request to j_security_check using a Filter... you'll have to use a Valve and make sure it fires before the authentication valve. Otherwise, the authenticator will have processed the request before your filter (or valve) gets a chance to do anything with it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5JRbUACgkQ9CaO5/Lv0PDTpQCdH/QKcJ/Eh1a6siRy4IRmBVmW jF4An0DS/yoxiY/32En6xv8BhS2tRhlu =hKm2 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Multiple contexts pointing to same WAR
I'd like to run the same web app at multiple paths in Tomcat 6, e.g. /foo1 - foo.war /foo2 - foo.war I was thinking of creating $CATALINA_BASE/conf/[enginename]/[hostname]/foo1.xml $CATALINA_BASE/conf/[enginename]/[hostname]/foo2.xml with different entries for database names etc. but having docBase point to the same war, e.g. /usr/share/foo/foo.war But documentation http://tomcat.apache.org/tomcat-6.0-doc/config/context.html in the docBase section seems to say that this won't give me autoDeploy functionality. How can do I this so I can make updates to the app without restarting Tomcat? Do I have to duplicate the WAR into foo1.war and foo2.war? Thanks, Johannes. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple contexts pointing to same WAR
On 15/08/2011 17:38, Johannes Ernst wrote: I'd like to run the same web app at multiple paths in Tomcat 6, e.g. /foo1 - foo.war /foo2 - foo.war I was thinking of creating $CATALINA_BASE/conf/[enginename]/[hostname]/foo1.xml $CATALINA_BASE/conf/[enginename]/[hostname]/foo2.xml with different entries for database names etc. but having docBase point to the same war, e.g. /usr/share/foo/foo.war But documentation http://tomcat.apache.org/tomcat-6.0-doc/config/context.html in the docBase section seems to say that this won't give me autoDeploy functionality. How can do I this so I can make updates to the app without restarting Tomcat? Do I have to duplicate the WAR into foo1.war and foo2.war? Try it an see what happens. If you don't get updates when the WAR changes, you can almost certainly get it working by via watched resources. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: j_security_check and RequestDispatcher forward
2011/8/15 Chen Paz chen@expand.com: Hi, I am using a servlet to intercept form based authentication in order to insert attribute into the request What parameter do you want to insert into the request ? I don't know, but maybe you can do the same with a custom realm Or, using by Spring Security - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple contexts pointing to same WAR
I will try that, thanks, and report back. If it works, will that create one ClassLoader for foo.war, or two (one per context?) On Aug 15, 2011, at 9:43, Mark Thomas wrote: On 15/08/2011 17:38, Johannes Ernst wrote: I'd like to run the same web app at multiple paths in Tomcat 6, e.g. /foo1 - foo.war /foo2 - foo.war I was thinking of creating $CATALINA_BASE/conf/[enginename]/[hostname]/foo1.xml $CATALINA_BASE/conf/[enginename]/[hostname]/foo2.xml with different entries for database names etc. but having docBase point to the same war, e.g. /usr/share/foo/foo.war But documentation http://tomcat.apache.org/tomcat-6.0-doc/config/context.html in the docBase section seems to say that this won't give me autoDeploy functionality. How can do I this so I can make updates to the app without restarting Tomcat? Do I have to duplicate the WAR into foo1.war and foo2.war? Try it an see what happens. If you don't get updates when the WAR changes, you can almost certainly get it working by via watched resources. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15.08.2011 17:09, Lataxes, Karl wrote:
Yes, the space before servlet is a copy/paste error.
I made the LogFormat additions to httpd.conf, set the mod_jk logging level to
debug and ran some additional tests.
The session id did appear in the access_log I generated:
2000-1-200-ap-1313413815567
So the session ID is wrong, it does not contain the trailing .tomcat7A
to allow sticky routing.
Whatever generates the session id doesn't generate a correct one which
supports stickyness. The session id doesn't look like a normal Tomcat
session id, so it seems something else is setting the JSESSIONID cookie,
like a custom sesion manager. You need to find that piece of code and
fix it (to append the jvmRoute to the id).
Regards,
Rainer
In the mod_jk.log, I also noted several references to the session id, which
are included below. Please note that the original client request went to
worker tomcat7A, but subsequent requests were routed to tomcat7C
[Mon Aug 15 09:10:15.614 2011] [3275:1] [debug]
ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [Set-Cookie] =
[JSESSIONID=2000-1-200-ap-1313413815567]
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] service::jk_lb_worker.c
(1118): service sticky_session=1 id='2000-1-200-ap-1313413815567'
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug]
get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial
sessionid 2000-1-200-ap-1313413815567
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug]
get_most_suitable_worker::jk_lb_worker.c (1001): found best worker tomcat7C
(tomcat7C) using method 'Request'
You can see from the log snippets that .worker_name is not being appended
to the session as expected.
-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: Saturday, August 13, 2011 8:11 AM
To: users@tomcat.apache.org
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 12.08.2011 15:30, Lataxes, Karl wrote:
The jvmRoute's for both server.xmls are properly set to the worker names and
are not commented out. This was the first thing I verified.
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat7A
Engine name=Catalina defaultHost=localhost
jvmRoute=tomcat7C
Here are the settings in workers.properties (worker tomcat7A identical to
tomcat7C except for port, since both are running on the same server for
testing. In production, we will probably install them on separate boxes):
worker.list=loadbalancer,jkstatus
worker.tomcat7C.type=ajp13
worker.tomcat7C.host=host_name
worker.tomcat7C.port=4931
worker.tomcat7C.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat7A,tomcat7C
worker.loadbalancer.sticky_session=1
worker.jkstatus.type=status
OK
Here are the JkMount settings in mod_jk.conf:
JkMount /jkmanager/* jkstatus
JkMount / servlet/* loadbalancer
I hope the space before servlet is a copy and paste error and not in the
original config ...
Load balancing is working, but subsequent requests from a single client are
being routed to the other Tomcat instance despite sticky_session being set
to 1.
OK, then maybe your cookie header is not OK. To debug:
- Add %{Cookie}i to the LogFormat you are using in Apache. It will log all
cookies. Check the values.
- Add %{JSESSIONID}C to the same LogFormat. It will log the value of the
JSESSIONID cookie found by the web server. Check the values.
- Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the setting
of the cookie (sending a cookie from the server to the client).
Probably of no use for you, since you seem to parse that info in some other
way.
- Increase log level of mod_jk to debug or even trace (not in
production) and look at the log lines written when your client sends a
request, which isn't handled sticky.
Regards,
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat war context path
Is this even possible with tomcat? On Thu, Aug 11, 2011 at 12:32 PM, Mohit Anchlia mohitanch...@gmail.com wrote: Currently when I deploy abc-SNAPSHOT-01.war I access is something like http://localhost:8080/abc-SNAPSHOT-01.war How can I change the context root such that I can access it as http://localhost:8080/abc? Problem is that abc-SNAPSHOT-01.war name could change with the build version change. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple contexts pointing to same WAR
On 15/08/2011 17:49, Johannes Ernst wrote: I will try that, thanks, and report back. If it works, will that create one ClassLoader for foo.war, or two (one per context?) Two. Always. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot make war file as default app
Thanks Chris, for your answers. My understanding was that tomcat figures out the changes in the re-deployed war file and starts to explode it in order to overwrite the existing exploded directories in order to serve the changes in war file. But it looks like it does not overwrite the exploded folders. I knew that deleting the work directory and webapps exploded directories before every deployment works without any problem. One easy solution i see is why not just use exploded directory structure for deployment instead of war file. Then it will solve my issue as i saw it working.. Just was curious to understand tomcat behavior with war files. Thanks to all for all your replies. -G From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Monday, August 15, 2011 8:21 AM Subject: Re: Cannot make war file as default app -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 G, On 8/12/2011 4:59 PM, exquisite wrote: Now when i renamed my war to ROOT.war and drop it in webapps folder (without any context in server.xml), it deploys fine for the first time as the root app (Creates a ROOT folder in webapps), but if i make any change to any of my jsps and drop the new ROOT.war file, it says its deploying ROOT.war but it does not pick the changes after restart. It keeps showing me the old jsp when i run. I tried with autoDeploy=true in Host config but there is no change. You shouldn't have to do anything strange to get this working. Tomcat's default configuration is to auto-deploy WARs and directories in the webapps/ directory and also to re-load them if they change. The only thing that can get out-of-sync is the Tomcat deployment descriptor (context.xml) that gets copied from the WAR file (or directory) into conf/[Service]/[Hostname]/[appname].xml. You will have to undeploy/deploy (or just delete the file) in order to update it. Do i have to manually delete the ROOT folder that tomcat creates, everytime before the fresh deployment? No, but it might be a good idea to completely shut-down Tomcat, delete the entire work directory as well as an exploded WAR directories in webapps/ and any files in conf/[Service]/[Host]. Then, start Tomcat normally and everything should run smoothly from there on out. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5JOWIACgkQ9CaO5/Lv0PAmsACgtCAzkxGLVfTIO9uQa552xpZd gQoAn2qOmcqxgc3WUSOTEp1MRIbvTCc+ =ASxn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
I wrote the code to generate the session id and add it as an HTTP header at the
recommendation of someone on the users list. The problem now is appending the
jvmroute to the generated session id in order to get session stickiness to
work. If there were some way for the servlet to retrieve the jvmRoute from
server.xml, I could append it to the session id and get it to work. I have
been looking online for a solution, but have been unable to find one.
-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: Monday, August 15, 2011 12:52 PM
To: users@tomcat.apache.org
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15.08.2011 17:09, Lataxes, Karl wrote:
Yes, the space before servlet is a copy/paste error.
I made the LogFormat additions to httpd.conf, set the mod_jk logging level to
debug and ran some additional tests.
The session id did appear in the access_log I generated:
2000-1-200-ap-1313413815567
So the session ID is wrong, it does not contain the trailing .tomcat7A
to allow sticky routing.
Whatever generates the session id doesn't generate a correct one which supports
stickyness. The session id doesn't look like a normal Tomcat session id, so it
seems something else is setting the JSESSIONID cookie, like a custom sesion
manager. You need to find that piece of code and fix it (to append the jvmRoute
to the id).
Regards,
Rainer
In the mod_jk.log, I also noted several references to the session id,
which are included below. Please note that the original client
request went to worker tomcat7A, but subsequent requests were routed
to tomcat7C
[Mon Aug 15 09:10:15.614 2011] [3275:1] [debug]
ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [Set-Cookie]
= [JSESSIONID=2000-1-200-ap-1313413815567]
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] service::jk_lb_worker.c
(1118): service sticky_session=1 id='2000-1-200-ap-1313413815567'
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug]
get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial
sessionid 2000-1-200-ap-1313413815567 [Mon Aug 15 09:10:18.495 2011] [3275:1]
[debug] get_most_suitable_worker::jk_lb_worker.c (1001): found best worker
tomcat7C (tomcat7C) using method 'Request'
You can see from the log snippets that .worker_name is not being appended
to the session as expected.
-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: Saturday, August 13, 2011 8:11 AM
To: users@tomcat.apache.org
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat
7.0.8
On 12.08.2011 15:30, Lataxes, Karl wrote:
The jvmRoute's for both server.xmls are properly set to the worker names and
are not commented out. This was the first thing I verified.
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat7A
Engine name=Catalina defaultHost=localhost
jvmRoute=tomcat7C
Here are the settings in workers.properties (worker tomcat7A identical to
tomcat7C except for port, since both are running on the same server for
testing. In production, we will probably install them on separate boxes):
worker.list=loadbalancer,jkstatus
worker.tomcat7C.type=ajp13
worker.tomcat7C.host=host_name
worker.tomcat7C.port=4931
worker.tomcat7C.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat7A,tomcat7C
worker.loadbalancer.sticky_session=1
worker.jkstatus.type=status
OK
Here are the JkMount settings in mod_jk.conf:
JkMount /jkmanager/* jkstatus
JkMount / servlet/* loadbalancer
I hope the space before servlet is a copy and paste error and not in the
original config ...
Load balancing is working, but subsequent requests from a single client are
being routed to the other Tomcat instance despite sticky_session being set
to 1.
OK, then maybe your cookie header is not OK. To debug:
- Add %{Cookie}i to the LogFormat you are using in Apache. It will log all
cookies. Check the values.
- Add %{JSESSIONID}C to the same LogFormat. It will log the value of the
JSESSIONID cookie found by the web server. Check the values.
- Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the setting
of the cookie (sending a cookie from the server to the client).
Probably of no use for you, since you seem to parse that info in some other
way.
- Increase log level of mod_jk to debug or even trace (not in
production) and look at the log lines written when your client sends a
request, which isn't handled sticky.
Regards,
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat war context path
On 15/08/2011 18:05, Mohit Anchlia wrote: Is this even possible with tomcat? In Tomcat 7.0: abc##SNAPSHOT-01.war abc##SNAPSHOT-02.war abc##SNAPSHOT-03.war abc##SNAPSHOT-04.war etc On Thu, Aug 11, 2011 at 12:32 PM, Mohit Anchlia mohitanch...@gmail.com wrote: Currently when I deploy abc-SNAPSHOT-01.war I access is something like http://localhost:8080/abc-SNAPSHOT-01.war How can I change the context root such that I can access it as http://localhost:8080/abc? Problem is that abc-SNAPSHOT-01.war name could change with the build version change. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15/08/2011 19:09, Lataxes, Karl wrote:
I wrote the code to generate the session id and add it as an HTTP header at
the recommendation of someone on the users list. The problem now is
appending the jvmroute to the generated session id in order to get session
stickiness to work. If there were some way for the servlet to retrieve the
jvmRoute from server.xml, I could append it to the session id and get it to
work. I have been looking online for a solution, but have been unable to
find one.
Try using JMX.
Look up the appropriate object (there are clues in the source of the
Manager app) and then retrieve the value of the appropriate attribute.
I would experiment with setting this value in the servlet.init() method.
p
-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: Monday, August 15, 2011 12:52 PM
To: users@tomcat.apache.org
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15.08.2011 17:09, Lataxes, Karl wrote:
Yes, the space before servlet is a copy/paste error.
I made the LogFormat additions to httpd.conf, set the mod_jk logging level
to debug and ran some additional tests.
The session id did appear in the access_log I generated:
2000-1-200-ap-1313413815567
So the session ID is wrong, it does not contain the trailing .tomcat7A
to allow sticky routing.
Whatever generates the session id doesn't generate a correct one which
supports stickyness. The session id doesn't look like a normal Tomcat session
id, so it seems something else is setting the JSESSIONID cookie, like a
custom sesion manager. You need to find that piece of code and fix it (to
append the jvmRoute to the id).
Regards,
Rainer
In the mod_jk.log, I also noted several references to the session id,
which are included below. Please note that the original client
request went to worker tomcat7A, but subsequent requests were routed
to tomcat7C
[Mon Aug 15 09:10:15.614 2011] [3275:1] [debug]
ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [Set-Cookie]
= [JSESSIONID=2000-1-200-ap-1313413815567]
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] service::jk_lb_worker.c
(1118): service sticky_session=1 id='2000-1-200-ap-1313413815567'
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug]
get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial
sessionid 2000-1-200-ap-1313413815567 [Mon Aug 15 09:10:18.495 2011]
[3275:1] [debug] get_most_suitable_worker::jk_lb_worker.c (1001): found best
worker tomcat7C (tomcat7C) using method 'Request'
You can see from the log snippets that .worker_name is not being
appended to the session as expected.
-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: Saturday, August 13, 2011 8:11 AM
To: users@tomcat.apache.org
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat
7.0.8
On 12.08.2011 15:30, Lataxes, Karl wrote:
The jvmRoute's for both server.xmls are properly set to the worker names
and are not commented out. This was the first thing I verified.
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat7A
Engine name=Catalina defaultHost=localhost
jvmRoute=tomcat7C
Here are the settings in workers.properties (worker tomcat7A identical to
tomcat7C except for port, since both are running on the same server for
testing. In production, we will probably install them on separate boxes):
worker.list=loadbalancer,jkstatus
worker.tomcat7C.type=ajp13
worker.tomcat7C.host=host_name
worker.tomcat7C.port=4931
worker.tomcat7C.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat7A,tomcat7C
worker.loadbalancer.sticky_session=1
worker.jkstatus.type=status
OK
Here are the JkMount settings in mod_jk.conf:
JkMount /jkmanager/* jkstatus
JkMount / servlet/* loadbalancer
I hope the space before servlet is a copy and paste error and not in the
original config ...
Load balancing is working, but subsequent requests from a single client are
being routed to the other Tomcat instance despite sticky_session being set
to 1.
OK, then maybe your cookie header is not OK. To debug:
- Add %{Cookie}i to the LogFormat you are using in Apache. It will log all
cookies. Check the values.
- Add %{JSESSIONID}C to the same LogFormat. It will log the value of the
JSESSIONID cookie found by the web server. Check the values.
- Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the
setting of the cookie (sending a cookie from the server to the client).
Probably of no use for you, since you seem to parse that info in some other
way.
- Increase log level of mod_jk to debug or even trace (not in
production) and look at the log lines written when your client sends a
request, which isn't handled sticky.
Regards,
Rainer
-
To unsubscribe, e-mail:
Re: Tomcat war context path
On Mon, Aug 15, 2011 at 12:17 PM, Pid p...@pidster.com wrote: On 15/08/2011 18:05, Mohit Anchlia wrote: Is this even possible with tomcat? In Tomcat 7.0: abc##SNAPSHOT-01.war abc##SNAPSHOT-02.war abc##SNAPSHOT-03.war abc##SNAPSHOT-04.war etc Sorry I don't follow. What do I need to do change such that I can use http://localhost:8080/abc/ instead of http://localhost:8080/abc-snapshort-.xx ? Currently you need to use the war file name in the context since that's how it gets deployed in webapps. On Thu, Aug 11, 2011 at 12:32 PM, Mohit Anchlia mohitanch...@gmail.com wrote: Currently when I deploy abc-SNAPSHOT-01.war I access is something like http://localhost:8080/abc-SNAPSHOT-01.war How can I change the context root such that I can access it as http://localhost:8080/abc? Problem is that abc-SNAPSHOT-01.war name could change with the build version change. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat war context path
Greetings, On Mon, Aug 15, 2011 at 3:39 PM, Mohit Anchlia mohitanch...@gmail.com wrote: Currently when I deploy abc-SNAPSHOT-01.war I access is something like http://localhost:8080/abc-SNAPSHOT-01.war How can I change the context root such that I can access it as http://localhost:8080/abc? Problem is that abc-SNAPSHOT-01.war name could change with the build version change. You could also bundle a META-INF/context.xml file which looks something akin to: ?xml version=1.0 encoding=UTF-8? Context path=/ / -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat war context path
On 15/08/2011 20:39, Mohit Anchlia wrote: On Mon, Aug 15, 2011 at 12:17 PM, Pidp...@pidster.com wrote: On 15/08/2011 18:05, Mohit Anchlia wrote: Is this even possible with tomcat? In Tomcat 7.0: abc##SNAPSHOT-01.war abc##SNAPSHOT-02.war abc##SNAPSHOT-03.war abc##SNAPSHOT-04.war etc Sorry I don't follow. Read Pid's e-mail again. Rename your WAR files as per his e-mail. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat war context path
On 15/08/2011 20:45, Jesse Farinacci wrote: Greetings, On Mon, Aug 15, 2011 at 3:39 PM, Mohit Anchliamohitanch...@gmail.com wrote: Currently when I deploy abc-SNAPSHOT-01.war I access is something like http://localhost:8080/abc-SNAPSHOT-01.war How can I change the context root such that I can access it as http://localhost:8080/abc? Problem is that abc-SNAPSHOT-01.war name could change with the build version change. You could also bundle a META-INF/context.xml file which looks something akin to: ?xml version=1.0 encoding=UTF-8? Context path=/ / No you can't. That config is invalid. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat war context path
From: Jesse Farinacci [mailto:jie...@gmail.com] Subject: Re: Tomcat war context path You could also bundle a META-INF/context.xml file which looks something akin to: ?xml version=1.0 encoding=UTF-8? Context path=/ / Pretty much wrong on all counts: 1) The path attribute is not allowed when the Context element is in META-INF/context.xml. 2) The path for the default webapp is not / (read the servlet spec or Tomcat doc). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15.08.2011 21:20, Pid wrote: On 15/08/2011 19:09, Lataxes, Karl wrote: I wrote the code to generate the session id and add it as an HTTP header at the recommendation of someone on the users list. The problem now is appending the jvmroute to the generated session id in order to get session stickiness to work. If there were some way for the servlet to retrieve the jvmRoute from server.xml, I could append it to the session id and get it to work. I have been looking online for a solution, but have been unable to find one. Try using JMX. Look up the appropriate object (there are clues in the source of the Manager app) and then retrieve the value of the appropriate attribute. I would experiment with setting this value in the servlet.init() method. Or, since you don't really need a jvmRoute but just something to add to the session id which is known by mod_jk, you can set a system property -DjvmRoute=tomcat7A etc. Then retrieve the value as a system property and add it to the session id, separated with a dot. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Get SSO ID on server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chema, On 8/12/2011 2:56 PM, Chema wrote: Why bother? As soon as the user logs out of one web application (for example, by invalidating the corresponding session if form based login is used), the user's sessions in all web applications will be invalidated. Any subsequent attempt to access a protected resource in any application will require the user to authenticate himself or herself again. Right. But the application requires than an administrator can expulse an user. It's a client requirement. How do you accomplish that? By doing this SSO sniff-and-kill-session thing? It seems more straightforward to expire a particular webapp's session explicitly and let the SSO expire along with it. So, I need to record all SSO sessions FYI, I made it using by JSESSIONIDSSO cookie and works fine Doesn't that mean you'll have to re-run the same query just to expire the sessions in the other webapps? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5JfTcACgkQ9CaO5/Lv0PAKZQCgnsSH7kzt62gdYvj0T0qjc7ES mcMAoJI36IqOKM39o/iRXj7xRblzKlWa =L/z6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl, On 8/15/2011 2:09 PM, Lataxes, Karl wrote: I wrote the code to generate the session id and add it as an HTTP header at the recommendation of someone on the users list. Not to open a whole can of worms, but why are you generating your own session ids? You don't like the format of the existing ids? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5Jfh8ACgkQ9CaO5/Lv0PD5UACgt4xmRqavb5Hk3gpZ+ihNxXV2 drgAn39ZqloIyCzBILV7Kw2hL8MTv/QJ =lq+C -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Why is the tomcat welcome page showing?
Hey all, In server.xml I have a Host section set up with a Context that has a path set to . I see in the logs that the webapp assigned to that path is indeed executing when I hit '/'. However the browser shows the Tomcat homepage. If you're seeing this page via a web browser, it means you've setup Tomcat successfully. Congratulations! Why is my webapp not showing in my browser? Do I have to set up a DocumentIndex type parameter like in Apache? How do I disable the ROOT context? Thanks, Carl Furst smime.p7s Description: S/MIME cryptographic signature ** MLB.com: Where Baseball is Always On - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Why is the tomcat welcome page showing?
To follow up on this.. I removed the ROOT folder from the webapps.. and it still shows up even when I have re-defined the default Context. Where does the welcome page get rendered? Thanks, Carl Furst -Original Message- From: Furst, Carl [mailto:carl.fu...@mlb.com] Sent: Monday, August 15, 2011 4:49 PM To: users@tomcat.apache.org Subject: Why is the tomcat welcome page showing? Hey all, In server.xml I have a Host section set up with a Context that has a path set to . I see in the logs that the webapp assigned to that path is indeed executing when I hit '/'. However the browser shows the Tomcat homepage. If you're seeing this page via a web browser, it means you've setup Tomcat successfully. Congratulations! Why is my webapp not showing in my browser? Do I have to set up a DocumentIndex type parameter like in Apache? How do I disable the ROOT context? Thanks, Carl Furst smime.p7s Description: S/MIME cryptographic signature ** MLB.com: Where Baseball is Always On - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Why is the tomcat welcome page showing?
From: Furst, Carl [mailto:carl.fu...@mlb.com] Subject: Why is the tomcat welcome page showing? In server.xml I have a Host section set up with a Context that has a path set to . Unfortunate that you choose to use the least desirable method of setting the default webapp. I see in the logs that the webapp assigned to that path is indeed executing when I hit '/'. However the browser shows the Tomcat homepage. Possibly browser caching, but also possible that your webapp isn't being deployed properly. How do I disable the ROOT context? You can't - there must always be a ROOT context; you have just chosen a poor (and conflicting) way to specify it. What you should be doing: 1) Tell us the version of Tomcat you're using. 2) Stop Tomcat. 3) Remove the existing ROOT directory from the Host appBase directory. 4) Rename your webapp to ROOT (or ROOT.war, if appropriate). 5) Remove the Context element from server.xml. 6) Remove the contents of Tomcat's work and temp directories. 7) Remove the ROOT.xml file (if it exists) from conf/Catalina/[host]. 8) Restart Tomcat. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Why is the tomcat welcome page showing?
Hi Charles, Thanks for taking the time to answer. I'm using Tomcat 6.0 on Solaris I understand it's not ideal, however, I have to work this way because of a framework built for a different platform. The deployment mechanisms are such that they don't deploy to ROOT. Anyway with you're inspiring words of webapp isn't being deployed properly got me going and rebuilding, killing the jdk and starting up again. Something got cleared and it's working again. Very much obliged, Carl Furst -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Monday, August 15, 2011 5:09 PM To: Tomcat Users List Subject: RE: Why is the tomcat welcome page showing? From: Furst, Carl [mailto:carl.fu...@mlb.com] Subject: Why is the tomcat welcome page showing? In server.xml I have a Host section set up with a Context that has a path set to . Unfortunate that you choose to use the least desirable method of setting the default webapp. I see in the logs that the webapp assigned to that path is indeed executing when I hit '/'. However the browser shows the Tomcat homepage. Possibly browser caching, but also possible that your webapp isn't being deployed properly. How do I disable the ROOT context? You can't - there must always be a ROOT context; you have just chosen a poor (and conflicting) way to specify it. What you should be doing: 1) Tell us the version of Tomcat you're using. 2) Stop Tomcat. 3) Remove the existing ROOT directory from the Host appBase directory. 4) Rename your webapp to ROOT (or ROOT.war, if appropriate). 5) Remove the Context element from server.xml. 6) Remove the contents of Tomcat's work and temp directories. 7) Remove the ROOT.xml file (if it exists) from conf/Catalina/[host]. 8) Restart Tomcat. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org smime.p7s Description: S/MIME cryptographic signature ** MLB.com: Where Baseball is Always On - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat war context path
Got it thanks! Will try that On Mon, Aug 15, 2011 at 12:54 PM, Mark Thomas ma...@apache.org wrote: On 15/08/2011 20:39, Mohit Anchlia wrote: On Mon, Aug 15, 2011 at 12:17 PM, Pidp...@pidster.com wrote: On 15/08/2011 18:05, Mohit Anchlia wrote: Is this even possible with tomcat? In Tomcat 7.0: abc##SNAPSHOT-01.war abc##SNAPSHOT-02.war abc##SNAPSHOT-03.war abc##SNAPSHOT-04.war etc Sorry I don't follow. Read Pid's e-mail again. Rename your WAR files as per his e-mail. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
