[hibernate-dev] [OGM] @Column and embedded objects in OGM

[Emmanuel Bernard]

Hey guys,

Marco found something that really surprised him. I am not sure if that’s a 
widespread behavior or just specific to CouchDB’s backend.

@Entity
class A {
   …
   B embedded;
}

@Embeddable
class B {
String c;
@Column(name=“real_d”) d;
}

The document structure is roughly

{
…
“embedded”: { “c”: “foo” },
“real_d”: “bar"
}

I can see this is happening because the column name has not dot in it. But I 
would expect as a noob to see the natural behavior and have real_d embedded in 
the nested document embedded.

Looks like MongoDB does the same and I suspect Noe4J too.

1. Can any one think of a trick (like the naming strategy or something like 
that) to compensate and do it “right”.
2. If not, I could not find anything in the documentation nor the FAQ and we 
should make that very obvious. I finally found some info in the embedded 
section of MongoDB but Neo4J and CouchDb are silent on the matter. How could we 
make that clearer in the mean time? FAQ?

Emmanuel
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] should immutable entities in the second level cache be invalidated when they are removed from the database?

[Radim Vansa]

On 01/05/2016 06:51 PM, Scott Marlow wrote:
> On 01/05/2016 12:36 PM, Steve Ebersole wrote:
>> Sorry Scott, I am not sure I understand exactly what you are asking.  I
>> will try to answer what I think you are asking as best I can..
>>
>>
>> On Tue, Jan 5, 2016 at 9:35 AM Scott Marlow > > wrote:
>>
>>  I missed adding the WildFly clustering configuration for the Hibernate
>>  immutable-entity cache.  I opened WFLY-5923 [1] for adding the cache but
>>  am unsure of whether org.hibernate.annotations.Immutable means that the
>>  application handles clearing the 2lc of stale immutable entities or if
>>  that should happen automagically when immutable entities are removed
>>  from the database.
>>
>>
>> Perhaps there is a confusion that an immutable entity can in fact be
>> created and deleted?  Immutable simply means the state of an existing
>> entity cannot be changed.  In SQL terms, if you will, we can have an
>> INSERT or a DELETE but never an UPDATE.
> Thanks for the answer, this is exactly what I needed to know.
>
>> If an application has asked that Hibernate cache data, the expectation
>> is that Hibernate would handle the caching of that data not the
>> application *so long as it knows about changes to the cached data*.  Now
>> if by "when immutable entities are removed from the database" you are
>> asking what should happen when cached data is changed in the database
>> directly, that answer is always the same and the question of
>> (im)mutablity is completely irrelevant there: if the underlying data is
>> changed directly in the database it is up to the application to make
>> sure that the cache is consistent with those outside changes.
>>
>>  In a cluster, I expect that the performance of caching
>>  immutable-entities, would be faster if we assume they will not be
>>  invalidated from the 2lc (e.g. let applications clear them from the
>>  cache).
>>
>>
>> I think really this comes down to the question of what "invalidated"
>> means to the underlying cache and how a deletion of data correlates to
>> that.  But my guess is that the invalidation still needs to handled (and
>> propagated) to properly handle the removal case.
> Yes, I agree (based on your explanation).
>
>>  Since we are using Infinispan for the 2lc in WildFly, I would like to
>>  use an Infinispan simple-cache for immutable-entities, which does no
>>  invalidation.  However, just because I would like to do this, doesn't
>>  make it right. :-)  Which is why I'm asking, what the design intention
>>  is, so I can configure the WildFly clustering configuration (for
>>  immutable entities), to align with the intent.
>>
>>
>> Right, which is what I am trying to describe I guess in my previous
>> paragraph.  Based on my (granted, very limited) understanding of
>> Infinispan I assume we still need the invalidation.  One possible option
>> is to allow the application to configure whether they expect removals
>> from an immutable dataset.
> This would be a nice performance enhancement for clustered environments,
> as the (no removals allowed) immutable-entities cache would not need to
> be cluster aware.

ATM in Infinispan 2LC there's no optimization for Immutable entities, 
because the necessary handling of removals does not differ much from 
updates.
In the past, the immutable-entities configuration was added as Galder 
suggested that in 4.x implementation these can use non-transactional 
cache, but in the end the implementation had flaws causing inconsistencies.

For Immutable and never removed entities, you can AFAIK safely use local 
cache. However I am not aware of any means that would mark entity as 
never removed, or relax the consistency for removals.

Radim

>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa 
JBoss Performance Team

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] @Column and embedded objects in OGM

[Gunnar Morling]

Hi,

Yes, I noticed this some time ago, too. It's tracked by
https://hibernate.atlassian.net/browse/OGM-893.

As it stands, I don't think it's fixable using the ORM
ImplicitNamingStrategy/PhysicalNamingStrategy contracts: The former
doesn't apply for explicitly given names, the latter lacks the
required context to establish the full dot name.

So maybe we could enhance PhysicalNamingStrategy - or have a new
contract specifically for preparing explicit names - to expose the
full attribute path, allowing implementations to prefix the column
with the parent name(s) as we'd need it for the document stores.

Btw. a - cumbersome - workaround is to use @AttributeOverride which
allows to create the right mapping. We can add something to the FAQ if
you like, but then I think it's a bug really which we need to fix, and
we don't have an FAQ entry for each bug.

--Gunnar



