Classpath order within a deployer (to support evil hacks)

[bob.mcwhirter]

I'd like to "patch" a dependency of my deployer by providing a replacement class earlier in the classloader than the original .jar.

ie:

jboss-rails.deployer/
 jboss-rails.jar # includes my patched org.apache.cxf.staxutils.StaxUtils
 cxf-commons.jar # includes the original version

Right now, I think my jboss-rails.jar comes after cxf-commons.jar, as my replacement class is not used. I'd like to ensure that my jar is first/earlier in the search process. I could probably "solve" this by naming my patch jar "aaaaa.jar" but that seems a little bit awkward.

Don't focus on CXF vs jbossws. Being able to "hot patch" classes through classloader search-order control would be awesome, generally speaking.

Thanks,

-Bob

[alesj]

A quick idea.

What about if you provide jboss-structure.xml,
listing your patch before cfx?

[bob.mcwhirter]

Good thought, I'll give that a try and report back.

-Bob

[bob.mcwhirter]

Ales--

Thanks, that answer was perfect. This jboss-structure works exactly how I want it to:

<?xml version="1.0" encoding="UTF-8"?>
<structure>
 <context>
 <path name=""/>
 <metaDataPath>
 <path name="META-INF"/>
 </metaDataPath>
 <classpath>
 <path name="lib/jboss-rails.jar"/>
 <path name="lib/" suffixes=".jar" />
 </classpath>
 </context>
</structure>

Thanks!

-Bob

[bob.mcwhirter]

Plus, an educational blogpost about it:

http://oddthesis.org/posts/2009-02-jboss-microcontainer-enables-the-good-sort-of-evil

-Bob

[alesj]

I guess this way you'll get duplicated jboss-rails.jar entry.
But if you rename it to jboss-rails.zip you'll be fine. :-)

Not that it matters, just a simply glitch that popped my mind.
Or I'll have a look if I can avoid this duplicates with an impl detail. ;-)

[alesj]

"alesj" wrote:
I guess this way you'll get duplicated jboss-rails.jar entry.
But if you rename it to jboss-rails.zip you'll be fine. :-)

Or put it into diff dir.
e.g. hack/jboss-rails.jar :-)