9:29 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Jason T. Greene
JBoss, a division of Red Hat