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

On 05/22/2012 10:14 AM, David M. Lloyd wrote: > On 05/22/2012 09:10 AM, Scott Marlow wrote: >> >> On 05/21/2012 06:40 PM, Steve Ebersole wrote: >>> Hey all, just to tie this up with a bow I wanted to send my take away >>> from the discussions we had on IRC and make sure everyone had the same >>> take away. Jason and David, wanted to thank you guys again for your >>> time >>> and input. It really helped out. I also went ahead and copied/pasted >>> the >>> transcript so we had record of discussion. >>> >>> The basic idea is to control this via a specific deployment descriptor >>> (jboss-hibernate.xml or somesuch). >> >> My understanding is that this jboss-hibernate.xml is an optional >> deployment descriptor that would be used by a deployment (EE or non-EE) >> that wants to use any of the following technologies: >> >> * Hibernate Search >> * Hibernate OGM >> * Hibernate Integrator module implementation >> >> The result of including a jboss-hibernate.xml, would be that the >> deployment includes the needed Hibernate modules (Hibernate >> Search/OGM/other custom modules). >> >> If there is no jboss-hibernate.xml, there would be no change from >> current AS behaviour (OGM could be packaged with the application but >> cannot be used as a module like other persistence providers). > > It sounds like you're implying that a regular JavaEE application with no > JBoss-specific descriptors in it cannot use JPA. Is this correct? No, I didn't intend to imply that. I'll restate with fewer negatives. ;) I just meant that standard EE deployment will continue to work for Hibernate ORM as the persistence provider. JavaEE applications that contain zero JBoss-specific descriptors, can continue to use JPA. Hibernate OGM/Search/Other Integrator applications will need to have a JBoss-specific descriptor (either jboss-hibernate.xml or jboss-deployment-structure.xml).

> >> This in effect will allow Hibernate ORM to use the application >> deployment as a composite module that also contains the Hibernate >> Search/OGM/Other Integrator module implementation(s). > > That's fine assuming that we have JPA out of the box. > >> This might require some Hibernate ORM changes or not (depending on >> whether its service loader searches in the TCCL currently). We can >> probably use the jboss-deployment-structure.xml as an alternative (short >> term solution) before we have this new Hibernate deployer that looks for >> the presence of the jboss-hibernate.xml file. I think more discussion is >> needed about the contents of jboss-hibernate.xml before we can implement >> that. > > The rule could probably be, if there's a jboss-hibernate.xml then use > that to configure, else use TCCL. That should work in most cases (though > it might break if they bundle certain combinations of JARs; this should > be tested). It seems like the TCCL could be used in Hibernate 4.1.4 (which doesn't require changing Hibernate ORM).

Regarding the jboss-hibernate.xml, it sounds like the binary representation could be a set of static module classloader references based on the user carefully specifying which Hibernate technologies to use for the deployment to be used by the ORM service loader.