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 <st...@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 <gun...@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 <st...@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.v...@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 <st...@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.v...@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 <st...@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@lists.jboss.org >> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>>>> >> >>>> >> >> >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
