[hibernate-dev] HHH-10307 - JTA dependency

[Gunnar Morling]

I'd prefer 1). The less dependencies I need, the better.

2016-01-06 18:36 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> I'll put it this way Gunnar, as a user would you prefer:
>
> 1) org.hibernate.Transaction#addCallback( org.hibernate.TransactionCallback
> )
> 2) org.hibernate.Transaction#addCallback( javax.transaction.Synchronization
> )
>
> ?
>
>
>
> On Wed, Jan 6, 2016 at 11:34 AM Steve Ebersole <steve at hibernate.org> wrote:
>>
>> The JTA API is a tiny jar.  I am not so concerned with "users working with
>> JDBC exclusively" being "surprised" that JTA is needed.  JTA's
>> Synchronization is a well understood pattern.
>>
>> On Wed, Jan 6, 2016 at 11:22 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>>
>>> I can see how users working with JDBC exclusively can be surprised by
>>> the fact that the JTA API is still needed. I think it boils down to
>>> these options:
>>>
>>> 1) Push back the need for JTA types to the case of actually using JTA
>>> (e.g. by splitting up the CoreMessageLogger interface etc.)
>>>
>>> In my experience classes (such as org.hibernate.Transaction) can be
>>> loaded also if they contain method signatures with absent types (e.g.
>>> registerSynchronization()), as long as these methods are not accessed
>>> (e.g. invoked or obtained via Class#getDeclaredMethods()). Plain
>>> imports are irrelevant (I don't think they are even present a concept
>>> in byte code), actual access of methods/fields with missing types will
>>> cause errors. So this could be doable, assuming that ORM itself
>>> doesn't work with JTA types in the case of JDBC-only.
>>>
>>> 2) If that's not feasible, JTA is non-optional really, leaving us to
>>> decide whether a) to "suggest" a JTA API version by transitively
>>> exposing it (which the user then still could replace) or b) always
>>> require the user to provide it.
>>>
>>> My personal preference would be 1) (assuming it is sensibly doable),
>>> followed by 2a) followed by 2b). Granted, 1) may be hard to test and
>>> also I am not sure whether that behaviour I described is guaranteed by
>>> the spec or only is exposed by specific JVMs.
>>>
>>> --Gunnar
>>>
>>>
>>>
>>> 2016-01-06 17:59 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>> > There is nothing "EE AS" specific in any of those jars I mentioned.
>>> > They
>>> > are all simply different jars of the JTA API.  Every EE spec has the
>>> > same
>>> > problem.  That is the point you are missing.
>>> >
>>> > TBH I forget the history as to why the JBoss's JTA jar (again, nothing
>>> > JBoss specific there, just the JTA API) was used rather than
>>> > javax.transaction:jta.  That predates our move to git and would require
>>> > some digging.  Later we moved from the JBoss JTA jar to the Geronimo
>>> > version because the JBoss one had some problem in its OSGi metadata
>>> > (the javax.transaction:jta
>>> > jar provides zero OSGi metadata btw).
>>> >
>>> >
>>> >
>>> > On Wed, Jan 6, 2016 at 10:44 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> > wrote:
>>> >
>>> >> I thought it was just the javax dependency.
>>> >> Supplying all those Java EE AS dependency is something else, as you
>>> >> pointed out.
>>> >>
>>> >> Adding some separate modules with those dependencies is not an option
>>> >> either: hibernate-wildfly, hibernate-geronimo, etc?
>>> >>
>>> >> Vlad
>>> >>
>>> >> On Wed, Jan 6, 2016 at 6:36 PM, Steve Ebersole <steve at hibernate.org>
>>> >> wrote:
>>> >>
>>> >>> Vlad, the issue is not "someone doesn't want it".  In fact, for the
>>> >>> most
>>> >>> part because of our decision to use the JTA contracts in our API
>>> >>> "(not)
>>> >>> wanting it" is not really an option.
>>> >>>
>>> >>> The issue here is the proliferation of JTA jars (maven coords).  We
>>> >>> have
>>> >>> the Geronimo jars, the JBoss/WildFly jars, etc.  So the concerns is
>>> >>> when
>>> >>> someone wants to use one of the jars other than the one we provide
>>> >>> transitively.  Yes, the result is the same: they still need to
>>> >>> exclude the
>>> >>> one we provide transitively.
>>> >>>
>>> >>> I have argued this for ages... I think this is a fundamental missing
>>> >>> construct in Maven dependency mappings: the ability to say "remap"
>>> >>> all
>>> >>> references to a particular spec jar coord to another.  Gradle luckily
>>> >>> allows users to do that (granted somewhat verbosely), Maven simply
>>> >>> does not.
>>> >>>
>>> >>>
>>> >>> On Wed, Jan 6, 2016 at 10:30 AM Vlad Mihalcea
>>> >>> <mihalcea.vlad at gmail.com>
>>> >>> wrote:
>>> >>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> Since the Hibernate core relies on the JTA dependency, I think we
>>> >>>> shouldn't provide that dependency.
>>> >>>> When someone doesn't want it he should explicitly mark that (e.g.
>>> >>>> Maven
>>> >>>> exclude).
>>> >>>> This way we can also address the parent issue:
>>> >>>> https://hibernate.atlassian.net/browse/HHH-10178
>>> >>>>
>>> >>>> Vlad
>>> >>>> On Wed, Jan 6, 2016 at 5:12 PM, Steve Ebersole <steve at hibernate.org>
>>> >>>> wrote:
>>> >>>>
>>> >>>>> HHH-10307[1] is another issue we need to get some consensus on.
>>> >>>>> Initially
>>> >>>>> we had removed JTA as a transitive dependency, but that is not
>>> >>>>> really
>>> >>>>> valid.  We need to discuss alternatives and options.
>>> >>>>>
>>> >>>>> [1] https://hibernate.atlassian.net/browse/HHH-10307
>>> >>>>>
>>> >>>> _______________________________________________
>>> >>>>> hibernate-dev mailing list
>>> >>>>> hibernate-dev at lists.jboss.org
>>> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>>>>
>>> >>>>
>>> >>
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev