Maybe would be best to spell out the architecture of my issue:
* At runtime, I add a group of jars to sun.misc.Loader$AppLoader containing some instrumentation using the addURL method, the code in these jars make reference to some jms classes. I also include jms.jar as part of this
* An EAR/WAR is loaded which is instrumented (bytecode modified) and make reference to the code in the jars put in the sun class loader. This WAR also has a jms.jar file - these classes are loaded into the JBoss "BaseClassLoader".
* The classes in the BaseClassLoader pick up the classes from the sun Class Loader just fine - evidently, the BaseClassLoader IS delegating to the
sun base Class Loader EVEN THOUGH it shows that it's parent is NOT the base loader (which I normally see), but instead the parent being
null indicating a native or boot loader.
* The problem comes when code in the sun loader is called by the code in the BaseClassLoader and the javax.jms.Session interface seems to be loaded into the BaseClassLoader from jms.jar in the WAR (self first? as it DID NOT delegate down to the sun Class Loader) and all comes
apart when a class impl for javax.jms.Session created in the BaseClassLoader is then cast to javax.jms.Session in the sun Class Loader and
because they were loaded in 2 different class loaders they are not considered the same class and we get a Class Cast Exception.
***** I want to either at runtime set the Classpath for the BaseClassLoader to my instrumentation classes which would resolve this issue OR
force ALL class loaders to delegate downstream to the jms.jar that I loaded in the sun AppClassLoader....