Chris,

Thanks for getting back to me. I did end up solving the problem, and it was not a bug or related in any way to what Tomcat is doing. It ended up being a (very buried) property setting of the application that is not documented anywhere. A lot of grep-ing lead me to the realization. After setting the property, Tomcat behaves as expected and obeys the application's desired cookie name.

Thanks again for letting me bounce my ideas off you, much appreciated!

Cheers,

Brian Jones
Programmer/Analyst
Information Technology Services
Support Services Building, Suite 4300
Western University
(519) 661-2111 x86969
bjone...@uwo.ca

On 2015-04-29 05:18 PM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Brian,

On 4/21/15 3:21 PM, Brian Jones wrote:
Chris, thanks for getting back to me!

I'm trying to override the default cookie name (JSESSIONID) for
one of my Tomcat7 instances. I put the following in
$catalina_home/conf/context.xml:

<Context sessionCookieName="MyCookie">

That will change the session cookie name for all applications
deployed on the server, and not just one web application. Is that
what you wanted ?

Yes, this is what I'm after. I'm working on an enterprise
application which is comprised of over 70 webapps all working
together. I need to change it for everything, as they all obey a
single cookie.

However, after restarting Tomcat, the setting isn't being
applied; the cookie always remains as JSESSIONID rather than
MyCookie.

My environment is: tomcat 7.0.39, java 1.7.0_79, kubuntu
14.10.

Can anyone shed some light on how/where
$catalina_home/conf/context.xml is loaded? Or any ideas,
suggestions, etc are appreciated.

I would have expected what you did to work. Do you have a
separate CATALINA_BASE as well as a CATALINA_HOME? If so, the
CATALINA_BASE/conf/context.xml will *completely override* the one
in CATALINA_HOME/conf/context.xml.

I don't believe so, output from ./shutdown.sh:

Using CATALINA_BASE:   /opt/apache-tomcat-7.0.39 Using
CATALINA_OWL:   /opt/apache-tomcat-7.0.39 Using CATALINA_TMPDIR:
/opt/apache-tomcat-7.0.39/temp Using JRE_HOME:
/usr/lib/jvm/java-7-openjdk-amd64 Using CLASSPATH:
/opt/apache-tomcat-7.0.39/bin/bootstrap.jar:/opt/apache-tomcat-7.0.39/
bin/tomcat-juli.jar




It would probably be better to set the configuration in your web
application's META-INF/context.xml file. Give that a try and see
if it gives you the desired effect.

The problem with doing this, is that as the application is open
source, modifying each subtool's context.xml would fork me from the
community.

The only reason I'm trying to accomplish this, is because I have
two versions of the application running in two different Tomcats;
one is the community version, one is my institution's
localized/modifyied version. I need to be able to run both
simultaneously for comparison purposes.

However, because both Tomcats/applications are using the same
JSESSIONID as the cookie name, if I start a session on one Tomcat,
it invalidates the session on the other.

Anything else you can think of? Do you perhaps know how/where
Tomcat is loading up the $catalina_home/conf/context.xml file? If
that is known, I can perhaps modify (hack) it to point explicitly
to the context.xml file that I have the sessionCookieName set.

Sorry for the delayed response.

I just wanted you to try to configure using META-INF/context.xml to
see if that made the difference. That test will determine whether this
is a bug in Tomcat (the feature doesn't work) or if Tomcat does not
allow certain things to be overridden locally (e.g. the cookie name)
and therefore this is an enhancement.

I rather think that your expectations are reasonable, so assuming it's
not a bug, I'm +1 for supporting site-wide cookie-name changes.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVQUq/AAoJEBzwKT+lPKRYYroP/Ao8Vdb2eL5ExJruAZdS/xKt
dzd2pVn4UTFXc1Pl8j7ShmlnBgm9VK6ls8NyGQTtshsNjO0/NaYof6mrBgiwZdAU
cnZci10Oz1er3qLHY5kBC1gnWajba3pg37hMPYWvwLTNvypnPwpCotBAnzHRbDDO
rU+MoGwxyi54YgAF26ewC2WUd9dy8kbLZdBis3PfE+bVNt8Ao/iA+8u9vjFzOfRv
nYaY0HxnV8VbiE54kLTdmbBQtfA3YpTyzxNZCEb5XP0AZvhQazqUQSmw773UBW2c
p9ovKirJ1axahdMfqYQ12HWE7ajeiONU9Q3PatVjC5fy+/uNMiGKm77cq9gr6MGG
JDe+PTcNNpsKVwyz+h5RzjnJALrW1GuUaxMb5NhgRMEHK6Vgo37lmkN2Db4f494Q
WkFkdjV03+ylQ88M8M+s+ubDKNVmZ0WalJsQrhePa9Q3LjTD8W71jSe5IMJT2MwP
8SEP4o4MPORaH9BlJJVYHBVYHgfuFnhXV2zqaOKph1fTvuczKjuL9LXmOlpalNsv
N0FPo/1X4NkMGf2tNAO1UzF5xc/FMSllH6wuFKC3cmTHvxaqwUdcZeV0vWxbIo1c
HLwhCxCPaYDuA5xgIS3JCr1HXlXY1bAQHsCWCFwbcc1C73me5qAsF0UliEC9h5mZ
Sh0kPbkRrI0bJA6Kcm0v
=jK03
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
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

Reply via email to