ClassLoading dependencies WAS: Re: [jboss-dev] How do you split your classes?

[Adrian Brock]

On Thu, 2008-09-04 at 11:47 +0200, Sacha Labourey wrote:
> Team,
> 
> I am interesting in better understanding how you take decisions when
> splitting classes between JARs. Let me be more accurate...
> 
> Ideally, each macro-service (Tomcat, WS, EJB3, etc.) would have its own
> MyService.sar file/directory in /deploy (or better, /deploy/system/). This
> SAR would contain all required implementation classes, services definition,
> etc. and would also list its dependencies in one of its jboss-services.xml
> <depends> tags. Then, if for some reasons this service needed to share some
> API classes with other services AND it was using some separate unified
> classloader, it could "pollute" the AS at large by putting these classes in
> the /lib folder of the AS. The outcome of this is that it would be very easy
> to remove a service: simply drop its folder from /deploy and that's it
> (modulo the potential pollution taking place in /lib).
> 

SERVICE DEPENDENCY IS NOT ENOUGH

It doesn't just need the <depends/>
since that only controls the create/start/stop/destroy lifecycle
which is why JBoss4 has no classloading dependencies.

> Now, we all know this is NOT how it happens in real-life. Hence, my
> question: WHY? What leads you to do things differently? I'd like to
> understand it better so we can potentially improve things.
> 
> It is worth mentioning that this is the pre-AS5 situation. With AS5 and its
> new classloaders à la OSGI, it is going to be possible to put EVERYTHING in
> specific directories in /deploy thanks to the import/export features Adrian
> has implemented. Consequently, outside of core services (specific deployers
> or any bootstrap code à la VFS, etc.), no JAR should be needed in /lib.
> 

CLASSLOADING DEPENDENCIES IN JBOSS 5

Yes. Your .xar should contain the packages (or bundles if you are lazy)
it imports and exports by including a META-INF/jboss-classloading.xml

The jboss-javaee.jar deployment would do:

<classloading xmlns="urn:jboss:classloading:1.0"
             name="JavaEE"
             version="5.0.0">

   <!-- exports -->
   <capabilities>
      <package name="javax.resource" version="1.5"/>
      <package name="javax.resource.work" version="1.5"/>
      <!-- etc. -->
   </capabilities>

</classloading>


Then jboss-jca.sar would do:

<classloading xmlns="urn:jboss:classloading:1.0"
             name="JBossJCA"
             version="5.0.0.GA">

   <!-- Doesn't really need to export anything? -->

   <!-- imports -->
   <requirements>
      <package name="javax.resource" version="1.5"/>
      <!-- etc. -->

      <!-- Lazy version -->
      <module name="JavaEE" version="5.0.0"/>
   </requirements>
</classloading>

What this does is make sure jboss-jca.sar doesn't
move to the ClassLoader stage of deployment
until jboss-javaee.jar has been deployed.

TRANSITIVE TO SERVICE DEPENDENCIES

Since this is before service construction,
it means anything depending on jca services
(e.g. the datasource) will have a transitive
dependency on jboss-javaee.jar

MULTIPLE VERSIONS

You might also notice that you
could actually deploy two different versions
of the classes/services in the same server,

But making that work properly, involves
changing the normal applications, ejbs/wars/etc.
to do explicit dependencies on the version
of the service they want to use.

This should be something done by our 
the relevant deployer
not left to users to try to figure out
and most likely get wrong. :-)

One easy mechamism for the later would
be for our containers to do "re-exports"
so the applications only have to
import the container's bundle.

ejb3 service

<classloading xmlns="urn:jboss:classloading:1.0"
             name="EJB30"
             version="5.0.0">

   <!-- ejb3 container exports here -->

   <!-- re-export our classloading dependencies -->
   <requirements>
      <module name="JavaEE" version="5.0.0" re-export="true"/>
      <!-- etc. -->
   </requirements>

</classloading>

ejb3 application (pseudo xml, actually
modification of ClassLoadingMetaData by the ejb3 deployers)

<classloading xmlns="urn:jboss:classloading:1.0">

   <requirements>
      <!-- This will also include the re-exported JavaEE:5.0.0 -->
      <module name="EJB30" version="5.0.0"/>
   </requirements>

</classloading>

> Thanks for your feedback. Cheers,
> 
> 
> 
> sacha
> 
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx