[jboss-as7-dev] Module Compatible Classloading Guide

[Jason T. Greene]

On 4/8/11 8:33 AM, Scott Marlow wrote:
> "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?


We only have to ensure that on components that we control the lifecycle 
of (so EJBs, Servlets, etc). Those threads are always our threads. If 
someone creates a thread to act as a client, then the resulting server 
invocation will have TCCL set by our invocation layer.

>
> 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."

I corrected that shortly after I posted. It now says:

"the defining classloader is not the right classloader, then look for a 
way to get the right loader and use it to load classes. Even if you have 
an inheritance model with a hierarchy that sees the classes you want, it 
is always more correct to pick the classloader that "owns" the classes."

In other words, there are no easy shortcuts, you ultimately need to have 
a design which has an accurate way to find a classloader. There are many 
possibilities that I don't go into, but they including looking it up by 
module name, change apis to allow for passing a classloader etc.

>
> 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.

If you are doing this you are not an EE application executing in an EE 
context, so the TCCL bit doesn't apply. Everything else does though.

>
> 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).

You can pass objects and class instances without having the classes in 
your classloader (else you would never be able to invoke JDK methods). 
So unwrap has no need for the app to see hibernates internal classes.

The only thing that should ever be exported is anything that an app 
would directly reference via an import/ or a 
Class.forName/ClassLoader.loadClass call. This should only ever be API 
classes. We should never export internal implementation classes.


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.

Yeah I don't talk a lot about jboss-modules and how to use it. I will 
add some stuff over time for that.

> 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:
>> I created an initial version of a guide on how to use class loading
>> correctly in a modular classloading environment like in AS7.
>>
>> Everyone that is writing AS7 code should review it. If you have any
>> questions ask and I will clarify it in the document.
>>
>> http://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Jason T. Greene
JBoss, a division of Red Hat