::Bitten by the horrid JBoss classloader again:: [/tech/java] (09:57)

I am a big fan of JBoss, but anyone who is around me for 15 minutes will know that I'm no fan of the JBoss classloading strategy. Just this last week was bitten by the JBoss classloader and am going to have to do quite a bit of work to get the application back in a usable state.

I added a JMX layer to our application whereby MBeans from one subsytem would interact with MBeans from another system. It seemed to work rather well until we started running into the deployment order and class cast exceptions you get when you forget to protect yourself from the JBoss classloader. When I isolated all the subsystems, I suddenly realized the design flaw in the system. Passing objects from MBean to MBean by interface doesn't work unless those interfaces are shared. I'm not trying to deny my responsibility for the mess. It's all my fault, but I am frustrated by the insidious way that the default classloading methodology tricked me into thinking that everything would work.

That's why I thought the EJB 3.0 discussion at the TSS was interesting. Several people requested that the J2EE specs lay down the law on classloading. Peter and Colin were two of the people who raised concerns about classloading, especially the way JBoss abuses the lack of clarity in the J2EE spec with regard to classloading with EJBs.

JBoss Bill and JBoss Marc were there arguing for the JBoss classloader. I really hope to some day to corner one of these guys and get them to explain in person why they think the JBoss way is good because I can't figure out how anyone would think that the JBoss classloader was helping things.