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

[Scott Marlow]

On 05/22/2012 10: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).

When we have Hibernate API jars (Hibernate 5.x), we can look at allowing 
the deployment descriptor to specify the client api jars (to be injected 
into the application deployment).  Until then, we can inject the 
implementation jars instead, so that the native APIs can be used that 
are in the Hibernate jars.

For EE JPA deployments, we can also inject the Hibernate 
OGM/Search/Other Integrator classloader set into 
org.hibernate.cfg.AvailableSettings#INTEGRATOR_CLASSLOADER (as a set).

For nonEE-JPA/Hibernate applications to use Hibernate Search/OGM/Other 
Integrator implementations on AS7, introducing an AS7 deployment API 
that native applications could call to get the jboss-hibernate.xml 
specified dependencies (classloader set) sounds ugly but would be one 
implementation.  A cleaner way would be to have some type of Hibernate 
deployer that could deploy/start Native Hibernate applications (instead 
of application code handling that).

>
>>
>>> 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.
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev