-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck,
On 2/26/12 11:29 PM, Caldarale, Charles R wrote: >> From: Aristedes Maniatis [mailto:amania...@apache.org] Subject: >> Re: parallel deployment: multiple applications responding > >> What happens if our application defines a static class or other >> resource? > > Not sure what you mean by "static class", unless you're referring > to an inner class. Regardless, each parallel deployment uses a > separate classloader, so the webapp instances cannot interfere > with each other. I'm sure he means a class with a static method that returns a shared object (aka singleton, etc.). > However, if you've placed classes in a shared library (e.g., > Tomcat's lib directory), anything in there will be shared by all > webapps. You must be very, very careful when utilizing shared > classes, since that can easily lead to unexpected data leakage > between webapps (not to mention often making it impossible to > undeploy them). Yes, but I would be very surprised if one could cause a different webapp to service a request by doing such a thing. What you might be able to do is get the request *logged* to the wrong webapp, if you were fetching references (say, to the ServletContext) and caching them in the (shared) class, then calling ServletContext.log on them. Aristedes, can you describe in a bit more detail the kinds of things you are doing, here? Also, what kind of logging are you using that suggests your requests are being handled by the wrong webapp? What does JMX have to say about the number of active sessions? (You said that the 'manager' webapp shows a status for the webapp, so you are probably using that session count in your reports, here, but I just wanted to check). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9LgbUACgkQ9CaO5/Lv0PBYoACfSFRbddQN1BNkBT5Q4GzhP2zA o4MAnRZVmV0mhFOj7Wu94JX76nbV9DFB =ugoA -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
