Re: [jboss-as7-dev] Module Compatible Classloading Guide

"In Java EE code, the TCCL is always the classloader of the relevant deployment". How do/should our (toplevel) EE containers ensure that the TCCL is set to the deployment? How do we turn a naked thread into a managed thread? I'm a little confused about the following sentence (from section FRAMEWORKS, NEVER LOAD YOUR CLASSES FROM THE TCCL!!): "If the defining classloader is not the right classloader, then pick it and use it to load classes." One other concern about the frameworks section, applications are often providing their own frameworks and can hit the issues called out there (like hitting a brick wall). It might be worth adding another section that raises the issues that applications will hit with any naked threads that they create (hopefully not from an EE thread). As well as application code that also expects to use the AS7 infrastructure jars as they have in the past. About "What To Export/Expose", I'm thinking about how I abused this rule with the "org.hibernate" module (I'm still wondering if I should abuse this rule further by including more of the Hibernate jars that applications might want access to in the future). Some of the other Hibernate jars might be accessed through the EntityManager.unwrap(Class) feature (that is being discussed anyway). Also, it might be nice to call out how the as7/build/build.xml (module-def) contains the exact list of the jars copied into the particular module. As well as the magic that happens behind the scenes, when a module dependency is exported. About "How to deal with "Bad" dependencies". Maybe rename to "How to deal with CNFE caused by code that would of caused Jar hell problems if we didn't make you jump through hoops to fix". ;) Okay, my title suggestion isn't much better. Thanks, Scott On 04/07/2011 01:33 PM, Jason T. Greene wrote: