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

[Thomas Diesler]

The standard (i.e. OSGi) works like this:

* There is an external ServiceRegistry that both the service provider 
and service consumer can depend on.
* The service producer binds a service instance typically using an API 
interface to the registry
* A service consumer has a class loading dependency (wire) on the API 
and uses the registry to do a lookup.
* Multiple service implementations are allowed with well defined 
ordering rules
* In contrary to jboss-modules, dependencies can be expressed at package 
level (version ranges are supported)
* Similar to jboss-modules, explicit dependencies are also supported 
(require bundle semantic) - discouraged!

If I understand correctly your current service lookup approach works 
well with a flat class space. It should hence be possible to come up 
with a simple service registry abstraction that can use an underlying 
OSGi registry, a jboss-msc layer or some other implementation. An 
initial registry impl that works with ServiceLoader is feasible. There 
is also a project that brings the OSGi service registry to non-osgi 
environments (i.e. without the modularity part)

For the module dependency part you could:

* Also use the standard (i.e. OSGi metadata in your jars) - this should 
then work in any OSGi runtime (felix, equinoix, virgo, etc), but also in 
a flat class space if the bundles can be treated as jars.
  * Please also note that today most appservers build on top of OSGi. 
Hibernate bundles would work in WebSphere, WebLogic, Glassfish, etc. out 
of the box. It would not work out of the box in AS7 however
* For AS7 Hibernate bundlescould be treated as as ordinary modules with 
their dependencies expressed in modules.xml

In future the distinction between modules/bundles should go away in AS7 
when we manage to align the lifecycle of module/bundle deployments.

In short - going with the standard is a viable option IMHO.

cheers
-thomas

On 05/09/2012 06:50 PM, Emmanuel Bernard wrote:
> 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
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx