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

[Steve Ebersole]

On May 22, 2012 9:43 AM, "David M. Lloyd" <david.lloyd at redhat.com> wrote:
>
> 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.

One thing that makes me nervous here is that Hibernate would hold on to
these classloaders until the SessionFactory is closed (technically until
its BootstrapServiceRegistry is released).  Couldn't this present a problem
in terms of classloader leaking in cases where the application is managing
the SessionFactory lifecycle and the SessionFactory is not closed?

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

Do you mean a product of all possible combinations of Hibernate modules?  I
personally dont think that is the best representation.  At best, where the
possibility set is known up front (aka there are no custom user modules),
it seems wasteful to define so many modules; though perhaps there is not
any real practical problem with that. Worst case though there might be
custom user modules involved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20120522/694f36be/attachment.html