[jboss-as7-dev] Modularity is the spawn of Lucifer and a stinking donkey

Emmanuel Bernard emmanuel at hibernate.org
Wed May 9 12:50:02 EDT 2012


Now that I have your attention, I'd like to discuss issues we are experiencing when trying to modularize the Hibernate portfolio and make it work in AS 7.1.

## Disclaimer

I perfectly understand all the coolness about modularity (speed, easier dependency isolation etc). I have also carefully read :

- https://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide
- https://community.jboss.org/wiki/ModularSerialization

But these tend to avoid the more complex cases of portable libraries that ought to run even outside AS 7 but have a wide variety of class and resource loading needs.
I am not a complete modularity bozo but I am definitely not familiar with JBoss Modules nor similar solution.

## Requirements / Landscape

Hibernate ORM uses the notion of service registry and integrator object that help during the integration or customization of the engine behavior by third-party frameworks.
Enlistment of Integrators is done via the service locator pattern (a service file in META-INF/services/ that is looked up and contain the implementation class(es) at stake.

Hibernate Envers is one of those customizer that depends on Hibernate ORM. Note that the core of Hibernate ORM does not depend on Hibernate Envers. The service locator file is contained in Hibernate Envers JAR.
Hibernate OGM likewise, heavily customizes ORM and depends on Hibernate ORM classes - the reverse is not true. The service locator file is contained in Hibernate OGM JAR.
Hibernate Search optionally depend on Hibernate ORM and JPA. The core of Hibernate Search is independent but an Hibernate Search ORM module has an integrator implementation. On top of that, Hibernate Search optionally depend on some JPA classes and behaves differently if they are there - we look them up in the classpath by reflection.

On top of that, these projects do load resources (config files, classes):

- from what Jason calls a Deployment classloader (the user application classes and resources really) - entities, custom analyzer implementations, resources files etc. A user could even write a custom Integrator and use the service locator pattern from his application.
- from direct dependencies (Lucene is a declared dependency of Hibernate Search)
- from dependencies of the deployment: for example an app developer adds the phonetic analyzer as a dependency of his application and ask Hibernate Search to use it
- from modules that use these projects. Modeshape and Capedwarf are being modularized and are making use of Hibernate Search as a module. Properly loading the necessary classes located in Modeshape or Capedwarf's module but from Hibernate Search's engine proves to be very hard in our current approach.

All of these projects should be able to run outside JBoss AS 7, so a modular friendly solution should somehow be abstracted and generic enough.

## What solution?

More and more projects are being modularized including ones with complex resource loading dependencies like the ones I have described. AFAIK Infinispan is even in a worse situation as clustering and late class binding is at stake but let's put this one aside. 
I'd love to get a reference design outcome from this thread that could be copied across all these projects and future ones like Bean Validation.

Today, we mostly use the good old and simple TCCL model which works fine if the jars are directly embedded in the app but fail the minute we start to move these dependencies into modules. Sanne, Strong, Scott Marlow and I are using dangerous amount of Advil to try and make everything work as expected. Some help would be awesome.

To sum up:

- can the Hibernate portfolio be supported within JBoss Module and how?
- what kind of ClassloaderService contract should we use within these projects to be modular friendly (JBoss Modules and others)?
- would such contract be generic enough to be extrapolated to JSRs in need of modular friendliness?
- how to solve the chicken and egg issue of the bootstrapping: if we need to pass a ClassloaderService impl? How do we do that best in a modular environment without forcing the application developer to implement such godforsaken ClassloaderService contract or even worse pass directly to us the right classloader for each call.

Thanks,

Emmanuel


More information about the jboss-as7-dev mailing list