[hibernate-dev] HHH-10307 - JTA dependency

[Steve Ebersole]

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
>