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 <[EMAIL PROTECTED]> 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
