JBoss classpath/classloader questions

[rziegler721]

Hi, please let me know if I'm in the wrong place.

QUESTION: Is it possible to use a classpath or classloader setting to load jars from a location outside our app's deployed war WEB-INF/lib location, but AFTER the app's WEB-INF/lib jars have already been loaded?

BACKGROUND: Our company has an enterprise app distributed as a war file that's running great when deployed to JBoss 4.2.2. As seems standard with web apps, we include several 3rd party and internally written jars under WEB-INF/lib, and life is good.

This war file is our 'standard' app that most of our clients will get, but we have decided to give clients the ability to create their own 'custom' logic (jar files) using our API that they could use along with our standard app.

The only deployment solution folks have come up with for this custom jar has been to just put it under WEB-INF/lib along with the other jars, and bounce the app server so it can be seen. This seems like a simple enough solution, but the next time a new standard war file is deployed, that WEB-INF/lib would get cleaned up, and someone would have to manually put the custom jar back in place under WEB-INF/lib again since they're not part of our standard war file.

We don't want to package the custom jars in our standard war file, since we don't want to maintain custom war files, and clients could change their jars on their schedule, so we'd never be in synch anyway.

The catch is that this custom jar is dependent on much of the logic contained in the other 3rd party and internal jars (import statements, etc), and any classpath settings I've tried look like they're loading this jar BEFORE the others, which won't work because of it's dependencies, and we just get the 'ClassDefNotFound' errors in the app.

I've tried several locations to put this custom jar, including -- server/XXX/lib, server/XXX/endorsed (with the -D arg pointing to the endorsed location), JBOSS_HOME/lib, and using the JBOSS_CLASSPATH variable, but none of them seem to do what I'd like.

I'm a Configuration Mgr (not a Java developer), so a lot of the documentation I've found on the wiki relating to classpaths/classloading is above my head...

Is what I'm trying to do possible, given the custom jars dependencies?

The system in question is JBoss 4.2.2 on Solaris 10, but we also run JBoss on Linux, Windows, and AIX.

Thank you in advance for any assistance you may be able to provide, and let me know if there's any other info I can post.

[rziegler721]

Does anyone have any thoughts on this? Lots of views, but no replies :(

[peterj]

Why not deploy the WAR as an exploded directory? Then when an updated standard WAR is deployed, the custom JARs in WEB-INF/lib would not be overwritten.

[rziegler721]

But what if the old standard war file has files that are obsolete as of a newer war, and shouldn't be there once the new war is deployed? Aside from the custom jars, it could get messy to reconcile what should/shouldn't remain. I could easily script moving the custom jars out, deploying a standard war file, then moving the custom jars back in, but I'd rather not choose that as a solution. Any deployments at client sites (which would be outside of my control) would have to do something similar and would not necessarily have my scripts. We also have clients running WebSphere, which isn't as forgiving when you mess around at the filesystem level with the expanded war folders. I was hoping that using some sort of classloader/classpath would be a solution instead, but it's sounding like that's not easy or possible...

[peterj]

Leaving old JARs in the WEB-INF/lib directory would not be an issue - if those classes are not used then all the file is doing is taking up disk space.

Of course, that tactic fails if you do something like combine all of the classes in one.jar and two.jar into one-two.jar. Then you would have one.jar, two.jar and one-two.jar in WEB-INF/lib which is guaranteed to be a mess.

I imagine you could code up you own classloading to load the client's custom JAR file so that file could be located anywhere, but that seems like a lot of work and fairly error prone. Some kind of deployment strategy seems easier to me, even if it is that you supply your customers with a deployer (which could be a script file) that does what you mentioned.