I'd prefer 1). The less dependencies I need, the better.
2016-01-06 18:36 GMT+01:00 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.tran
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 wrote:
> The JTA API is a tiny
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 wrote:
> I can see how users working with JDBC exclusively can be
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 experien
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
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 Eberso
Hi Vlad,
you mean we should provide that dependency, don't you?
On 6 January 2016 at 16:30, Vlad Mihalcea 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. M
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,
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,
(a) just the api
On Wed, Jan 6, 2016 at 10:20 AM Gunnar Morling wrote:
> To get some clarification: When using solely JDBC, what is required at
> runtime:
>
> a) the JTA API packages only
> b) JTA API and implementation
> c) none of the above
>
> ?
>
>
>
> 2016-01-06 16:12 GMT+01:00 Steve Ebers
To get some clarification: When using solely JDBC, what is required at runtime:
a) the JTA API packages only
b) JTA API and implementation
c) none of the above
?
2016-01-06 16:12 GMT+01:00 Steve Ebersole :
> HHH-10307[1] is another issue we need to get some consensus on. Initially
> we had re
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
___
12 matches
Mail list logo
