Hello, I don't know if there was a problem with that (I've seen a thread between Aaron and Juha about this argument). If there was, probably I found reason and solution; if there wasn't, then I'll say something that probably most of you already know, but that can be interesting for jBoss newbies like me :-) For those interested, I've (luckily) found a solution/workaround for the problem of ClassCastException: sun.misc.Launcher$AppClassLoader when jBoss starts and loads the ClasspathExtensions MBeans. My investigations found out that all the MBeans are loaded with sun.misc.Launcher$AppClassLoader if, when you run the server, the classpath points to the jboss.jar or to the directory were the class files are compiled to (usually build/classes). If, instead, the classpath points only to the jmxri.jar, the conf directory and the Main class inside run.jar (as is in run.bat), then the MBeans are loaded with the javax.management.loading.MLet classloader, and I was able to run and debug jBoss from inside the IDE (I'm using Kawa) from the start (i.e. without attaching the debugger to the process). I think the reason for this behavior is that the class loader (in our case MLet) delegates the loading of a class first to its parent class loader (Launcher$AppClassLoader), then if the parent does not find the class, tries itself to do the job. When there are the MBeans in its classpath, the parent class loader is able to load the MBeans and this cause the ClassCastException. BS
