Hello. I'm working with a framework that makes liberal use of singletons. This of course is not good in a web application context.
Normally the way you eliminate singletons if you can't update the source code is to make sure that the library that uses a singleton is loaded in its own classloader, since singletons are by definition in Java scoped to their classloader.
I have this solution working in Sun ONE application server, WebSphere and Weblogic. Not terribly surprisingly, I can't get it to work with JBoss. I was hoping someone had some experience here.
Briefly, if I create a ClassLoader whose URL list is dynamically expanded via the usual MANIFEST.MF Class-Path conventions, somehow the JBoss loader repository silliness gets in the middle. That is, instead of doing what every other application server under the sun does--namely letting the Manifest.MF Class-Path entries take precedence over parental delegation--JBoss seems to consult its loader repository for classes that are supposed to be loaded from the URLs present in the Manifest.
A simple example: a.jar refers to b.jar in its manifest. I create a URLClassLoader pointing at a.jar. It should be the case that any class present in b.jar loaded by a class in a.jar should be resolved properly. Instead, JBoss leaps in helpfully and attempts to use its loader repository to load b.jar's classes. For whatever reason, the manifest's Class-Path entries are not added to the loader repository, or at the very least the loader repository/UCL spit, glue, baling wire, twigs and axle grease can't see anything present in the Class-Path entries.
There is a related bug report in JIRA here: http://jira.jboss.com/jira/browse/JBAS-3086
Briefly, it looks like the URLs pulled in from manifests never make it into the loader repository? Does anyone have a workaround for this?
