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

[David M. Lloyd]

On 05/22/2012 09:38 AM, Scott Marlow wrote:
> 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).

OK.

>>
>>> 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).

I don't think we'll require any such changes regardless, from what Steve 
was saying.

> 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.

Right, that's the intent.  Just to be extra-clear, in this case the TCCL 
is *not* used (even though there may be implicit simple [non-exporting, 
non-service] imports [to the deployment's class loader] of the Hibernate 
component modules as a result) and instead it's the ClassLoaderService 
stuff that Steve talked about.

-- 
- DML