Using custom classloaders in JBoss

[coyotesqrl]

I'd like to be able to plug in custom classloaders for the UnifiedClassLoader architecture to use. It would be nice to plug in at the deployment level; however, it would be just fine if it were plugged in only at the LoaderRepository level.

It seems that the UnifiedClassLoaders could use a custom loader to do resource loading, and use that *same* resource loading mechanism to get classbytes before calling defineClass.

In other words, what I'm suggesting is that I be able to build a VERY simple classloader that just overrides findResource(). That method (in conjunction with a customer protocol handler if necessary) could do whatever was necessary to get the requested resource and decode it - access a database, decrypt bytes in an encrypted jar, etc. Then, UnifiedClassLoader3 could defer to that custom loader's implementation of findResource(). AND...when running findClass() it could first just call findResource() by munging the provided classname to be a resource name, get the bytes from the URL stream, and then call defineClass().

findResource() isn't going to give the same re-entrancy issues that findClass() does, so it shouldn't be a problem if UnifiedClassLoader were changed to work this way.

I've only looked at the UnifiedClassLoader architecture a little bit, so I'm not sure if this is a big change or a small one at this point. It's rather important to my organization to be able to do this, but I don't know whether I can get it done quickly enough. I also don't know whether this is functionality that the community wants to see included in JBoss.

So, I'm looking for some opinions from everyone (the UnifiedClassLoader authors being the most important) on desirability and expected difficulty. If it's desirable but more than I can bite off during my current contract, I wonder whether the authors would want to do it themselves, or if I should take it on on my own time.

-Richard Porter

[adrian.brock]

You can subclass to make this work.

Base your work on
UnifiedClassLoader3 (UCL) /UnifiedLoaderRepository3 (ULR)

You can change the ULR class using the system property
jbossmx.loader.repository.class

Be warned, the ULR has changed a lot since 3.0.0
and will probably change again in the future.
It is also quite complicated to workaround a
couple of bugs in the JVM.

If you have a good way that works generally post
a patch on www.sf.net/projects/jboss

Regards,
Adrian

[coyotesqrl]

I had looked at using subclasses of UCL3 a while back when trying to figure out the best way of (re)deploying things on the fly that weren't under JBoss and over which I wanted more control. I had a lot of trouble going down that route and decided it was a lot simpler and easier to just use ask the ULR to give me new UCLs when I needed them (or to deploy jars as the case may be).

While I could look at doing this again to handle our unique loading needs, it doesn't provide an all-around solution to the problem, merely a one-off for me and my company. Plus, as you point out, the loader and repository api is still in flux.

With my suggestion of a custom loader that is only defered to in order to find resources, api and implementation changes in the ULR and UCL architecture aren't as big a deal. I'd merely ask the LoaderRepository to create me a new UCL with the name of my classloader. Create a UCL4 or UCL5 and it shouldn't affect my custom loader and the way that it works.

-Richard Porter