[hibernate-dev] HHH-10307 - JTA dependency

[Steve Ebersole]

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