geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul McMahan" <paulmcma...@gmail.com>
Subject Re: replacing tomcat classes
Date Thu, 11 May 2006 18:26:49 GMT
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 <jgenender@apache.org> 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
> system...call 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
>

Mime
View raw message