On 14/01/2010 23:45, youngm wrote:
* It would seem that the change tracking of a process like that above would
be very difficult. It would be hard to answer questions like "What patches
have I applied to these 20 applications in production?" If there were
simply a folder with the patches right there then it becomes very easier to
see how this running application's configuration differs from the
configuration the archive was built with. This becomes more and more
important the older an application gets and the more patches applied to it.
I think there's a fundamental misunderstanding here.
In some environments it is possible to load application code, followed
by patch code which replaces sections of the previously loaded code.
Thus the environment may load multiple versions of the same code, in a
particular order.
A running JVM is not one of those environments AFAIK. (Because, amongst
other reasons, you can't specify the load order of classes/jars in a
given classloader.)
The concept of sequential patching isn't something that can be readily
applied to deployed Java web applications. This is something better
achieved prior to deployment, e.g. in a source code repository.
If you have multiple versions of the same class in the classloader tree
you *will* experience problems at some point. We frequently see
problems here caused by duplicate jars and classes.
You seem to acknowledge that different servlet containers exhibit
different behaviour here, which makes the whole scheme you're proposing
even more fragile.
Your idea might /seem/ like a good solution, but it is a square peg in a
round hole.
People vastly more experienced than me are suggesting things to you that
they think are a better solution. Listen to them.
p
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
