geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: replacing tomcat classes
Date Thu, 11 May 2006 18:43:22 GMT
That technique will only work for a limited set of use cases, and is  
very error prone.  The fundamental problem is you are moving a class  
from a node deep in the the class loader graph to the system class  
loader.  That means the class will only be able to see classes on the  
system class path.  Specifically, a servlet would not be able to see  
the javax.servlet.Servlet class :(


On May 11, 2006, at 11:26 AM, Paul McMahan wrote:

> It seems that you can override some of the jars in geronimo/lib by
> dropping a jar into geronimo/lib/ext.  As a test I recompiled a change
> into o.a.g.system.main.Daemon that became visible when I put the
> updated jar into that directory.  But using the same technique for a
> deployed webapp didn't have the same results,  presumably due to the
> deeper classloader structure in effect for stuff loaded from the
> repository (as David described earlier).  I agree it would be nice to
> have a directory whose contents trump all classloaders used for quick
> testing and "hotfixes" and such.  But I can sympathize with concerns
> that it may be abused and lead to instability.  I have wasted a good
> deal of time in the past chasing red herrings caused by jars I didn't
> realize were in jre/lib/ext :-)
> Paul
> On 5/11/06, Jeff Genender <> wrote:
>> Matt Hogstrom wrote:
>> >
>> >
>> > David Jencks wrote:
>> >>
>> >> On May 11, 2006, at 8:29 AM, Joe Bohn wrote:
>> >>
>> >>>
>> >>> Thanks for the quick response Jeff.
>> >>>
>> >>> I like the idea of a "system patch" location in the classpath  
>> where
>> >>> we can pick up patches for anything we might include in a  
>> geronimo
>> >>> assembly.
>> >>
>> >> I think this "system patch" idea will only work in environments  
>> with
>> >> only one classloader, i.e. not geronimo.  The problem is that the
>> >> patched classes need to get into the correct classloader,  
>> "before" the
>> >> normal versions.   We'd need a patch directory for each module.  I
>> >> also think any solution that relies on the order of stuff in a
>> >> classpath is inherently unstable and unreliable.
>> >
>> > I agree that it would be very unwieldy.  For some folks providing
>> > support for Geronimo it might be nice for the classloaders to  
>> look in an
>> > aside dir (./patches) for a jar with the artifact name with a
>> > -pyyyymmddss suffix so patches can be applied.  The ss allows  
>> for the
>> > sequencing to be addressed.  This would make it easier to  
>> provide one
>> > hit patches that can get rolled up into the released jar you  
>> describe
>> > below and the user would not have to wait for a release to come out
>> > which could be a few months.
>> Matt, you hit the nail on the head.  I really think a simple patching
>> it..."quick hit" ;-) could have some big beneficial  
>> uses.
>>  I have many times run into this situation where I needed to be  
>> able to
>> do this.  Only through altering the CLASSPATH or changing the jar  
>> was I
>> able to get around the problem.   I always wanted a way to drop in  
>> a jar
>> w/o having to alter core services that allowed me to patch what I
>> needed. There are many use cases for this, with the biggest being a
>> possible way for us to release "service paks" w/o the need to  
>> download
>> and fully reconfigure a new server.
>> I only see this feature as an added extension to make thing easier  
>> for
>> development/support/and heavily configured prod servers.
>> Jeff

View raw message