[hibernate-dev] HHH-10307 - JTA dependency

[Gunnar Morling]

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