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
