https://issues.apache.org/bugzilla/show_bug.cgi?id=48547
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #2 from Mark Thomas <ma...@apache.org> 2010-01-14 12:53:32 GMT ---
Modifying CLASSPATH is generally a very bad idea. In 99.9% of cases it causes
far more problems that it fixes.
Another class loader in the hierarchy won't help due to the delegation model
required by the Servlet spec.
Regardless of how you do it, dynamically replacing classes in a running web
application is asking for trouble unless your are very careful or in an
environment designed to it (eg OSGI). Getting that right for Tomcat would
require a huge amount of complexity (it is bad enough for JSPs) and there are
simpler solutions.
Tomcat does support updating an entire WAR whilst the application is running
and serving requests. You need to do this through the manager for it to be
safe.
You can also add/replace classes in the WEB-INF/classes directory. These will
override and classes in JARs (hence can be used for patching) and a simple
re-load will cause Tomcat to pick them up, again without loss of service to the
end-user.
As an aside, Tomcat has had the concept of a shared library for as long as I
can remember (Tomcat 4 onwards). It is disabled by default in Tomcat 6 & 7.
All the use cases you describe can be achieved with existing Tomcat
functionality. Use the users list if you need more details of how to do it. If
there is a practical use case that can't be met with existing functionality
then that is worth further discussion. The users list is also the best place to
start that discussion.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
