You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2010/01/14 21:29:41 UTC
DO NOT REPLY [Bug 48547] New: Add hook for a "patch" classloader
https://issues.apache.org/bugzilla/show_bug.cgi?id=48547
Summary: Add hook for a "patch" classloader
Product: Tomcat 7
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: youngm@gmail.com
Occasionally it can be useful when administering an application running in
production to apply patches to that application rather than rebuilding that
application. Such situations might include upgrading the database driver for
an application that has an embedded driver, providing a patch to some spring
configuration, etc...
Other application servers have this capability. e.g. Websphere has the notion
of a "shared library".
It would be nice if tomcat had a similar concept. It could simply be a loader
that sits between the System loader and the webapp loader.
This loader could be configured in the catalina.properties along with the
common.loader. The "patch.loader"??? And could be blank/unused by default.
Some might argue that the correct way to handle this "patch" situation is to do
a new build of your web application. I argue that it's not Tomcat's job to
tell organizations how they run their IT but should instead work to be flexible
wherever feasible in allowing organizations to use Tomcat in such ways that
best fits that organization's processes.
Mike
--
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 48547] Add hook for a "patch" classloader
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48547
--- Comment #1 from Mike Youngstrom <yo...@gmail.com> 2010-01-14 12:43:41 UTC ---
As a work around people who have a similar need can modify the tomcat startup
scripts to add patched jars and classes folders to the "CLASSPATH" variable to
include them into the system classloader.
Mike
--
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 48547] Add hook for a "patch" classloader
Posted by bu...@apache.org.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 48547] Add hook for a "patch" classloader
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48547
--- Comment #3 from Mike Youngstrom <yo...@gmail.com> 2010-01-14 14:24:54 UTC ---
A few additional comments:
* This issue was not about runtime patching. I expect to need to restart my
tomcat.
* I don't believe the Shared classloader will work in this situation since
according to all the documentation and tests I've run the shared loader comes
after the webapp loader in class loading order.
* I have created a user thread and they were aware of no way to accomplish this
other than modifying the .war. I will continue to work on the user list to
gather more of a consensus before reopening this issue. For those with this
same question the thread can be found here:
http://old.nabble.com/Classloader-between-Web-application-and-system-loader-ts27154908.html
Thanks for your help Mark.
Mike
--
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org