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
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
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.