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

Scott Marlow smarlow at redhat.com
Tue May 22 10:38:54 EDT 2012


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.



More information about the jboss-as7-dev mailing list