2016-01-06 9:40 GMT+01:00 Emmanuel Bernard :
> Hey guys,
>
> Marco found something that really surprised him. I am not sure if that’s a 
> widespread behavior or just specific to CouchDB’s backend.
>
> @Entity
> class A {
>…
>B embedded;
> }
>
> @Embeddable
> class B {
> String c;
> @Column(name=“real_d”) d;
> }
>
> The document structure is roughly
>
> {
> …
> “embedded”: { “c”: “foo” },
> “real_d”: “bar"
> }
>
> I can see this is happening because the column name has not dot in it. But I 
> would expect as a noob to see the natural behavior and have real_d embedded 
> in the nested document embedded.
>
> Looks like MongoDB does the same and I suspect Noe4J too.
>
> 1. Can any one think of a trick (like the naming strategy or something like 
> that) to compensate and do it “right”.
> 2. If not, I could not find anything in the documentation nor the FAQ and we 
> should make that very obvious. I finally found some info in the embedded 
> section of MongoDB but Neo4J and CouchDb are silent on the matter. How could 
> we make that clearer in the mean time? FAQ?
>
> Emmanuel
> ___
> 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] HHH-10307 - JTA dependency

[Steve Ebersole]

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] Hibernate forum inactive users pruning

[Vlad Mihalcea]

Hi,

Among all 75000 registered users, 1 used to be inactive ones
(registered without any post).

Regular users are always creating an account and post at least one question
on the forum, so there is no reason why we should keep 13 years old user
accounts that haven't posted anything on the forum.

Most have been registered with temporary email addresses or other spam
domain names.

I deleted those and now the forum is so much faster.

Vlad
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate forum inactive users pruning

[Steve Ebersole]

Awesome!  Although I find it strange that a mere 13% decrease in the number
of registered users would have such a big impact on overall performance of
the forum.

On Wed, Jan 6, 2016 at 9:53 AM Vlad Mihalcea 
wrote:

> Hi,
>
> Among all 75000 registered users, 1 used to be inactive ones
> (registered without any post).
>
> Regular users are always creating an account and post at least one question
> on the forum, so there is no reason why we should keep 13 years old user
> accounts that haven't posted anything on the forum.
>
> Most have been registered with temporary email addresses or other spam
> domain names.
>
> I deleted those and now the forum is so much faster.
>
> Vlad
> ___
> 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

Re: [hibernate-dev] Hibernate forum inactive users pruning

[Vlad Mihalcea]

There must have been some checks probably when the Home page was rendered,
but you can check it out and see the result.
I wish I could find a way to delete banned users too.

My banning routine goes like this:

1. I ban the email address or the whole domain if it's one of those
temporary email domains used by spammers
2. I then delete the spam account to make sure we don't store unnecessary
users in the DB

I noticed that the amount of spam has been reduced, although we still have
it.
They seem to bother to open a Gmail account just to send a post that's not
even visible.
I guess they do it manually, since Gmail should have a more robust Captcha
mechanism.

Vlad

On Wed, Jan 6, 2016 at 5:55 PM, Steve Ebersole  wrote:

> Awesome!  Although I find it strange that a mere 13% decrease in the
> number of registered users would have such a big impact on overall
> performance of the forum.
>
> On Wed, Jan 6, 2016 at 9:53 AM Vlad Mihalcea 
> wrote:
>
>> Hi,
>>
>> Among all 75000 registered users, 1 used to be inactive ones
>> (registered without any post).
>>
>> Regular users are always creating an account and post at least one
>> question
>> on the forum, so there is no reason why we should keep 13 years old user
>> accounts that haven't posted anything on the forum.
>>
>> Most have been registered with temporary email addresses or other spam
>> domain names.
>>
>> I deleted those and now the forum is so much faster.
>>
>> Vlad
>> ___
>> 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

Re: [hibernate-dev] HHH-10307 - JTA dependency

[Gunnar Morling]

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 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

Re: [hibernate-dev] HHH-10307 - JTA dependency

[Steve Ebersole]

(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 Ebersole :
> > 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

Re: [hibernate-dev] HHH-10307 - JTA dependency

[Vlad Mihalcea]

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  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

Re: [hibernate-dev] HHH-10307 - JTA dependency

[Steve Ebersole]

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 
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 
> 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

Re: [hibernate-dev] HHH-10307 - JTA dependency

[andrea boriero]

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. 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 
> 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

Re: [hibernate-dev] HHH-10307 - JTA dependency

[Vlad Mihalcea]

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  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 
> 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 
>> 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

Re: [hibernate-dev] HHH-10307 - JTA dependency

[Steve Ebersole]

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 
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 
> 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 
>> 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 
>>> 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

Re: [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 :
> 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 
> 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 
>> 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 
>>> 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 
 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

Re: [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  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 :
> > 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 
> > 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 
> >> 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  >
> >>> 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 
>  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

Re: [hibernate-dev] HHH-10307 - JTA dependency

[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.transaction.Synchronization
)

?



On Wed, Jan 6, 2016 at 11:34 AM Steve Ebersole  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 
> 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 :
>> > 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 
>> > 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 
>> >> 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 
>>  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-de

Re: [hibernate-dev] HHH-10307 - JTA dependency

[Gunnar Morling]

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.transaction.Synchronization
> )
>
> ?
>
>
>
> On Wed, Jan 6, 2016 at 11:34 AM Steve Ebersole  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 
>> 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 :
>>> > 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 
>>> > 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 
>>> >> 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
>>> >>> 
>>> >>> 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 
>>>  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
>>> >