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 :(
-dain
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 <[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
