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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
> >>>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>
> >>>>
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>