From gunnar at hibernate.org  Mon Mar  2 04:17:53 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 2 Mar 2015 10:17:53 +0100
Subject: [hibernate-dev] Bug fixes around JP-QL and more: Hibernate OGM
	4.1.2 released
Message-ID: <CADGJaX8it3n5oxhHJocd4PcV_scF0zaG3Fm5WNdhGcz3yrorHg@mail.gmail.com>

Hi,

It?s my pleasure to announce the release of Hibernate OGM 4.1.2!

This maintenance release fixes several bugs, e.g. around JP-QL, using
Hibernate OGM within SAAS environments and mapping byte[] properties on
CouchDB. We also clarified several issues in the reference guide.

Please check out the release announcement for the details [1].

--Gunnar

[1]
http://in.relation.to/Bloggers/BugFixesAroundJPQLAndMoreHibernateOGM412Released

From sanne at hibernate.org  Mon Mar  2 08:40:26 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 2 Mar 2015 13:40:26 +0000
Subject: [hibernate-dev] To identify the version of Hibernate ORM at runtime
Message-ID: <CAFm4XO2UxGF=RY6W4+nEVq2CZjhu8xYVL+PDOsQoXM0jk9oyeA@mail.gmail.com>

All,
it looks like people get easily confused by which version of ORM is
compatible with - for example - Hibernate Search.

The expected versions are documented plenty, in readme, project
sources, documentation and we even remind about the expectations
frequently in blog posts.

Wondering if it would be more effective to have some marker in ORM, to
validate at least for most critical known incompatibilities at
runtime?

I realize there is no 100% foolproof in any possible solution, but
providing a nice error message to 90% of these cases could be helpful
to a large population already, and doesn't seem too complex for us to
do.

I guess it could be simple enough to use the existing org.hibernate.Version ?
Or we could improve on those methods, if not actually adding some easy
to consume resource in the orm jars.

WDYT?

Sanne

 - https://hibernate.atlassian.net/browse/HSEARCH-1816
 - http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837

From gunnar at hibernate.org  Mon Mar  2 08:57:42 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 2 Mar 2015 14:57:42 +0100
Subject: [hibernate-dev] To identify the version of Hibernate ORM at
	runtime
In-Reply-To: <CAFm4XO2UxGF=RY6W4+nEVq2CZjhu8xYVL+PDOsQoXM0jk9oyeA@mail.gmail.com>
References: <CAFm4XO2UxGF=RY6W4+nEVq2CZjhu8xYVL+PDOsQoXM0jk9oyeA@mail.gmail.com>
Message-ID: <CADGJaX9t1in-0jRG63khMZewDa5McS1oLQwEt_furgsrBA0i7Q@mail.gmail.com>

> Or we could improve on those methods, if not actually adding some easy
to consume resource in the orm jars.

Doesn't such resource already exist, in the form of META-INF/MANIFEST.MF ->
key "Implementation-Version"?

Based on that you should be able to raise a meaningful error if the ORM
version is "too old". It doesn't help with incompatible future ORM
versions, but it should improve the experience in some cases.

2015-03-02 14:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> All,
> it looks like people get easily confused by which version of ORM is
> compatible with - for example - Hibernate Search.
>
> The expected versions are documented plenty, in readme, project
> sources, documentation and we even remind about the expectations
> frequently in blog posts.
>
> Wondering if it would be more effective to have some marker in ORM, to
> validate at least for most critical known incompatibilities at
> runtime?
>
> I realize there is no 100% foolproof in any possible solution, but
> providing a nice error message to 90% of these cases could be helpful
> to a large population already, and doesn't seem too complex for us to
> do.
>
> I guess it could be simple enough to use the existing
> org.hibernate.Version ?
> Or we could improve on those methods, if not actually adding some easy
> to consume resource in the orm jars.
>
> WDYT?
>
> Sanne
>
>  - https://hibernate.atlassian.net/browse/HSEARCH-1816
>  -
> http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Mar  2 10:05:13 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 2 Mar 2015 09:05:13 -0600
Subject: [hibernate-dev] To identify the version of Hibernate ORM at
	runtime
In-Reply-To: <CADGJaX9t1in-0jRG63khMZewDa5McS1oLQwEt_furgsrBA0i7Q@mail.gmail.com>
References: <CAFm4XO2UxGF=RY6W4+nEVq2CZjhu8xYVL+PDOsQoXM0jk9oyeA@mail.gmail.com>
	<CADGJaX9t1in-0jRG63khMZewDa5McS1oLQwEt_furgsrBA0i7Q@mail.gmail.com>
Message-ID: <CAFdSV9sa4BmAGtutr58Gh_-SdGadU6kMUFq7r8=CXh6g_wS-2g@mail.gmail.com>

Hmm, I had used to set the set the Specification-* entries too, but it
looks like those are no longer there :(

On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> > Or we could improve on those methods, if not actually adding some easy
> to consume resource in the orm jars.
>
> Doesn't such resource already exist, in the form of META-INF/MANIFEST.MF ->
> key "Implementation-Version"?
>
> Based on that you should be able to raise a meaningful error if the ORM
> version is "too old". It doesn't help with incompatible future ORM
> versions, but it should improve the experience in some cases.
>
> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>
> > All,
> > it looks like people get easily confused by which version of ORM is
> > compatible with - for example - Hibernate Search.
> >
> > The expected versions are documented plenty, in readme, project
> > sources, documentation and we even remind about the expectations
> > frequently in blog posts.
> >
> > Wondering if it would be more effective to have some marker in ORM, to
> > validate at least for most critical known incompatibilities at
> > runtime?
> >
> > I realize there is no 100% foolproof in any possible solution, but
> > providing a nice error message to 90% of these cases could be helpful
> > to a large population already, and doesn't seem too complex for us to
> > do.
> >
> > I guess it could be simple enough to use the existing
> > org.hibernate.Version ?
> > Or we could improve on those methods, if not actually adding some easy
> > to consume resource in the orm jars.
> >
> > WDYT?
> >
> > Sanne
> >
> >  - https://hibernate.atlassian.net/browse/HSEARCH-1816
> >  -
> >
> http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837
> > _______________________________________________
> > 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
>

From sanne at hibernate.org  Mon Mar  2 10:22:13 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 2 Mar 2015 15:22:13 +0000
Subject: [hibernate-dev] To identify the version of Hibernate ORM at
	runtime
In-Reply-To: <CAFdSV9sa4BmAGtutr58Gh_-SdGadU6kMUFq7r8=CXh6g_wS-2g@mail.gmail.com>
References: <CAFm4XO2UxGF=RY6W4+nEVq2CZjhu8xYVL+PDOsQoXM0jk9oyeA@mail.gmail.com>
	<CADGJaX9t1in-0jRG63khMZewDa5McS1oLQwEt_furgsrBA0i7Q@mail.gmail.com>
	<CAFdSV9sa4BmAGtutr58Gh_-SdGadU6kMUFq7r8=CXh6g_wS-2g@mail.gmail.com>
Message-ID: <CAFm4XO3jNEGz7CK34w2ARyaCUN_yWWfs=N=by_AGi21VGuTh4A@mail.gmail.com>

On 2 March 2015 at 15:05, Steve Ebersole <steve at hibernate.org> wrote:
> Hmm, I had used to set the set the Specification-* entries too, but it looks
> like those are no longer there :(

Just out of curiosity, what would these define?
But not too bad, I think I'll simply rely on parsing
org.hibernate.Version#getVersionString

> On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> > Or we could improve on those methods, if not actually adding some easy
>> to consume resource in the orm jars.
>>
>> Doesn't such resource already exist, in the form of META-INF/MANIFEST.MF
>> ->
>> key "Implementation-Version"?

Right that could work as well. There will be many manifests on
classpath I'd guess, but we could identify the one from ORM from the
other keys, such as Bundle-Name, Implementation-Vendor-Id, etc..
But how would that be better over using org.hibernate.Version#getVersionString ?

I guess one benefit of basing on resources would be that we'd be able
to check for duplicate ORM jars, but are we interested into going to
that length? It wouldn't be fool-proof either, as in a modular world
it's possible that ORM version A has visibility on Search (and
attempts to start it) but Search could be validating on resources from
ORM module B - and not be able to "see" ORM version A's resources. I
guess I'd stick with the method invocation, as obviously we can't
implement a bullet proof validation either way.

Sanne

>>
>> Based on that you should be able to raise a meaningful error if the ORM
>> version is "too old". It doesn't help with incompatible future ORM
>> versions, but it should improve the experience in some cases.
>>
>> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> > All,
>> > it looks like people get easily confused by which version of ORM is
>> > compatible with - for example - Hibernate Search.
>> >
>> > The expected versions are documented plenty, in readme, project
>> > sources, documentation and we even remind about the expectations
>> > frequently in blog posts.
>> >
>> > Wondering if it would be more effective to have some marker in ORM, to
>> > validate at least for most critical known incompatibilities at
>> > runtime?
>> >
>> > I realize there is no 100% foolproof in any possible solution, but
>> > providing a nice error message to 90% of these cases could be helpful
>> > to a large population already, and doesn't seem too complex for us to
>> > do.
>> >
>> > I guess it could be simple enough to use the existing
>> > org.hibernate.Version ?
>> > Or we could improve on those methods, if not actually adding some easy
>> > to consume resource in the orm jars.
>> >
>> > WDYT?
>> >
>> > Sanne
>> >
>> >  - https://hibernate.atlassian.net/browse/HSEARCH-1816
>> >  -
>> >
>> > http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837
>> > _______________________________________________
>> > 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
>
>

From steve at hibernate.org  Mon Mar  2 10:32:35 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 2 Mar 2015 09:32:35 -0600
Subject: [hibernate-dev] To identify the version of Hibernate ORM at
	runtime
In-Reply-To: <CAFm4XO3jNEGz7CK34w2ARyaCUN_yWWfs=N=by_AGi21VGuTh4A@mail.gmail.com>
References: <CAFm4XO2UxGF=RY6W4+nEVq2CZjhu8xYVL+PDOsQoXM0jk9oyeA@mail.gmail.com>
	<CADGJaX9t1in-0jRG63khMZewDa5McS1oLQwEt_furgsrBA0i7Q@mail.gmail.com>
	<CAFdSV9sa4BmAGtutr58Gh_-SdGadU6kMUFq7r8=CXh6g_wS-2g@mail.gmail.com>
	<CAFm4XO3jNEGz7CK34w2ARyaCUN_yWWfs=N=by_AGi21VGuTh4A@mail.gmail.com>
Message-ID: <CAFdSV9s6vdbtR_qP42bxkEt3Qx+8C2jPCs0v7fhJw0K8=nf7Xg@mail.gmail.com>

It was the "release family".  4.3, or 4.2...
On Mar 2, 2015 9:22 AM, "Sanne Grinovero" <sanne at hibernate.org> wrote:

> On 2 March 2015 at 15:05, Steve Ebersole <steve at hibernate.org> wrote:
> > Hmm, I had used to set the set the Specification-* entries too, but it
> looks
> > like those are no longer there :(
>
> Just out of curiosity, what would these define?
> But not too bad, I think I'll simply rely on parsing
> org.hibernate.Version#getVersionString
>
> > On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> > Or we could improve on those methods, if not actually adding some easy
> >> to consume resource in the orm jars.
> >>
> >> Doesn't such resource already exist, in the form of META-INF/MANIFEST.MF
> >> ->
> >> key "Implementation-Version"?
>
> Right that could work as well. There will be many manifests on
> classpath I'd guess, but we could identify the one from ORM from the
> other keys, such as Bundle-Name, Implementation-Vendor-Id, etc..
> But how would that be better over using
> org.hibernate.Version#getVersionString ?
>
> I guess one benefit of basing on resources would be that we'd be able
> to check for duplicate ORM jars, but are we interested into going to
> that length? It wouldn't be fool-proof either, as in a modular world
> it's possible that ORM version A has visibility on Search (and
> attempts to start it) but Search could be validating on resources from
> ORM module B - and not be able to "see" ORM version A's resources. I
> guess I'd stick with the method invocation, as obviously we can't
> implement a bullet proof validation either way.
>
> Sanne
>
> >>
> >> Based on that you should be able to raise a meaningful error if the ORM
> >> version is "too old". It doesn't help with incompatible future ORM
> >> versions, but it should improve the experience in some cases.
> >>
> >> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> > All,
> >> > it looks like people get easily confused by which version of ORM is
> >> > compatible with - for example - Hibernate Search.
> >> >
> >> > The expected versions are documented plenty, in readme, project
> >> > sources, documentation and we even remind about the expectations
> >> > frequently in blog posts.
> >> >
> >> > Wondering if it would be more effective to have some marker in ORM, to
> >> > validate at least for most critical known incompatibilities at
> >> > runtime?
> >> >
> >> > I realize there is no 100% foolproof in any possible solution, but
> >> > providing a nice error message to 90% of these cases could be helpful
> >> > to a large population already, and doesn't seem too complex for us to
> >> > do.
> >> >
> >> > I guess it could be simple enough to use the existing
> >> > org.hibernate.Version ?
> >> > Or we could improve on those methods, if not actually adding some easy
> >> > to consume resource in the orm jars.
> >> >
> >> > WDYT?
> >> >
> >> > Sanne
> >> >
> >> >  - https://hibernate.atlassian.net/browse/HSEARCH-1816
> >> >  -
> >> >
> >> >
> http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837
> >> > _______________________________________________
> >> > 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
> >
> >
>

From gunnar at hibernate.org  Mon Mar  2 10:49:13 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 2 Mar 2015 16:49:13 +0100
Subject: [hibernate-dev] To identify the version of Hibernate ORM at
	runtime
In-Reply-To: <CAFm4XO3jNEGz7CK34w2ARyaCUN_yWWfs=N=by_AGi21VGuTh4A@mail.gmail.com>
References: <CAFm4XO2UxGF=RY6W4+nEVq2CZjhu8xYVL+PDOsQoXM0jk9oyeA@mail.gmail.com>
	<CADGJaX9t1in-0jRG63khMZewDa5McS1oLQwEt_furgsrBA0i7Q@mail.gmail.com>
	<CAFdSV9sa4BmAGtutr58Gh_-SdGadU6kMUFq7r8=CXh6g_wS-2g@mail.gmail.com>
	<CAFm4XO3jNEGz7CK34w2ARyaCUN_yWWfs=N=by_AGi21VGuTh4A@mail.gmail.com>
Message-ID: <CADGJaX96PEW-24Yt_ZPCqNi_pOmQzept-aBC2ybHuYT9xSgKOQ@mail.gmail.com>

2015-03-02 16:22 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> On 2 March 2015 at 15:05, Steve Ebersole <steve at hibernate.org> wrote:
> > Hmm, I had used to set the set the Specification-* entries too, but it
> looks
> > like those are no longer there :(
>
> Just out of curiosity, what would these define?
> But not too bad, I think I'll simply rely on parsing
> org.hibernate.Version#getVersionString
>
> > On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> > Or we could improve on those methods, if not actually adding some easy
> >> to consume resource in the orm jars.
> >>
> >> Doesn't such resource already exist, in the form of META-INF/MANIFEST.MF
> >> ->
> >> key "Implementation-Version"?
>
> Right that could work as well. There will be many manifests on
> classpath I'd guess, but we could identify the one from ORM from the
> other keys, such as Bundle-Name, Implementation-Vendor-Id, etc..
> But how would that be better over using
> org.hibernate.Version#getVersionString ?
>

The "Implementation-Version" value can be obtained through a standard API:

    Session.class.getPackage().getImplementationVersion();

So it basically renders that custom method superfluous.

No huge difference apart from that. Only pointing out that there is no need
for another "easy to consume resource in the orm jars".

I guess one benefit of basing on resources would be that we'd be able
> to check for duplicate ORM jars, but are we interested into going to
> that length? It wouldn't be fool-proof either, as in a modular world
> it's possible that ORM version A has visibility on Search (and
> attempts to start it) but Search could be validating on resources from
> ORM module B - and not be able to "see" ORM version A's resources. I
> guess I'd stick with the method invocation, as obviously we can't
> implement a bullet proof validation either way.
>

+1 for keeping it simple.


>
> Sanne
>
> >>
> >> Based on that you should be able to raise a meaningful error if the ORM
> >> version is "too old". It doesn't help with incompatible future ORM
> >> versions, but it should improve the experience in some cases.
> >>
> >> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> > All,
> >> > it looks like people get easily confused by which version of ORM is
> >> > compatible with - for example - Hibernate Search.
> >> >
> >> > The expected versions are documented plenty, in readme, project
> >> > sources, documentation and we even remind about the expectations
> >> > frequently in blog posts.
> >> >
> >> > Wondering if it would be more effective to have some marker in ORM, to
> >> > validate at least for most critical known incompatibilities at
> >> > runtime?
> >> >
> >> > I realize there is no 100% foolproof in any possible solution, but
> >> > providing a nice error message to 90% of these cases could be helpful
> >> > to a large population already, and doesn't seem too complex for us to
> >> > do.
> >> >
> >> > I guess it could be simple enough to use the existing
> >> > org.hibernate.Version ?
> >> > Or we could improve on those methods, if not actually adding some easy
> >> > to consume resource in the orm jars.
> >> >
> >> > WDYT?
> >> >
> >> > Sanne
> >> >
> >> >  - https://hibernate.atlassian.net/browse/HSEARCH-1816
> >> >  -
> >> >
> >> >
> http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837
> >> > _______________________________________________
> >> > 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
> >
> >
>

From sanne at hibernate.org  Mon Mar  2 11:03:49 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 2 Mar 2015 16:03:49 +0000
Subject: [hibernate-dev] To identify the version of Hibernate ORM at
	runtime
In-Reply-To: <CADGJaX96PEW-24Yt_ZPCqNi_pOmQzept-aBC2ybHuYT9xSgKOQ@mail.gmail.com>
References: <CAFm4XO2UxGF=RY6W4+nEVq2CZjhu8xYVL+PDOsQoXM0jk9oyeA@mail.gmail.com>
	<CADGJaX9t1in-0jRG63khMZewDa5McS1oLQwEt_furgsrBA0i7Q@mail.gmail.com>
	<CAFdSV9sa4BmAGtutr58Gh_-SdGadU6kMUFq7r8=CXh6g_wS-2g@mail.gmail.com>
	<CAFm4XO3jNEGz7CK34w2ARyaCUN_yWWfs=N=by_AGi21VGuTh4A@mail.gmail.com>
	<CADGJaX96PEW-24Yt_ZPCqNi_pOmQzept-aBC2ybHuYT9xSgKOQ@mail.gmail.com>
Message-ID: <CAFm4XO31W5eEr33D-G71xbe70LT5OPe=QW7G1zrPpFjvKJSZXA@mail.gmail.com>

On 2 March 2015 at 15:49, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>
> 2015-03-02 16:22 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 2 March 2015 at 15:05, Steve Ebersole <steve at hibernate.org> wrote:
>> > Hmm, I had used to set the set the Specification-* entries too, but it
>> > looks
>> > like those are no longer there :(
>>
>> Just out of curiosity, what would these define?
>> But not too bad, I think I'll simply rely on parsing
>> org.hibernate.Version#getVersionString
>>
>> > On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling <gunnar at hibernate.org>
>> > wrote:
>> >>
>> >> > Or we could improve on those methods, if not actually adding some
>> >> > easy
>> >> to consume resource in the orm jars.
>> >>
>> >> Doesn't such resource already exist, in the form of
>> >> META-INF/MANIFEST.MF
>> >> ->
>> >> key "Implementation-Version"?
>>
>> Right that could work as well. There will be many manifests on
>> classpath I'd guess, but we could identify the one from ORM from the
>> other keys, such as Bundle-Name, Implementation-Vendor-Id, etc..
>> But how would that be better over using
>> org.hibernate.Version#getVersionString ?
>
>
> The "Implementation-Version" value can be obtained through a standard API:
>
>     Session.class.getPackage().getImplementationVersion();
>
> So it basically renders that custom method superfluous.

Cool trick, I had no idea :)
So why do we have those methods? Just to log it?

>
> No huge difference apart from that. Only pointing out that there is no need
> for another "easy to consume resource in the orm jars".
>
>> I guess one benefit of basing on resources would be that we'd be able
>> to check for duplicate ORM jars, but are we interested into going to
>> that length? It wouldn't be fool-proof either, as in a modular world
>> it's possible that ORM version A has visibility on Search (and
>> attempts to start it) but Search could be validating on resources from
>> ORM module B - and not be able to "see" ORM version A's resources. I
>> guess I'd stick with the method invocation, as obviously we can't
>> implement a bullet proof validation either way.
>
>
> +1 for keeping it simple.
>
>>
>>
>> Sanne
>>
>> >>
>> >> Based on that you should be able to raise a meaningful error if the ORM
>> >> version is "too old". It doesn't help with incompatible future ORM
>> >> versions, but it should improve the experience in some cases.
>> >>
>> >> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> > All,
>> >> > it looks like people get easily confused by which version of ORM is
>> >> > compatible with - for example - Hibernate Search.
>> >> >
>> >> > The expected versions are documented plenty, in readme, project
>> >> > sources, documentation and we even remind about the expectations
>> >> > frequently in blog posts.
>> >> >
>> >> > Wondering if it would be more effective to have some marker in ORM,
>> >> > to
>> >> > validate at least for most critical known incompatibilities at
>> >> > runtime?
>> >> >
>> >> > I realize there is no 100% foolproof in any possible solution, but
>> >> > providing a nice error message to 90% of these cases could be helpful
>> >> > to a large population already, and doesn't seem too complex for us to
>> >> > do.
>> >> >
>> >> > I guess it could be simple enough to use the existing
>> >> > org.hibernate.Version ?
>> >> > Or we could improve on those methods, if not actually adding some
>> >> > easy
>> >> > to consume resource in the orm jars.
>> >> >
>> >> > WDYT?
>> >> >
>> >> > Sanne
>> >> >
>> >> >  - https://hibernate.atlassian.net/browse/HSEARCH-1816
>> >> >  -
>> >> >
>> >> >
>> >> > http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837
>> >> > _______________________________________________
>> >> > 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
>> >
>> >
>
>

From steve at hibernate.org  Tue Mar  3 10:18:27 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 3 Mar 2015 09:18:27 -0600
Subject: [hibernate-dev] To identify the version of Hibernate ORM at
	runtime
In-Reply-To: <CAFm4XO31W5eEr33D-G71xbe70LT5OPe=QW7G1zrPpFjvKJSZXA@mail.gmail.com>
References: <CAFm4XO2UxGF=RY6W4+nEVq2CZjhu8xYVL+PDOsQoXM0jk9oyeA@mail.gmail.com>
	<CADGJaX9t1in-0jRG63khMZewDa5McS1oLQwEt_furgsrBA0i7Q@mail.gmail.com>
	<CAFdSV9sa4BmAGtutr58Gh_-SdGadU6kMUFq7r8=CXh6g_wS-2g@mail.gmail.com>
	<CAFm4XO3jNEGz7CK34w2ARyaCUN_yWWfs=N=by_AGi21VGuTh4A@mail.gmail.com>
	<CADGJaX96PEW-24Yt_ZPCqNi_pOmQzept-aBC2ybHuYT9xSgKOQ@mail.gmail.com>
	<CAFm4XO31W5eEr33D-G71xbe70LT5OPe=QW7G1zrPpFjvKJSZXA@mail.gmail.com>
Message-ID: <CAFdSV9t_jiU=eYivL9HZTWnSpsVuaoytcX2G1f4m0PjK2f4Nyg@mail.gmail.com>

I just personally never knew about this method :)

On Mon, Mar 2, 2015 at 10:03 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 2 March 2015 at 15:49, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> >
> > 2015-03-02 16:22 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> On 2 March 2015 at 15:05, Steve Ebersole <steve at hibernate.org> wrote:
> >> > Hmm, I had used to set the set the Specification-* entries too, but it
> >> > looks
> >> > like those are no longer there :(
> >>
> >> Just out of curiosity, what would these define?
> >> But not too bad, I think I'll simply rely on parsing
> >> org.hibernate.Version#getVersionString
> >>
> >> > On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling <gunnar at hibernate.org>
> >> > wrote:
> >> >>
> >> >> > Or we could improve on those methods, if not actually adding some
> >> >> > easy
> >> >> to consume resource in the orm jars.
> >> >>
> >> >> Doesn't such resource already exist, in the form of
> >> >> META-INF/MANIFEST.MF
> >> >> ->
> >> >> key "Implementation-Version"?
> >>
> >> Right that could work as well. There will be many manifests on
> >> classpath I'd guess, but we could identify the one from ORM from the
> >> other keys, such as Bundle-Name, Implementation-Vendor-Id, etc..
> >> But how would that be better over using
> >> org.hibernate.Version#getVersionString ?
> >
> >
> > The "Implementation-Version" value can be obtained through a standard
> API:
> >
> >     Session.class.getPackage().getImplementationVersion();
> >
> > So it basically renders that custom method superfluous.
>
> Cool trick, I had no idea :)
> So why do we have those methods? Just to log it?
>
> >
> > No huge difference apart from that. Only pointing out that there is no
> need
> > for another "easy to consume resource in the orm jars".
> >
> >> I guess one benefit of basing on resources would be that we'd be able
> >> to check for duplicate ORM jars, but are we interested into going to
> >> that length? It wouldn't be fool-proof either, as in a modular world
> >> it's possible that ORM version A has visibility on Search (and
> >> attempts to start it) but Search could be validating on resources from
> >> ORM module B - and not be able to "see" ORM version A's resources. I
> >> guess I'd stick with the method invocation, as obviously we can't
> >> implement a bullet proof validation either way.
> >
> >
> > +1 for keeping it simple.
> >
> >>
> >>
> >> Sanne
> >>
> >> >>
> >> >> Based on that you should be able to raise a meaningful error if the
> ORM
> >> >> version is "too old". It doesn't help with incompatible future ORM
> >> >> versions, but it should improve the experience in some cases.
> >> >>
> >> >> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >>
> >> >> > All,
> >> >> > it looks like people get easily confused by which version of ORM is
> >> >> > compatible with - for example - Hibernate Search.
> >> >> >
> >> >> > The expected versions are documented plenty, in readme, project
> >> >> > sources, documentation and we even remind about the expectations
> >> >> > frequently in blog posts.
> >> >> >
> >> >> > Wondering if it would be more effective to have some marker in ORM,
> >> >> > to
> >> >> > validate at least for most critical known incompatibilities at
> >> >> > runtime?
> >> >> >
> >> >> > I realize there is no 100% foolproof in any possible solution, but
> >> >> > providing a nice error message to 90% of these cases could be
> helpful
> >> >> > to a large population already, and doesn't seem too complex for us
> to
> >> >> > do.
> >> >> >
> >> >> > I guess it could be simple enough to use the existing
> >> >> > org.hibernate.Version ?
> >> >> > Or we could improve on those methods, if not actually adding some
> >> >> > easy
> >> >> > to consume resource in the orm jars.
> >> >> >
> >> >> > WDYT?
> >> >> >
> >> >> > Sanne
> >> >> >
> >> >> >  - https://hibernate.atlassian.net/browse/HSEARCH-1816
> >> >> >  -
> >> >> >
> >> >> >
> >> >> >
> http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837
> >> >> > _______________________________________________
> >> >> > 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
> >> >
> >> >
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Mar  3 10:20:54 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 3 Mar 2015 09:20:54 -0600
Subject: [hibernate-dev] To identify the version of Hibernate ORM at
	runtime
In-Reply-To: <CAFdSV9t_jiU=eYivL9HZTWnSpsVuaoytcX2G1f4m0PjK2f4Nyg@mail.gmail.com>
References: <CAFm4XO2UxGF=RY6W4+nEVq2CZjhu8xYVL+PDOsQoXM0jk9oyeA@mail.gmail.com>
	<CADGJaX9t1in-0jRG63khMZewDa5McS1oLQwEt_furgsrBA0i7Q@mail.gmail.com>
	<CAFdSV9sa4BmAGtutr58Gh_-SdGadU6kMUFq7r8=CXh6g_wS-2g@mail.gmail.com>
	<CAFm4XO3jNEGz7CK34w2ARyaCUN_yWWfs=N=by_AGi21VGuTh4A@mail.gmail.com>
	<CADGJaX96PEW-24Yt_ZPCqNi_pOmQzept-aBC2ybHuYT9xSgKOQ@mail.gmail.com>
	<CAFm4XO31W5eEr33D-G71xbe70LT5OPe=QW7G1zrPpFjvKJSZXA@mail.gmail.com>
	<CAFdSV9t_jiU=eYivL9HZTWnSpsVuaoytcX2G1f4m0PjK2f4Nyg@mail.gmail.com>
Message-ID: <CAFdSV9u-nyOGkOxbXehjBzk_ncoGjiJdGjN6LQCdeBSd9wSm7g@mail.gmail.com>

I think we should point out that this method is only available (iiuc) when
running with "from a jar".  Which means it won't work, for example, in our
test suites.  I assume we'd just get blanks or nulls there.

On Tue, Mar 3, 2015 at 9:18 AM, Steve Ebersole <steve at hibernate.org> wrote:

> I just personally never knew about this method :)
>
> On Mon, Mar 2, 2015 at 10:03 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 2 March 2015 at 15:49, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >
>> >
>> > 2015-03-02 16:22 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> On 2 March 2015 at 15:05, Steve Ebersole <steve at hibernate.org> wrote:
>> >> > Hmm, I had used to set the set the Specification-* entries too, but
>> it
>> >> > looks
>> >> > like those are no longer there :(
>> >>
>> >> Just out of curiosity, what would these define?
>> >> But not too bad, I think I'll simply rely on parsing
>> >> org.hibernate.Version#getVersionString
>> >>
>> >> > On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling <gunnar at hibernate.org
>> >
>> >> > wrote:
>> >> >>
>> >> >> > Or we could improve on those methods, if not actually adding some
>> >> >> > easy
>> >> >> to consume resource in the orm jars.
>> >> >>
>> >> >> Doesn't such resource already exist, in the form of
>> >> >> META-INF/MANIFEST.MF
>> >> >> ->
>> >> >> key "Implementation-Version"?
>> >>
>> >> Right that could work as well. There will be many manifests on
>> >> classpath I'd guess, but we could identify the one from ORM from the
>> >> other keys, such as Bundle-Name, Implementation-Vendor-Id, etc..
>> >> But how would that be better over using
>> >> org.hibernate.Version#getVersionString ?
>> >
>> >
>> > The "Implementation-Version" value can be obtained through a standard
>> API:
>> >
>> >     Session.class.getPackage().getImplementationVersion();
>> >
>> > So it basically renders that custom method superfluous.
>>
>> Cool trick, I had no idea :)
>> So why do we have those methods? Just to log it?
>>
>> >
>> > No huge difference apart from that. Only pointing out that there is no
>> need
>> > for another "easy to consume resource in the orm jars".
>> >
>> >> I guess one benefit of basing on resources would be that we'd be able
>> >> to check for duplicate ORM jars, but are we interested into going to
>> >> that length? It wouldn't be fool-proof either, as in a modular world
>> >> it's possible that ORM version A has visibility on Search (and
>> >> attempts to start it) but Search could be validating on resources from
>> >> ORM module B - and not be able to "see" ORM version A's resources. I
>> >> guess I'd stick with the method invocation, as obviously we can't
>> >> implement a bullet proof validation either way.
>> >
>> >
>> > +1 for keeping it simple.
>> >
>> >>
>> >>
>> >> Sanne
>> >>
>> >> >>
>> >> >> Based on that you should be able to raise a meaningful error if the
>> ORM
>> >> >> version is "too old". It doesn't help with incompatible future ORM
>> >> >> versions, but it should improve the experience in some cases.
>> >> >>
>> >> >> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >> >>
>> >> >> > All,
>> >> >> > it looks like people get easily confused by which version of ORM
>> is
>> >> >> > compatible with - for example - Hibernate Search.
>> >> >> >
>> >> >> > The expected versions are documented plenty, in readme, project
>> >> >> > sources, documentation and we even remind about the expectations
>> >> >> > frequently in blog posts.
>> >> >> >
>> >> >> > Wondering if it would be more effective to have some marker in
>> ORM,
>> >> >> > to
>> >> >> > validate at least for most critical known incompatibilities at
>> >> >> > runtime?
>> >> >> >
>> >> >> > I realize there is no 100% foolproof in any possible solution, but
>> >> >> > providing a nice error message to 90% of these cases could be
>> helpful
>> >> >> > to a large population already, and doesn't seem too complex for
>> us to
>> >> >> > do.
>> >> >> >
>> >> >> > I guess it could be simple enough to use the existing
>> >> >> > org.hibernate.Version ?
>> >> >> > Or we could improve on those methods, if not actually adding some
>> >> >> > easy
>> >> >> > to consume resource in the orm jars.
>> >> >> >
>> >> >> > WDYT?
>> >> >> >
>> >> >> > Sanne
>> >> >> >
>> >> >> >  - https://hibernate.atlassian.net/browse/HSEARCH-1816
>> >> >> >  -
>> >> >> >
>> >> >> >
>> >> >> >
>> http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837
>> >> >> > _______________________________________________
>> >> >> > 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
>> >> >
>> >> >
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Wed Mar  4 02:28:06 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 4 Mar 2015 08:28:06 +0100
Subject: [hibernate-dev] To identify the version of Hibernate ORM at
	runtime
In-Reply-To: <CAFdSV9u-nyOGkOxbXehjBzk_ncoGjiJdGjN6LQCdeBSd9wSm7g@mail.gmail.com>
References: <CAFm4XO2UxGF=RY6W4+nEVq2CZjhu8xYVL+PDOsQoXM0jk9oyeA@mail.gmail.com>
	<CADGJaX9t1in-0jRG63khMZewDa5McS1oLQwEt_furgsrBA0i7Q@mail.gmail.com>
	<CAFdSV9sa4BmAGtutr58Gh_-SdGadU6kMUFq7r8=CXh6g_wS-2g@mail.gmail.com>
	<CAFm4XO3jNEGz7CK34w2ARyaCUN_yWWfs=N=by_AGi21VGuTh4A@mail.gmail.com>
	<CADGJaX96PEW-24Yt_ZPCqNi_pOmQzept-aBC2ybHuYT9xSgKOQ@mail.gmail.com>
	<CAFm4XO31W5eEr33D-G71xbe70LT5OPe=QW7G1zrPpFjvKJSZXA@mail.gmail.com>
	<CAFdSV9t_jiU=eYivL9HZTWnSpsVuaoytcX2G1f4m0PjK2f4Nyg@mail.gmail.com>
	<CAFdSV9u-nyOGkOxbXehjBzk_ncoGjiJdGjN6LQCdeBSd9wSm7g@mail.gmail.com>
Message-ID: <CADGJaX9zD0ABrHGs0BP4=b+BMfNnF8-v45YWq752prvMBJ6wAA@mail.gmail.com>

Yes, that's true. It returns null when being run for classes obtained from
a directory rather than a JAR.

I noticed the same btw. when running tests in the IDE for the injection
stuff we e.g. use in HV, but it never was a problem for us there.


2015-03-03 16:20 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> I think we should point out that this method is only available (iiuc) when
> running with "from a jar".  Which means it won't work, for example, in our
> test suites.  I assume we'd just get blanks or nulls there.
>
> On Tue, Mar 3, 2015 at 9:18 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I just personally never knew about this method :)
>>
>> On Mon, Mar 2, 2015 at 10:03 AM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>>> On 2 March 2015 at 15:49, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> >
>>> >
>>> > 2015-03-02 16:22 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>> >>
>>> >> On 2 March 2015 at 15:05, Steve Ebersole <steve at hibernate.org> wrote:
>>> >> > Hmm, I had used to set the set the Specification-* entries too, but
>>> it
>>> >> > looks
>>> >> > like those are no longer there :(
>>> >>
>>> >> Just out of curiosity, what would these define?
>>> >> But not too bad, I think I'll simply rely on parsing
>>> >> org.hibernate.Version#getVersionString
>>> >>
>>> >> > On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling <
>>> gunnar at hibernate.org>
>>> >> > wrote:
>>> >> >>
>>> >> >> > Or we could improve on those methods, if not actually adding some
>>> >> >> > easy
>>> >> >> to consume resource in the orm jars.
>>> >> >>
>>> >> >> Doesn't such resource already exist, in the form of
>>> >> >> META-INF/MANIFEST.MF
>>> >> >> ->
>>> >> >> key "Implementation-Version"?
>>> >>
>>> >> Right that could work as well. There will be many manifests on
>>> >> classpath I'd guess, but we could identify the one from ORM from the
>>> >> other keys, such as Bundle-Name, Implementation-Vendor-Id, etc..
>>> >> But how would that be better over using
>>> >> org.hibernate.Version#getVersionString ?
>>> >
>>> >
>>> > The "Implementation-Version" value can be obtained through a standard
>>> API:
>>> >
>>> >     Session.class.getPackage().getImplementationVersion();
>>> >
>>> > So it basically renders that custom method superfluous.
>>>
>>> Cool trick, I had no idea :)
>>> So why do we have those methods? Just to log it?
>>>
>>> >
>>> > No huge difference apart from that. Only pointing out that there is no
>>> need
>>> > for another "easy to consume resource in the orm jars".
>>> >
>>> >> I guess one benefit of basing on resources would be that we'd be able
>>> >> to check for duplicate ORM jars, but are we interested into going to
>>> >> that length? It wouldn't be fool-proof either, as in a modular world
>>> >> it's possible that ORM version A has visibility on Search (and
>>> >> attempts to start it) but Search could be validating on resources from
>>> >> ORM module B - and not be able to "see" ORM version A's resources. I
>>> >> guess I'd stick with the method invocation, as obviously we can't
>>> >> implement a bullet proof validation either way.
>>> >
>>> >
>>> > +1 for keeping it simple.
>>> >
>>> >>
>>> >>
>>> >> Sanne
>>> >>
>>> >> >>
>>> >> >> Based on that you should be able to raise a meaningful error if
>>> the ORM
>>> >> >> version is "too old". It doesn't help with incompatible future ORM
>>> >> >> versions, but it should improve the experience in some cases.
>>> >> >>
>>> >> >> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>> >> >>
>>> >> >> > All,
>>> >> >> > it looks like people get easily confused by which version of ORM
>>> is
>>> >> >> > compatible with - for example - Hibernate Search.
>>> >> >> >
>>> >> >> > The expected versions are documented plenty, in readme, project
>>> >> >> > sources, documentation and we even remind about the expectations
>>> >> >> > frequently in blog posts.
>>> >> >> >
>>> >> >> > Wondering if it would be more effective to have some marker in
>>> ORM,
>>> >> >> > to
>>> >> >> > validate at least for most critical known incompatibilities at
>>> >> >> > runtime?
>>> >> >> >
>>> >> >> > I realize there is no 100% foolproof in any possible solution,
>>> but
>>> >> >> > providing a nice error message to 90% of these cases could be
>>> helpful
>>> >> >> > to a large population already, and doesn't seem too complex for
>>> us to
>>> >> >> > do.
>>> >> >> >
>>> >> >> > I guess it could be simple enough to use the existing
>>> >> >> > org.hibernate.Version ?
>>> >> >> > Or we could improve on those methods, if not actually adding some
>>> >> >> > easy
>>> >> >> > to consume resource in the orm jars.
>>> >> >> >
>>> >> >> > WDYT?
>>> >> >> >
>>> >> >> > Sanne
>>> >> >> >
>>> >> >> >  - https://hibernate.atlassian.net/browse/HSEARCH-1816
>>> >> >> >  -
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837
>>> >> >> > _______________________________________________
>>> >> >> > 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
>>> >> >
>>> >> >
>>> >
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From sanne at hibernate.org  Wed Mar  4 08:24:29 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 4 Mar 2015 13:24:29 +0000
Subject: [hibernate-dev] Announcing Hibernate Search 5.1.0.Final !
Message-ID: <CAFm4XO2+2wjk2JcHjQc32cCd6UeVRQyLxoErdYWTweerQ536iQ@mail.gmail.com>

With many performance and usability improvements, and some bugfixes
over 5.0.1.Final.

As usual the better overview is on our blog:
 - http://in.relation.to/Bloggers/HibernateSearch51

Regards,
Sanne

From emmanuel at hibernate.org  Fri Mar  6 03:12:21 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 6 Mar 2015 09:12:21 +0100
Subject: [hibernate-dev] Returning Iterable
Message-ID: <21A65FC8-061F-4665-ACBC-590836CBCA9B@hibernate.org>

We had that debate in one of the PR. We ended up not returning it for other reasons.
A small additional stone to the discussion is here http://alexruiz.developerblogs.com/?p=2519



From sanne at hibernate.org  Fri Mar  6 05:01:09 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 6 Mar 2015 10:01:09 +0000
Subject: [hibernate-dev] Returning Iterable
In-Reply-To: <21A65FC8-061F-4665-ACBC-590836CBCA9B@hibernate.org>
References: <21A65FC8-061F-4665-ACBC-590836CBCA9B@hibernate.org>
Message-ID: <CAFm4XO1mAfv2zEcFFMtS2s7oFaG6C4hfVsHfSwAeRzcAoSDk8A@mail.gmail.com>

I was already aware of that blog, and while he makes some interesting
observations, I strongly disagree on it being a general rule. Like
many of the people commenting on the blog post, and the author himself
admits the title was too broad ;-)

First of, it's an SPI that we consume ourselves. We *know* that all we
need is to iterate, and the "for each" idiom is all we need.
Exposing a List in this case was an error, as it's a leaky
abstraction: there is no ordering requirement, and in fact I was
hoping to replace the implementation with a Set but I couldn't do that
as we committed to a contract which exposes a List.

We all know the rules of encapsulation: expose the least possible, but
no less... obviously the blog poster has a point in his case as he was
bitten by the "no less" problem.
I guess we all like encapsulation of classes, or we could as well move
back to public static fields rather than accessors. And you all return
"Set", and not "HashSet" right? Even though I often prefer to keep the
private field to use the type of the concrete collection, as
*privately* it may be useful (that's a case by case call).

You expose the highest abstraction which satisfies the need, aiming at
a good balance of practicality for both the implementor of the
contract and the consumer.

There also is a performance aspect. By returning List or Set, decency
rules require me to wrap them in their immutable counterparts, or make
defensive copies.
But then when the collections' whole point is to actually mutate,
you'd need to do such a wrap (or such a copy) on a per-invocation of
the read.. even if you don't agree on it being a good enough
performance reason, it adds on the readability of the code.
Often that's not a big deal, still why do I need to pay for any cost
if its reason to be is completely moot.

Many of our internal contracts should be Iterable, especially if it's
only about iterating _some collection_.

It's different of course if you expose it as a domain model to a user
API: in that case you don't really know what the use case's practical
needs are going to need, and then like the blog states being able to
run "size()" is often too compelling.



On 6 March 2015 at 08:12, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> We had that debate in one of the PR. We ended up not returning it for other reasons.
> A small additional stone to the discussion is here http://alexruiz.developerblogs.com/?p=2519
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From hardy at hibernate.org  Fri Mar  6 05:36:58 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 6 Mar 2015 11:36:58 +0100
Subject: [hibernate-dev] Returning Iterable
In-Reply-To: <CAFm4XO1mAfv2zEcFFMtS2s7oFaG6C4hfVsHfSwAeRzcAoSDk8A@mail.gmail.com>
References: <21A65FC8-061F-4665-ACBC-590836CBCA9B@hibernate.org>
	<CAFm4XO1mAfv2zEcFFMtS2s7oFaG6C4hfVsHfSwAeRzcAoSDk8A@mail.gmail.com>
Message-ID: <20150306103658.GA40082@Sarmakand-4.local>

Hi,

> First of, it's an SPI that we consume ourselves. We *know* that all we
> need is to iterate, and the "for each" idiom is all we need.

How do you know that? At the moment that might be how it is implemented, 
but in the future this might change. In which case Iterable is a very
unthankful data structure to work with. 

Also, in many cases some processing can be skipped if I do a simple 
empty/size check first. I cannot even do that with an Iterable.

> Exposing a List in this case was an error, as it's a leaky
> abstraction there is no ordering requirement,

True, so maybe it should have not been a List, but rather a Set of Collection. 
Either of them is a better choice than Iterable.

> and in fact I was
> hoping to replace the implementation with a Set but I couldn't do that
> as we committed to a contract which exposes a List.

I am confused? If you are concerned about changing the API, why is the change
to Iterable ok, but not to Set?

> There also is a performance aspect. By returning List or Set, decency
> rules require me to wrap them in their immutable counterparts, or make
> defensive copies.

Shall I come with the premature optimisation argument now?

> Many of our internal contracts should be Iterable, especially if it's
> only about iterating _some collection_.

-1

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150306/30b89c65/attachment.bin 

From emmanuel at hibernate.org  Fri Mar  6 05:45:18 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 6 Mar 2015 11:45:18 +0100
Subject: [hibernate-dev] Returning Iterable
In-Reply-To: <CAFm4XO1mAfv2zEcFFMtS2s7oFaG6C4hfVsHfSwAeRzcAoSDk8A@mail.gmail.com>
References: <21A65FC8-061F-4665-ACBC-590836CBCA9B@hibernate.org>
	<CAFm4XO1mAfv2zEcFFMtS2s7oFaG6C4hfVsHfSwAeRzcAoSDk8A@mail.gmail.com>
Message-ID: <FE0066EE-6158-4B30-A5D6-C0DEC40AB7BE@hibernate.org>

I heard it the first time, no need to draw guns :)
I just added another viewpoint as I happened to also ponder Iterable vs dedicated API on another pull request. 


> On 6 mars 2015, at 11:01, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> I was already aware of that blog, and while he makes some interesting
> observations, I strongly disagree on it being a general rule. Like
> many of the people commenting on the blog post, and the author himself
> admits the title was too broad ;-)
> 
> First of, it's an SPI that we consume ourselves. We *know* that all we
> need is to iterate, and the "for each" idiom is all we need.
> Exposing a List in this case was an error, as it's a leaky
> abstraction: there is no ordering requirement, and in fact I was
> hoping to replace the implementation with a Set but I couldn't do that
> as we committed to a contract which exposes a List.
> 
> We all know the rules of encapsulation: expose the least possible, but
> no less... obviously the blog poster has a point in his case as he was
> bitten by the "no less" problem.
> I guess we all like encapsulation of classes, or we could as well move
> back to public static fields rather than accessors. And you all return
> "Set", and not "HashSet" right? Even though I often prefer to keep the
> private field to use the type of the concrete collection, as
> *privately* it may be useful (that's a case by case call).
> 
> You expose the highest abstraction which satisfies the need, aiming at
> a good balance of practicality for both the implementor of the
> contract and the consumer.
> 
> There also is a performance aspect. By returning List or Set, decency
> rules require me to wrap them in their immutable counterparts, or make
> defensive copies.
> But then when the collections' whole point is to actually mutate,
> you'd need to do such a wrap (or such a copy) on a per-invocation of
> the read.. even if you don't agree on it being a good enough
> performance reason, it adds on the readability of the code.
> Often that's not a big deal, still why do I need to pay for any cost
> if its reason to be is completely moot.
> 
> Many of our internal contracts should be Iterable, especially if it's
> only about iterating _some collection_.
> 
> It's different of course if you expose it as a domain model to a user
> API: in that case you don't really know what the use case's practical
> needs are going to need, and then like the blog states being able to
> run "size()" is often too compelling.
> 
> 
> 
>> On 6 March 2015 at 08:12, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> We had that debate in one of the PR. We ended up not returning it for other reasons.
>> A small additional stone to the discussion is here http://alexruiz.developerblogs.com/?p=2519
>> 
>> 
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From gunnar at hibernate.org  Fri Mar  6 06:05:43 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 6 Mar 2015 12:05:43 +0100
Subject: [hibernate-dev] Returning Iterable
In-Reply-To: <FE0066EE-6158-4B30-A5D6-C0DEC40AB7BE@hibernate.org>
References: <21A65FC8-061F-4665-ACBC-590836CBCA9B@hibernate.org>
	<CAFm4XO1mAfv2zEcFFMtS2s7oFaG6C4hfVsHfSwAeRzcAoSDk8A@mail.gmail.com>
	<FE0066EE-6158-4B30-A5D6-C0DEC40AB7BE@hibernate.org>
Message-ID: <CADGJaX8PZ6JCnbFjwkHwFzQPg4Y7KquGa4H1vkhAUhXSZYO4KA@mail.gmail.com>

Which case/change is this actually about?

I could swear we discussed that issue before a while ago and someone even
shared that very link.

Iterable IMO is good for things like result sets which you might not want
to have in memory all at once. Otherwise, I prefer returning Set/List which
makes the duplicate semantics apparent and are generally just more useful.
How do you know whether iterating really is the only thing users of a
method will do? It would help to know the case at hand.

It's a different thing for parameters of course. There I find Iterable good
if it is all I need as a method implementor: "Be conservative in what you
send, be liberal in what you accept".





2015-03-06 11:45 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> I heard it the first time, no need to draw guns :)
> I just added another viewpoint as I happened to also ponder Iterable vs
> dedicated API on another pull request.
>
>
> > On 6 mars 2015, at 11:01, Sanne Grinovero <sanne at hibernate.org> wrote:
> >
> > I was already aware of that blog, and while he makes some interesting
> > observations, I strongly disagree on it being a general rule. Like
> > many of the people commenting on the blog post, and the author himself
> > admits the title was too broad ;-)
> >
> > First of, it's an SPI that we consume ourselves. We *know* that all we
> > need is to iterate, and the "for each" idiom is all we need.
> > Exposing a List in this case was an error, as it's a leaky
> > abstraction: there is no ordering requirement, and in fact I was
> > hoping to replace the implementation with a Set but I couldn't do that
> > as we committed to a contract which exposes a List.
> >
> > We all know the rules of encapsulation: expose the least possible, but
> > no less... obviously the blog poster has a point in his case as he was
> > bitten by the "no less" problem.
> > I guess we all like encapsulation of classes, or we could as well move
> > back to public static fields rather than accessors. And you all return
> > "Set", and not "HashSet" right? Even though I often prefer to keep the
> > private field to use the type of the concrete collection, as
> > *privately* it may be useful (that's a case by case call).
> >
> > You expose the highest abstraction which satisfies the need, aiming at
> > a good balance of practicality for both the implementor of the
> > contract and the consumer.
> >
> > There also is a performance aspect. By returning List or Set, decency
> > rules require me to wrap them in their immutable counterparts, or make
> > defensive copies.
> > But then when the collections' whole point is to actually mutate,
> > you'd need to do such a wrap (or such a copy) on a per-invocation of
> > the read.. even if you don't agree on it being a good enough
> > performance reason, it adds on the readability of the code.
> > Often that's not a big deal, still why do I need to pay for any cost
> > if its reason to be is completely moot.
> >
> > Many of our internal contracts should be Iterable, especially if it's
> > only about iterating _some collection_.
> >
> > It's different of course if you expose it as a domain model to a user
> > API: in that case you don't really know what the use case's practical
> > needs are going to need, and then like the blog states being able to
> > run "size()" is often too compelling.
> >
> >
> >
> >> On 6 March 2015 at 08:12, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >> We had that debate in one of the PR. We ended up not returning it for
> other reasons.
> >> A small additional stone to the discussion is here
> http://alexruiz.developerblogs.com/?p=2519
> >>
> >>
> >> _______________________________________________
> >> 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
>

From steve at hibernate.org  Fri Mar  6 17:56:47 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 6 Mar 2015 16:56:47 -0600
Subject: [hibernate-dev] Scanning and META-INF/orm.xml
Message-ID: <CAFdSV9syhz6ibdYF97D9fLUR9RNegp_gR8i=4gen=7ddp+6wbw@mail.gmail.com>

Anyone remember why META-INF/orm.xml is handled specially in scanning?

I am having some trouble locally with scanning matching multiple sources
named META-INF/orm.xml and am trying to understand the reason we do what we
do here.

From emmanuel at hibernate.org  Mon Mar  9 06:18:06 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 9 Mar 2015 11:18:06 +0100
Subject: [hibernate-dev] Scanning and META-INF/orm.xml
In-Reply-To: <CAFdSV9syhz6ibdYF97D9fLUR9RNegp_gR8i=4gen=7ddp+6wbw@mail.gmail.com>
References: <CAFdSV9syhz6ibdYF97D9fLUR9RNegp_gR8i=4gen=7ddp+6wbw@mail.gmail.com>
Message-ID: <E9FA0271-C00E-482E-8314-3EB917168A76@hibernate.org>

AFAIR only the META-INF/orm.xml file present in the JAR containing META-INF/persistence.xml is handled automatically. Also <jar> references will be taken into account.

The spec mentions

An object/relational mapping XML file named orm.xml may be specified in the META-INF directory in the root of the persistence unit or in the META-INF directory of any jar file referenced by the persistence.xml.


> On 06 Mar 2015, at 23:56, Steve Ebersole <steve at hibernate.org> wrote:
> 
> Anyone remember why META-INF/orm.xml is handled specially in scanning?
> 
> I am having some trouble locally with scanning matching multiple sources
> named META-INF/orm.xml and am trying to understand the reason we do what we
> do here.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From smarlow at redhat.com  Mon Mar  9 14:19:48 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 09 Mar 2015 14:19:48 -0400
Subject: [hibernate-dev] new proposal for tx timeout handling using
 transaction DISASSOCIATING event notification...
Message-ID: <54FDE444.8060804@redhat.com>

With a proposed TM level listener, we will have an SPI for notification 
of when application threads associated with a JTA transaction, become 
disassociated with the transaction (tm.commit/rollback/suspend time). 
Having this knowledge in a synchronization callback, can determine 
whether the persistence context should be cleared directly from the 
Synchronization.afterCompletion(int) call or should be deferred until 
the transaction is disassociated from the JTA transaction.

This idea is based on a TM level listener approach that Tom Jenkinson 
[1] suggested.  Mike Musgrove has a "proof of concept" implementation of 
the suggested changes [2].  I did some testing with [3] to see if the 
improvement helps with clearing entities that might still be in the 
persistence context after a background tx timeout.

I'm wondering if in the Hibernate ORM 
Synchronization.afterCompletion(int status) implementation, in case of 
tx rollback, if we could defer the clearing of the Hibernate session to 
be handled by the JtaPlatform.  This could be setup at 
EntityManager.joinTransaction() time (if a new property like 
"hibernate.transaction.defer_clear_session" is true).  Perhaps via a 
JtaPlatform.joinTransaction(EntityManager) registration call?

Thoughts?

Scott

[1] https://developer.jboss.org/thread/252572?start=45&tstart=0

[2] 
https://github.com/mmusgrov/jboss-transaction-spi/blob/threadDisassociationListener/src/main/java/org/jboss/tm/

[3] 
https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut_noejb_wildfly9_march5_2015 


From hardy at hibernate.org  Mon Mar  9 17:52:26 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 9 Mar 2015 22:52:26 +0100
Subject: [hibernate-dev] Jira issues
Message-ID: <20150309215226.GA3450@Sarmakand-4.local>

Hi,

I seem to have problems with Jira atm. If I select a link which refers to a specific version
(eg https://hibernate.atlassian.net/projects/OGM/versions/19251), I keep getting a 500 error
with the message "Sorry, we had some technical problems during your last operation."

It does not seem to matter which project or releases vs unreleased version. 

Do you guys have the same problem? Any ideas on what's going on?

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150309/5e6c0d14/attachment.bin 

From steve at hibernate.org  Mon Mar  9 18:13:14 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 9 Mar 2015 17:13:14 -0500
Subject: [hibernate-dev] Jira issues
In-Reply-To: <20150309215226.GA3450@Sarmakand-4.local>
References: <20150309215226.GA3450@Sarmakand-4.local>
Message-ID: <CAFdSV9tqPQsKB-HbBagfp88etp3yuZ174-1vW6VwCa7YQQZfUg@mail.gmail.com>

Interesting.  I can get to that link from your email (just clicked it) just
fine.

On Mon, Mar 9, 2015 at 4:52 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> I seem to have problems with Jira atm. If I select a link which refers to
> a specific version
> (eg https://hibernate.atlassian.net/projects/OGM/versions/19251), I keep
> getting a 500 error
> with the message "Sorry, we had some technical problems during your last
> operation."
>
> It does not seem to matter which project or releases vs unreleased version.
>
> Do you guys have the same problem? Any ideas on what's going on?
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mih_vlad at yahoo.com  Mon Mar  9 18:13:26 2015
From: mih_vlad at yahoo.com (Mihalcea Vlad)
Date: Mon, 9 Mar 2015 22:13:26 +0000 (UTC)
Subject: [hibernate-dev] DefaultLockEventListener cascading
Message-ID: <561447730.1346312.1425939206788.JavaMail.yahoo@mail.yahoo.com>

Hi,
While investigating how Lock Cascading works, I realized that the lock "scope" is only applied for detached entities.
Object entity = source.getPersistenceContext().unproxyAndReassociate( event.getObject() );
//TODO: if object was an uninitialized proxy, this is inefficient,
//      resulting in two SQL selects

EntityEntry entry = source.getPersistenceContext().getEntry(entity);
if (entry==null) {
   final EntityPersister persister = source.getEntityPersister( event.getEntityName(), entity );
   final Serializable id = persister.getIdentifier( entity, source );
   if ( !ForeignKeys.isNotTransient( event.getEntityName(), entity, Boolean.FALSE, source ) ) {
      throw new TransientObjectException(
            "cannot lock an unsaved transient instance: " +
            persister.getEntityName()
      );
   }

   entry = reassociate(event, entity, id, persister);
   cascadeOnLock(event, persister, entity);
}

upgradeLock( entity, entry, event.getLockOptions(), event.getSession() );

If an entity is already attached, the Lock will only be applied to the request entity.
If the lock request entity is detached, then it will be:
- re-associated
- and the lock cascade will be propagated
The Cascade lock action looks like this:
LockMode lockMode = LockMode.NONE;
LockOptions lr = new LockOptions();
if ( anything instanceof LockOptions ) {
   LockOptions lockOptions = (LockOptions) anything;
   lr.setTimeOut( lockOptions.getTimeOut() );
   lr.setScope( lockOptions.getScope() );
   if ( lockOptions.getScope() ) {
      lockMode = lockOptions.getLockMode();
   }
}
lr.setLockMode( lockMode );
session.buildLockRequest( lr ).lock( entityName, child );So, if I specify a "scope" lock request I can propagate the lock to all child association (configured with CascadeType.ALL or CascadeType.LOCK):
Query:{[select id from Comment where id =? for update][1]} 
Query:{[select id from Comment where id =? for update][2]} 
Query:{[select id from PostDetails where id =? for update][1]}
Query:{[select id from Post where id =? for update][1]}?
Shouldn't this logic be consistent for both attached and detached entities?
The test is available on GitHub:
https://github.com/vladmihalcea/hibernate-master-class/blob/master/core/src/test/java/com/vladmihalcea/hibernate/masterclass/laboratory/concurrency/CascadeLockTest.java

Vlad Mihalcea

From hardy at hibernate.org  Mon Mar  9 18:29:15 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 9 Mar 2015 23:29:15 +0100
Subject: [hibernate-dev] Jira issues
In-Reply-To: <CAFdSV9tqPQsKB-HbBagfp88etp3yuZ174-1vW6VwCa7YQQZfUg@mail.gmail.com>
References: <20150309215226.GA3450@Sarmakand-4.local>
	<CAFdSV9tqPQsKB-HbBagfp88etp3yuZ174-1vW6VwCa7YQQZfUg@mail.gmail.com>
Message-ID: <20150309222914.GB3450@Sarmakand-4.local>

On Mon, Mar 09, 2015 at 05:13:14PM -0500, Steve Ebersole wrote:
> Interesting.  I can get to that link from your email (just clicked it) just
> fine.

Turns out, I can get to these links as well - provided I am logged in.
I think my session must had expired and I was not logged in when I tried. 

If I log out, I am still not able to access these links, but I guess they
should be accessible even without login, right?

Could you check whether you can access the link when you log off?

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150309/357c323d/attachment.bin 

From steve at hibernate.org  Mon Mar  9 18:35:07 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 9 Mar 2015 17:35:07 -0500
Subject: [hibernate-dev] Jira issues
In-Reply-To: <20150309222914.GB3450@Sarmakand-4.local>
References: <20150309215226.GA3450@Sarmakand-4.local>
	<CAFdSV9tqPQsKB-HbBagfp88etp3yuZ174-1vW6VwCa7YQQZfUg@mail.gmail.com>
	<20150309222914.GB3450@Sarmakand-4.local>
Message-ID: <CAFdSV9sdwWzKuYJFV=kOW=PLiwgyYPmh+UiuivEohijCKdik7g@mail.gmail.com>

Ok, if I log out I get the same.  We'll have to reach out to Atlassian
about this.  Or maybe there is a setting as to whether this should be
publicly available.

On Mon, Mar 9, 2015 at 5:29 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> On Mon, Mar 09, 2015 at 05:13:14PM -0500, Steve Ebersole wrote:
> > Interesting.  I can get to that link from your email (just clicked it)
> just
> > fine.
>
> Turns out, I can get to these links as well - provided I am logged in.
> I think my session must had expired and I was not logged in when I tried.
>
> If I log out, I am still not able to access these links, but I guess they
> should be accessible even without login, right?
>
> Could you check whether you can access the link when you log off?
>
> --Hardy
>

From steve at hibernate.org  Mon Mar  9 22:26:34 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 9 Mar 2015 21:26:34 -0500
Subject: [hibernate-dev] Jira issues
In-Reply-To: <CAFdSV9sdwWzKuYJFV=kOW=PLiwgyYPmh+UiuivEohijCKdik7g@mail.gmail.com>
References: <20150309215226.GA3450@Sarmakand-4.local>
	<CAFdSV9tqPQsKB-HbBagfp88etp3yuZ174-1vW6VwCa7YQQZfUg@mail.gmail.com>
	<20150309222914.GB3450@Sarmakand-4.local>
	<CAFdSV9sdwWzKuYJFV=kOW=PLiwgyYPmh+UiuivEohijCKdik7g@mail.gmail.com>
Message-ID: <CAFdSV9vH89bBv0dANcuboNGyYqFt+B+9X68BdocL5ihqFr6Wtw@mail.gmail.com>

I tried using the feedback approach with Atlassian, lets see how that goes
and whether we hear back.  If I don't hear back in a few days, I will reach
out to them directly.



On Mon, Mar 9, 2015 at 5:35 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Ok, if I log out I get the same.  We'll have to reach out to Atlassian
> about this.  Or maybe there is a setting as to whether this should be
> publicly available.
>
> On Mon, Mar 9, 2015 at 5:29 PM, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
>
>> On Mon, Mar 09, 2015 at 05:13:14PM -0500, Steve Ebersole wrote:
>> > Interesting.  I can get to that link from your email (just clicked it)
>> just
>> > fine.
>>
>> Turns out, I can get to these links as well - provided I am logged in.
>> I think my session must had expired and I was not logged in when I tried.
>>
>> If I log out, I am still not able to access these links, but I guess they
>> should be accessible even without login, right?
>>
>> Could you check whether you can access the link when you log off?
>>
>> --Hardy
>>
>
>

From hardy at hibernate.org  Tue Mar 10 05:57:09 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 10 Mar 2015 10:57:09 +0100
Subject: [hibernate-dev] Jira issues
In-Reply-To: <CAFdSV9vH89bBv0dANcuboNGyYqFt+B+9X68BdocL5ihqFr6Wtw@mail.gmail.com>
References: <20150309215226.GA3450@Sarmakand-4.local>
	<CAFdSV9tqPQsKB-HbBagfp88etp3yuZ174-1vW6VwCa7YQQZfUg@mail.gmail.com>
	<20150309222914.GB3450@Sarmakand-4.local>
	<CAFdSV9sdwWzKuYJFV=kOW=PLiwgyYPmh+UiuivEohijCKdik7g@mail.gmail.com>
	<CAFdSV9vH89bBv0dANcuboNGyYqFt+B+9X68BdocL5ihqFr6Wtw@mail.gmail.com>
Message-ID: <20150310095709.GA5025@Sarmakand-4.local>

On Mon, Mar 09, 2015 at 09:26:34PM -0500, Steve Ebersole wrote:
> I tried using the feedback approach with Atlassian, lets see how that goes
> and whether we hear back.  If I don't hear back in a few days, I will reach
> out to them directly.

+1 I guess this is related to their latest changes. Maybe there was more to it
than some simple UI changes?

--Hardy 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150310/f33de11c/attachment-0001.bin 

From gunnar at hibernate.org  Tue Mar 10 09:03:51 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 10 Mar 2015 14:03:51 +0100
Subject: [hibernate-dev] JTA synchronizations on WildFly
Message-ID: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>

Hi,

I'm trying to perform a specific action upon transaction rollback.

Assuming this could be done using a custom
javax.transaction.Synchronization, I tried to register a synchronization as
follows:

    TransactionImplementor transaction = ...; // e.g. a CMTTransaction
    transaction.registerSynchronization( new MySync() );

And indeed beforeCompletion() is invoked as expected. But afterCompletion()
never is. I debugged this a bit on WildFly and observed the following:

* Hibernate ORM registers RegisteredSynchronization with JTA.
RegisteredSynchronization manages (indirectly, through
TransactionCoordinator, SynchronizationRegistry etc.) those
synchronizations added through o.h.t.Transaction.registerSynchronization()
* WildFly (specifically, TransactionUtil [1]) registers its own
SessionSynchronization
for closing the entity manager/session

Now that second synchronization is called first, closing the session. Upon
SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
afterComplection() is called on RegisteredSynchronization afterwards, any
previously registered delegate synchronizations are gone already and thus
do not get invoked.

I believe I found a workaround for my case by registering my
synchronization through JtaPlatform#registerSynchronization() (which
registers it with the actual JTA transaction).

My questions are:

* Is this behaviour expected?
* Is the work-around of doing the registration via JtaPlatform viable or
are there any drawbacks which I'm not aware of?

Thanks,

--Gunnar

[1]
https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java

From smarlow at redhat.com  Tue Mar 10 09:39:05 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 10 Mar 2015 09:39:05 -0400
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
Message-ID: <54FEF3F9.9090204@redhat.com>

Hi Gunnar,

Yes, this behaviour is expected since you registered an non-interposed 
synchronization.  For what purpose are you registering the transaction 
synchronization?  I would like to be aware of the synchronizations that 
we register in WildFly.

The non-interposed sync beforeCompletion callback are invoked first, 
then the interposed sync beforeCompletion calls, then the interposed 
afterCompletion(int status) calls and finally, the non-interposed 
afterCompletion(int status) calls.

The Synchronizations that are registered via the 
javax.transaction.TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization) 
[2] are interposed.

Synchronizations that are registered via the 
javax.transaction.Transaction.registerSynchronization(Synchronization) 
[3] are non-interposed.

In WildFly, the transaction manager uses the registration order within 
the interposed/non-interposed group.  Before completion syncs (within 
their respective group), are run in registration order.  After 
completion syncs (within their respective group), are run in reverse 
registration order.

I believe that your workaround, mentioned below, of using 
JtaPlatform#registerSynchronization() on WildFly, is registering your 
synchronization as interposed via the TransactionSynchronizationRegistry 
[2]. There might be a way to register a sync callback at the Hibernate 
session level (which would also run as interposed sync on WildFly).

Not sure if you saw my email yesterday to Hibernate-dev ml.  You should 
be aware that the afterCompletion(int status) callback, may be called 
from a non-application thread when the WildFly tm reaper handles tx 
timeout (this can happen while the application thread is still invoking 
calls on the Hibernate session).  Because the Hibernate session is not 
thread safe, we need to ensure that the Hibernate session 
afterCompletion(int status) callback does not mutate the Hibernate 
session (e.g. calling session.clear() what status == rolled back).

Scott

[2] 
http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html#registerInterposedSynchronization%28javax.transaction.Synchronization%29

[3] 
http://docs.oracle.com/javaee/5/api/javax/transaction/Transaction.html#registerSynchronization%28javax.transaction.Synchronization%29

On 03/10/2015 09:03 AM, Gunnar Morling wrote:
> Hi,
>
> I'm trying to perform a specific action upon transaction rollback.
>
> Assuming this could be done using a custom
> javax.transaction.Synchronization, I tried to register a synchronization as
> follows:
>
>      TransactionImplementor transaction = ...; // e.g. a CMTTransaction
>      transaction.registerSynchronization( new MySync() );
>
> And indeed beforeCompletion() is invoked as expected. But afterCompletion()
> never is. I debugged this a bit on WildFly and observed the following:
>
> * Hibernate ORM registers RegisteredSynchronization with JTA.
> RegisteredSynchronization manages (indirectly, through
> TransactionCoordinator, SynchronizationRegistry etc.) those
> synchronizations added through o.h.t.Transaction.registerSynchronization()
> * WildFly (specifically, TransactionUtil [1]) registers its own
> SessionSynchronization
> for closing the entity manager/session
>
> Now that second synchronization is called first, closing the session. Upon
> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
> afterComplection() is called on RegisteredSynchronization afterwards, any
> previously registered delegate synchronizations are gone already and thus
> do not get invoked.
>
> I believe I found a workaround for my case by registering my
> synchronization through JtaPlatform#registerSynchronization() (which
> registers it with the actual JTA transaction).
>
> My questions are:
>
> * Is this behaviour expected?
> * Is the work-around of doing the registration via JtaPlatform viable or
> are there any drawbacks which I'm not aware of?
>
> Thanks,
>
> --Gunnar
>
> [1]
> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Tue Mar 10 10:12:52 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 10 Mar 2015 15:12:52 +0100
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <54FEF3F9.9090204@redhat.com>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
	<54FEF3F9.9090204@redhat.com>
Message-ID: <1C6C422E-1B20-4421-A8AB-EA8C6542CCBC@hibernate.org>

So Gunnar, your workaround is fine today but will pose problems in the future if we decide that onRollback for ErrorHandler needs access to the session somehow to be able to compensate and undo the already executed operations:
- a closed session will do us no good
- there is a harder problem that Scott mentions below related to tx reaping in a different thread

Let?s try and find a solution for the first problem.

@Scott, I think what happens is the following:

- Hibernate registers a Sync when the EM is created (for the flush() callbacks and a few other things)
- Synchronization attached to the Hibernate Transaction objects are piggybacking on that initial Sync attachement
- Wildfly attach a ?close session? Sync once it has the instance of EntityManager
- according to your rules, the close session afterTransaction Sync is called before the one Hibernate put
- that explains why Gunnar finds an already closed Tx.

But since Gunnar attaches its Sync when the Hibernate TransactionCoordinator creates the Hibernate transaction, which is when the EM is created, I can?t explain why the workaround works.

Emmanuel

> On 10 Mar 2015, at 14:39, Scott Marlow <smarlow at redhat.com> wrote:
> 
> Hi Gunnar,
> 
> Yes, this behaviour is expected since you registered an non-interposed 
> synchronization.  For what purpose are you registering the transaction 
> synchronization?  I would like to be aware of the synchronizations that 
> we register in WildFly.
> 
> The non-interposed sync beforeCompletion callback are invoked first, 
> then the interposed sync beforeCompletion calls, then the interposed 
> afterCompletion(int status) calls and finally, the non-interposed 
> afterCompletion(int status) calls.
> 
> The Synchronizations that are registered via the 
> javax.transaction.TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization) 
> [2] are interposed.
> 
> Synchronizations that are registered via the 
> javax.transaction.Transaction.registerSynchronization(Synchronization) 
> [3] are non-interposed.
> 
> In WildFly, the transaction manager uses the registration order within 
> the interposed/non-interposed group.  Before completion syncs (within 
> their respective group), are run in registration order.  After 
> completion syncs (within their respective group), are run in reverse 
> registration order.
> 
> I believe that your workaround, mentioned below, of using 
> JtaPlatform#registerSynchronization() on WildFly, is registering your 
> synchronization as interposed via the TransactionSynchronizationRegistry 
> [2]. There might be a way to register a sync callback at the Hibernate 
> session level (which would also run as interposed sync on WildFly).
> 
> Not sure if you saw my email yesterday to Hibernate-dev ml.  You should 
> be aware that the afterCompletion(int status) callback, may be called 
> from a non-application thread when the WildFly tm reaper handles tx 
> timeout (this can happen while the application thread is still invoking 
> calls on the Hibernate session).  Because the Hibernate session is not 
> thread safe, we need to ensure that the Hibernate session 
> afterCompletion(int status) callback does not mutate the Hibernate 
> session (e.g. calling session.clear() what status == rolled back).
> 
> Scott
> 
> [2] 
> http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html#registerInterposedSynchronization%28javax.transaction.Synchronization%29
> 
> [3] 
> http://docs.oracle.com/javaee/5/api/javax/transaction/Transaction.html#registerSynchronization%28javax.transaction.Synchronization%29
> 
> On 03/10/2015 09:03 AM, Gunnar Morling wrote:
>> Hi,
>> 
>> I'm trying to perform a specific action upon transaction rollback.
>> 
>> Assuming this could be done using a custom
>> javax.transaction.Synchronization, I tried to register a synchronization as
>> follows:
>> 
>>     TransactionImplementor transaction = ...; // e.g. a CMTTransaction
>>     transaction.registerSynchronization( new MySync() );
>> 
>> And indeed beforeCompletion() is invoked as expected. But afterCompletion()
>> never is. I debugged this a bit on WildFly and observed the following:
>> 
>> * Hibernate ORM registers RegisteredSynchronization with JTA.
>> RegisteredSynchronization manages (indirectly, through
>> TransactionCoordinator, SynchronizationRegistry etc.) those
>> synchronizations added through o.h.t.Transaction.registerSynchronization()
>> * WildFly (specifically, TransactionUtil [1]) registers its own
>> SessionSynchronization
>> for closing the entity manager/session
>> 
>> Now that second synchronization is called first, closing the session. Upon
>> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
>> afterComplection() is called on RegisteredSynchronization afterwards, any
>> previously registered delegate synchronizations are gone already and thus
>> do not get invoked.
>> 
>> I believe I found a workaround for my case by registering my
>> synchronization through JtaPlatform#registerSynchronization() (which
>> registers it with the actual JTA transaction).
>> 
>> My questions are:
>> 
>> * Is this behaviour expected?
>> * Is the work-around of doing the registration via JtaPlatform viable or
>> are there any drawbacks which I'm not aware of?
>> 
>> Thanks,
>> 
>> --Gunnar
>> 
>> [1]
>> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
>> _______________________________________________
>> 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



From emmanuel at hibernate.org  Tue Mar 10 10:15:42 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 10 Mar 2015 15:15:42 +0100
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <54FEF3F9.9090204@redhat.com>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
	<54FEF3F9.9090204@redhat.com>
Message-ID: <1E22E633-CFF9-407C-8679-111DC08E5521@hibernate.org>

Scott, for Hibernate OGM and for non transactional datastores, we collect the list of executed operations and offer the list if the user calls Hibernate?s transaction.rollback() or if the JTA transaction is rollbacked. Note that the JTA transaction has no resource attached to it since the datastore is non transactional, we just piggyback on the begin / commit lifecycle without their true semantic.
This feature is called the ErrorHandling or Compensation API in OGM. That?s why we want to attach a Synchronization.

> On 10 Mar 2015, at 14:39, Scott Marlow <smarlow at redhat.com> wrote:
> 
> Hi Gunnar,
> 
> Yes, this behaviour is expected since you registered an non-interposed 
> synchronization.  For what purpose are you registering the transaction 
> synchronization?  I would like to be aware of the synchronizations that 
> we register in WildFly.
> 
> The non-interposed sync beforeCompletion callback are invoked first, 
> then the interposed sync beforeCompletion calls, then the interposed 
> afterCompletion(int status) calls and finally, the non-interposed 
> afterCompletion(int status) calls.
> 
> The Synchronizations that are registered via the 
> javax.transaction.TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization) 
> [2] are interposed.
> 
> Synchronizations that are registered via the 
> javax.transaction.Transaction.registerSynchronization(Synchronization) 
> [3] are non-interposed.
> 
> In WildFly, the transaction manager uses the registration order within 
> the interposed/non-interposed group.  Before completion syncs (within 
> their respective group), are run in registration order.  After 
> completion syncs (within their respective group), are run in reverse 
> registration order.
> 
> I believe that your workaround, mentioned below, of using 
> JtaPlatform#registerSynchronization() on WildFly, is registering your 
> synchronization as interposed via the TransactionSynchronizationRegistry 
> [2]. There might be a way to register a sync callback at the Hibernate 
> session level (which would also run as interposed sync on WildFly).
> 
> Not sure if you saw my email yesterday to Hibernate-dev ml.  You should 
> be aware that the afterCompletion(int status) callback, may be called 
> from a non-application thread when the WildFly tm reaper handles tx 
> timeout (this can happen while the application thread is still invoking 
> calls on the Hibernate session).  Because the Hibernate session is not 
> thread safe, we need to ensure that the Hibernate session 
> afterCompletion(int status) callback does not mutate the Hibernate 
> session (e.g. calling session.clear() what status == rolled back).
> 
> Scott
> 
> [2] 
> http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html#registerInterposedSynchronization%28javax.transaction.Synchronization%29
> 
> [3] 
> http://docs.oracle.com/javaee/5/api/javax/transaction/Transaction.html#registerSynchronization%28javax.transaction.Synchronization%29
> 
> On 03/10/2015 09:03 AM, Gunnar Morling wrote:
>> Hi,
>> 
>> I'm trying to perform a specific action upon transaction rollback.
>> 
>> Assuming this could be done using a custom
>> javax.transaction.Synchronization, I tried to register a synchronization as
>> follows:
>> 
>>     TransactionImplementor transaction = ...; // e.g. a CMTTransaction
>>     transaction.registerSynchronization( new MySync() );
>> 
>> And indeed beforeCompletion() is invoked as expected. But afterCompletion()
>> never is. I debugged this a bit on WildFly and observed the following:
>> 
>> * Hibernate ORM registers RegisteredSynchronization with JTA.
>> RegisteredSynchronization manages (indirectly, through
>> TransactionCoordinator, SynchronizationRegistry etc.) those
>> synchronizations added through o.h.t.Transaction.registerSynchronization()
>> * WildFly (specifically, TransactionUtil [1]) registers its own
>> SessionSynchronization
>> for closing the entity manager/session
>> 
>> Now that second synchronization is called first, closing the session. Upon
>> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
>> afterComplection() is called on RegisteredSynchronization afterwards, any
>> previously registered delegate synchronizations are gone already and thus
>> do not get invoked.
>> 
>> I believe I found a workaround for my case by registering my
>> synchronization through JtaPlatform#registerSynchronization() (which
>> registers it with the actual JTA transaction).
>> 
>> My questions are:
>> 
>> * Is this behaviour expected?
>> * Is the work-around of doing the registration via JtaPlatform viable or
>> are there any drawbacks which I'm not aware of?
>> 
>> Thanks,
>> 
>> --Gunnar
>> 
>> [1]
>> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
>> _______________________________________________
>> 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



From emmanuel at hibernate.org  Tue Mar 10 09:14:11 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 10 Mar 2015 14:14:11 +0100
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
Message-ID: <EDD8860D-D178-40C2-8C71-37FE02328EBE@hibernate.org>

Ah synchronization ordering, it never gets old :) Steve might remember better but I don?t think we ever managed to convice the tx team to offer guaranteed ordering.

Your workaround seems fine (if there is a JtaPlaform) but when we add more logic to your onRollback calls, we might want to offer access tot he Session to try compensating for example. In which case, we would be in trouble with the closed session. I don?t have a good idea.

I am a bit surprised WildFly closes the session but that might be per spec that the container manages these calls.

> On 10 Mar 2015, at 14:03, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hi,
> 
> I'm trying to perform a specific action upon transaction rollback.
> 
> Assuming this could be done using a custom
> javax.transaction.Synchronization, I tried to register a synchronization as
> follows:
> 
>    TransactionImplementor transaction = ...; // e.g. a CMTTransaction
>    transaction.registerSynchronization( new MySync() );
> 
> And indeed beforeCompletion() is invoked as expected. But afterCompletion()
> never is. I debugged this a bit on WildFly and observed the following:
> 
> * Hibernate ORM registers RegisteredSynchronization with JTA.
> RegisteredSynchronization manages (indirectly, through
> TransactionCoordinator, SynchronizationRegistry etc.) those
> synchronizations added through o.h.t.Transaction.registerSynchronization()
> * WildFly (specifically, TransactionUtil [1]) registers its own
> SessionSynchronization
> for closing the entity manager/session
> 
> Now that second synchronization is called first, closing the session. Upon
> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
> afterComplection() is called on RegisteredSynchronization afterwards, any
> previously registered delegate synchronizations are gone already and thus
> do not get invoked.
> 
> I believe I found a workaround for my case by registering my
> synchronization through JtaPlatform#registerSynchronization() (which
> registers it with the actual JTA transaction).
> 
> My questions are:
> 
> * Is this behaviour expected?
> * Is the work-around of doing the registration via JtaPlatform viable or
> are there any drawbacks which I'm not aware of?
> 
> Thanks,
> 
> --Gunnar
> 
> [1]
> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From smarlow at redhat.com  Tue Mar 10 10:53:34 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 10 Mar 2015 10:53:34 -0400
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <1C6C422E-1B20-4421-A8AB-EA8C6542CCBC@hibernate.org>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
	<54FEF3F9.9090204@redhat.com>
	<1C6C422E-1B20-4421-A8AB-EA8C6542CCBC@hibernate.org>
Message-ID: <54FF056E.10909@redhat.com>



On 03/10/2015 10:12 AM, Emmanuel Bernard wrote:
> So Gunnar, your workaround is fine today but will pose problems in the future if we decide that onRollback for ErrorHandler needs access to the session somehow to be able to compensate and undo the already executed operations:
> - a closed session will do us no good
> - there is a harder problem that Scott mentions below related to tx reaping in a different thread
>
> Let?s try and find a solution for the first problem.
>
> @Scott, I think what happens is the following:
>
> - Hibernate registers a Sync when the EM is created (for the flush() callbacks and a few other things)
> - Synchronization attached to the Hibernate Transaction objects are piggybacking on that initial Sync attachement
> - Wildfly attach a ?close session? Sync once it has the instance of EntityManager
> - according to your rules, the close session afterTransaction Sync is called before the one Hibernate put
> - that explains why Gunnar finds an already closed Tx.
>
> But since Gunnar attaches its Sync when the Hibernate TransactionCoordinator creates the Hibernate transaction, which is when the EM is created, I can?t explain why the workaround works.

Because Gunnar initially registered the Sync, via [3] 
javax.transaction.Transaction.registerSynchronization(Sync), which might 
be correct in some non-WildFly environments where perhaps all Syncs are 
registered via [3] (as non-interposed syncs).  When Gunnar, switched to 
the Hibernate JtaPlatform mechanism for registering the Sync, we then 
switched to an interposed Sync.  I suspect that the JtaPlatform sync 
registration is a good way to register the OGM, however, I have been 
told that the *best* way is to register only one sync (to avoid ordering 
issues).

If OGM could register to share the existing Hibernate EM sync, we would 
have more control over when the OGM sync is invoked and in which thread 
(application versus background tm reaping thread).

Regarding the proposed "new proposal for tx timeout handling using 
transaction DISASSOCIATING event notification" discussion and how that 
could impact OGM.  We will continue to run the interposed/non-interposed 
sync callbacks in whatever thread the TM, calls them from (e.g. 
beforeCompletion may or may not be called from app thread, 
afterCompletion will be called from either app thread, background 
reaping thread or background communications thread).  The reason is that 
certain resources need to be cleaned up immediately from the 
Sync.afterCompletion(int status) call.  Certain other resources (like 
clearing managed entities from persistence context after a rollback), 
need to be handled from either the application thread or a background 
thread after the application thread is disassociated from the JTA 
transaction.

IMO, the OGM ErrorHandling/Compensation API probably needs to be aware 
of the same concurrency requirements to avoid presenting the executed 
operations list, while the application thread is still executing new 
operations (because it perhaps doesn't yet know that the tx rolled back).

It would be good to know if OGM will also need the concurrency 
protection, so that any new Hibernate 5.0 SPI can be used by OGM (e.g. 
currently the only need is to run the Hibernate Session.clear when we 
know that the application thread is not actively using the Session).

>
> Emmanuel
>
>> On 10 Mar 2015, at 14:39, Scott Marlow <smarlow at redhat.com> wrote:
>>
>> Hi Gunnar,
>>
>> Yes, this behaviour is expected since you registered an non-interposed
>> synchronization.  For what purpose are you registering the transaction
>> synchronization?  I would like to be aware of the synchronizations that
>> we register in WildFly.
>>
>> The non-interposed sync beforeCompletion callback are invoked first,
>> then the interposed sync beforeCompletion calls, then the interposed
>> afterCompletion(int status) calls and finally, the non-interposed
>> afterCompletion(int status) calls.
>>
>> The Synchronizations that are registered via the
>> javax.transaction.TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization)
>> [2] are interposed.
>>
>> Synchronizations that are registered via the
>> javax.transaction.Transaction.registerSynchronization(Synchronization)
>> [3] are non-interposed.
>>
>> In WildFly, the transaction manager uses the registration order within
>> the interposed/non-interposed group.  Before completion syncs (within
>> their respective group), are run in registration order.  After
>> completion syncs (within their respective group), are run in reverse
>> registration order.
>>
>> I believe that your workaround, mentioned below, of using
>> JtaPlatform#registerSynchronization() on WildFly, is registering your
>> synchronization as interposed via the TransactionSynchronizationRegistry
>> [2]. There might be a way to register a sync callback at the Hibernate
>> session level (which would also run as interposed sync on WildFly).
>>
>> Not sure if you saw my email yesterday to Hibernate-dev ml.  You should
>> be aware that the afterCompletion(int status) callback, may be called
>> from a non-application thread when the WildFly tm reaper handles tx
>> timeout (this can happen while the application thread is still invoking
>> calls on the Hibernate session).  Because the Hibernate session is not
>> thread safe, we need to ensure that the Hibernate session
>> afterCompletion(int status) callback does not mutate the Hibernate
>> session (e.g. calling session.clear() what status == rolled back).
>>
>> Scott
>>
>> [2]
>> http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html#registerInterposedSynchronization%28javax.transaction.Synchronization%29
>>
>> [3]
>> http://docs.oracle.com/javaee/5/api/javax/transaction/Transaction.html#registerSynchronization%28javax.transaction.Synchronization%29
>>
>> On 03/10/2015 09:03 AM, Gunnar Morling wrote:
>>> Hi,
>>>
>>> I'm trying to perform a specific action upon transaction rollback.
>>>
>>> Assuming this could be done using a custom
>>> javax.transaction.Synchronization, I tried to register a synchronization as
>>> follows:
>>>
>>>      TransactionImplementor transaction = ...; // e.g. a CMTTransaction
>>>      transaction.registerSynchronization( new MySync() );
>>>
>>> And indeed beforeCompletion() is invoked as expected. But afterCompletion()
>>> never is. I debugged this a bit on WildFly and observed the following:
>>>
>>> * Hibernate ORM registers RegisteredSynchronization with JTA.
>>> RegisteredSynchronization manages (indirectly, through
>>> TransactionCoordinator, SynchronizationRegistry etc.) those
>>> synchronizations added through o.h.t.Transaction.registerSynchronization()
>>> * WildFly (specifically, TransactionUtil [1]) registers its own
>>> SessionSynchronization
>>> for closing the entity manager/session
>>>
>>> Now that second synchronization is called first, closing the session. Upon
>>> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
>>> afterComplection() is called on RegisteredSynchronization afterwards, any
>>> previously registered delegate synchronizations are gone already and thus
>>> do not get invoked.
>>>
>>> I believe I found a workaround for my case by registering my
>>> synchronization through JtaPlatform#registerSynchronization() (which
>>> registers it with the actual JTA transaction).
>>>
>>> My questions are:
>>>
>>> * Is this behaviour expected?
>>> * Is the work-around of doing the registration via JtaPlatform viable or
>>> are there any drawbacks which I'm not aware of?
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>>
>>> [1]
>>> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
>>> _______________________________________________
>>> 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
>

From smarlow at redhat.com  Tue Mar 10 11:11:36 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 10 Mar 2015 11:11:36 -0400
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <EDD8860D-D178-40C2-8C71-37FE02328EBE@hibernate.org>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
	<EDD8860D-D178-40C2-8C71-37FE02328EBE@hibernate.org>
Message-ID: <54FF09A8.104@redhat.com>

I just saw the below email response after I sent the last one.  Sorry 
about that, will respond here also.  :)

On 03/10/2015 09:14 AM, Emmanuel Bernard wrote:
> Ah synchronization ordering, it never gets old :) Steve might remember better but I don?t think we ever managed to convice the tx team to offer guaranteed ordering.

We started discussing synchronization ordering as well (within the 
interposed group) and there is a WildFly specific code change being 
worked on to always run the JCA sync last (so IronJacamar can delist a 
resource that would of otherwise been leaked).

>
> Your workaround seems fine (if there is a JtaPlaform) but when we add more logic to your onRollback calls, we might want to offer access tot he Session to try compensating for example. In which case, we would be in trouble with the closed session. I don?t have a good idea.

Hmm, for the new SPI that deals with registering "concurrency safe" 
OnRollback calls, I wonder if we should have an ordering priority, so 
that the session clear/OGM operations list presentation, can always run 
before the JPA container closes the session.  In a discussion about 
changing the TM level Sync ordering for an unknown set of Syncs, we 
talked about specifying an ordering priority for registered Syncs, that 
idea will probably be useful for ordering the OnRollback calls if we 
enable that.

>
> I am a bit surprised WildFly closes the session but that might be per spec that the container manages these calls.

Yes, only for a transaction scoped entity manager, do we have to close 
the session after the transaction ends.  We don't do this for 
application managed (application needs to call EM.close()).  For 
extended persistence contexts, we close the session, after the last 
referencing stateful bean is destroyed (tracking is done in the JPA 
container).

Scott

>
>> On 10 Mar 2015, at 14:03, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Hi,
>>
>> I'm trying to perform a specific action upon transaction rollback.
>>
>> Assuming this could be done using a custom
>> javax.transaction.Synchronization, I tried to register a synchronization as
>> follows:
>>
>>     TransactionImplementor transaction = ...; // e.g. a CMTTransaction
>>     transaction.registerSynchronization( new MySync() );
>>
>> And indeed beforeCompletion() is invoked as expected. But afterCompletion()
>> never is. I debugged this a bit on WildFly and observed the following:
>>
>> * Hibernate ORM registers RegisteredSynchronization with JTA.
>> RegisteredSynchronization manages (indirectly, through
>> TransactionCoordinator, SynchronizationRegistry etc.) those
>> synchronizations added through o.h.t.Transaction.registerSynchronization()
>> * WildFly (specifically, TransactionUtil [1]) registers its own
>> SessionSynchronization
>> for closing the entity manager/session
>>
>> Now that second synchronization is called first, closing the session. Upon
>> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
>> afterComplection() is called on RegisteredSynchronization afterwards, any
>> previously registered delegate synchronizations are gone already and thus
>> do not get invoked.
>>
>> I believe I found a workaround for my case by registering my
>> synchronization through JtaPlatform#registerSynchronization() (which
>> registers it with the actual JTA transaction).
>>
>> My questions are:
>>
>> * Is this behaviour expected?
>> * Is the work-around of doing the registration via JtaPlatform viable or
>> are there any drawbacks which I'm not aware of?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
>> _______________________________________________
>> 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
>

From steve at hibernate.org  Tue Mar 10 11:32:48 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 10 Mar 2015 10:32:48 -0500
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <54FEF3F9.9090204@redhat.com>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
	<54FEF3F9.9090204@redhat.com>
Message-ID: <CAFdSV9tX2JKZ_T4pEBWAbGSfQAR-YuWPPD6nid+PMBRH9Pn5xw@mail.gmail.com>

On Tue, Mar 10, 2015 at 8:39 AM, Scott Marlow <smarlow at redhat.com> wrote:
>
>
> I believe that your workaround, mentioned below, of using
> JtaPlatform#registerSynchronization() on WildFly, is registering your
> synchronization as interposed via the TransactionSynchronizationRegistry
> [2]. There might be a way to register a sync callback at the Hibernate
> session level (which would also run as interposed sync on WildFly).


If you register syncs via the Hibernate Transaction API
(session.getTransaction().registerSynchronization()) these will be kept
local to the Session.  They are then delegated to in response to all
transaction events, whether that comes from a Transaction API call or JTA
sync callback.

From steve at hibernate.org  Tue Mar 10 11:36:01 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 10 Mar 2015 10:36:01 -0500
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <54FF09A8.104@redhat.com>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
	<EDD8860D-D178-40C2-8C71-37FE02328EBE@hibernate.org>
	<54FF09A8.104@redhat.com>
Message-ID: <CAFdSV9syf4Dz0_0DuPa5WbKo8VPuVLi9Ytori8LSJNRrNsmRaQ@mail.gmail.com>

Isn't the general approach is for "compensating actions" to be run in a
separate transaction?

On Tue, Mar 10, 2015 at 10:11 AM, Scott Marlow <smarlow at redhat.com> wrote:

> I just saw the below email response after I sent the last one.  Sorry
> about that, will respond here also.  :)
>
> On 03/10/2015 09:14 AM, Emmanuel Bernard wrote:
> > Ah synchronization ordering, it never gets old :) Steve might remember
> better but I don?t think we ever managed to convice the tx team to offer
> guaranteed ordering.
>
> We started discussing synchronization ordering as well (within the
> interposed group) and there is a WildFly specific code change being
> worked on to always run the JCA sync last (so IronJacamar can delist a
> resource that would of otherwise been leaked).
>
> >
> > Your workaround seems fine (if there is a JtaPlaform) but when we add
> more logic to your onRollback calls, we might want to offer access tot he
> Session to try compensating for example. In which case, we would be in
> trouble with the closed session. I don?t have a good idea.
>
> Hmm, for the new SPI that deals with registering "concurrency safe"
> OnRollback calls, I wonder if we should have an ordering priority, so
> that the session clear/OGM operations list presentation, can always run
> before the JPA container closes the session.  In a discussion about
> changing the TM level Sync ordering for an unknown set of Syncs, we
> talked about specifying an ordering priority for registered Syncs, that
> idea will probably be useful for ordering the OnRollback calls if we
> enable that.
>
> >
> > I am a bit surprised WildFly closes the session but that might be per
> spec that the container manages these calls.
>
> Yes, only for a transaction scoped entity manager, do we have to close
> the session after the transaction ends.  We don't do this for
> application managed (application needs to call EM.close()).  For
> extended persistence contexts, we close the session, after the last
> referencing stateful bean is destroyed (tracking is done in the JPA
> container).
>
> Scott
>
> >
> >> On 10 Mar 2015, at 14:03, Gunnar Morling <gunnar at hibernate.org> wrote:
> >>
> >> Hi,
> >>
> >> I'm trying to perform a specific action upon transaction rollback.
> >>
> >> Assuming this could be done using a custom
> >> javax.transaction.Synchronization, I tried to register a
> synchronization as
> >> follows:
> >>
> >>     TransactionImplementor transaction = ...; // e.g. a CMTTransaction
> >>     transaction.registerSynchronization( new MySync() );
> >>
> >> And indeed beforeCompletion() is invoked as expected. But
> afterCompletion()
> >> never is. I debugged this a bit on WildFly and observed the following:
> >>
> >> * Hibernate ORM registers RegisteredSynchronization with JTA.
> >> RegisteredSynchronization manages (indirectly, through
> >> TransactionCoordinator, SynchronizationRegistry etc.) those
> >> synchronizations added through
> o.h.t.Transaction.registerSynchronization()
> >> * WildFly (specifically, TransactionUtil [1]) registers its own
> >> SessionSynchronization
> >> for closing the entity manager/session
> >>
> >> Now that second synchronization is called first, closing the session.
> Upon
> >> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
> >> afterComplection() is called on RegisteredSynchronization afterwards,
> any
> >> previously registered delegate synchronizations are gone already and
> thus
> >> do not get invoked.
> >>
> >> I believe I found a workaround for my case by registering my
> >> synchronization through JtaPlatform#registerSynchronization() (which
> >> registers it with the actual JTA transaction).
> >>
> >> My questions are:
> >>
> >> * Is this behaviour expected?
> >> * Is the work-around of doing the registration via JtaPlatform viable or
> >> are there any drawbacks which I'm not aware of?
> >>
> >> Thanks,
> >>
> >> --Gunnar
> >>
> >> [1]
> >>
> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
> >> _______________________________________________
> >> 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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Tue Mar 10 11:44:28 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 10 Mar 2015 16:44:28 +0100
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <54FEF3F9.9090204@redhat.com>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
	<54FEF3F9.9090204@redhat.com>
Message-ID: <CADGJaX8vO0M6CKN6omc2yjOk+X+yYcRHOgDaTpRe4RZxmPchWw@mail.gmail.com>

Hi,

> I believe that your workaround, mentioned below, of using
JtaPlatform#registerSynchronization() on WildFly, is registering your
synchronization as interposed via the TransactionSynchronizationRegistry
[2].

That seems not to be the case. If you check out AbstractJtaPlatform and
TransactionManagerBasedSynchronizationStrategy in ORM,
registerSynchronization() adds the Sync as non-interposed via
TransactionManager.getTransaction().registerSynchronization().

But the ordering is indeed what makes me wonder. As SessionSynchronization
is interposed, the non-interposed beforeCompletion() hooks are run, but the
non-interposed afterCompletion() hooks managed via
RegisteredSynchronization are never run, as the session has been closed and
thus the list of syncs to be invoked through RegisteredSynchronization has
been cleared at this point. At least this behaviour was surprising to me.

My work-around works because my non-interposed sync is added through
JtaPlatform to the actual (Arjuna) Transaction instance directly (rather
than indirectly via RegisteredSynchronization) and thus gets invoked
properly.

2015-03-10 14:39 GMT+01:00 Scott Marlow <smarlow at redhat.com>:

> Hi Gunnar,
>
> Yes, this behaviour is expected since you registered an non-interposed
> synchronization.  For what purpose are you registering the transaction
> synchronization?  I would like to be aware of the synchronizations that we
> register in WildFly.
>
> The non-interposed sync beforeCompletion callback are invoked first, then
> the interposed sync beforeCompletion calls, then the interposed
> afterCompletion(int status) calls and finally, the non-interposed
> afterCompletion(int status) calls.
>
> The Synchronizations that are registered via the javax.transaction.
> TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization)
> [2] are interposed.
>
> Synchronizations that are registered via the javax.transaction.Transaction.
> registerSynchronization(Synchronization) [3] are non-interposed.
>
> In WildFly, the transaction manager uses the registration order within the
> interposed/non-interposed group.  Before completion syncs (within their
> respective group), are run in registration order.  After completion syncs
> (within their respective group), are run in reverse registration order.
>
> I believe that your workaround, mentioned below, of using JtaPlatform#registerSynchronization()
> on WildFly, is registering your synchronization as interposed via the
> TransactionSynchronizationRegistry [2]. There might be a way to register
> a sync callback at the Hibernate session level (which would also run as
> interposed sync on WildFly).
>
> Not sure if you saw my email yesterday to Hibernate-dev ml.  You should be
> aware that the afterCompletion(int status) callback, may be called from a
> non-application thread when the WildFly tm reaper handles tx timeout (this
> can happen while the application thread is still invoking calls on the
> Hibernate session).  Because the Hibernate session is not thread safe, we
> need to ensure that the Hibernate session afterCompletion(int status)
> callback does not mutate the Hibernate session (e.g. calling
> session.clear() what status == rolled back).
>
> Scott
>
> [2] http://docs.oracle.com/javaee/5/api/javax/transaction/
> TransactionSynchronizationRegistry.html#registerInterposedSynchronizat
> ion%28javax.transaction.Synchronization%29
>
> [3] http://docs.oracle.com/javaee/5/api/javax/transaction/
> Transaction.html#registerSynchronization%28javax.transaction.
> Synchronization%29
>
>
> On 03/10/2015 09:03 AM, Gunnar Morling wrote:
>
>> Hi,
>>
>> I'm trying to perform a specific action upon transaction rollback.
>>
>> Assuming this could be done using a custom
>> javax.transaction.Synchronization, I tried to register a synchronization
>> as
>> follows:
>>
>>      TransactionImplementor transaction = ...; // e.g. a CMTTransaction
>>      transaction.registerSynchronization( new MySync() );
>>
>> And indeed beforeCompletion() is invoked as expected. But
>> afterCompletion()
>> never is. I debugged this a bit on WildFly and observed the following:
>>
>> * Hibernate ORM registers RegisteredSynchronization with JTA.
>> RegisteredSynchronization manages (indirectly, through
>> TransactionCoordinator, SynchronizationRegistry etc.) those
>> synchronizations added through o.h.t.Transaction.
>> registerSynchronization()
>> * WildFly (specifically, TransactionUtil [1]) registers its own
>> SessionSynchronization
>> for closing the entity manager/session
>>
>> Now that second synchronization is called first, closing the session. Upon
>> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
>> afterComplection() is called on RegisteredSynchronization afterwards, any
>> previously registered delegate synchronizations are gone already and thus
>> do not get invoked.
>>
>> I believe I found a workaround for my case by registering my
>> synchronization through JtaPlatform#registerSynchronization() (which
>> registers it with the actual JTA transaction).
>>
>> My questions are:
>>
>> * Is this behaviour expected?
>> * Is the work-around of doing the registration via JtaPlatform viable or
>> are there any drawbacks which I'm not aware of?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>> https://github.com/wildfly/wildfly/blob/master/jpa/src/
>> main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>

From steve at hibernate.org  Tue Mar 10 11:44:59 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 10 Mar 2015 10:44:59 -0500
Subject: [hibernate-dev] new proposal for tx timeout handling using
 transaction DISASSOCIATING event notification...
In-Reply-To: <54FDE444.8060804@redhat.com>
References: <54FDE444.8060804@redhat.com>
Message-ID: <CAFdSV9umV82vr+6gAnGphnO6NhhqrHisWHYA63kw5VvGHss4Qw@mail.gmail.com>

Scott, I am not following.  Pardon me if I am being dense :)

Today, in our afterCompletion hooks we have code that, in the case of
rollback, tries to make a determination of whether the rollback is due to a
timeout or a "normal" rollback.  If we deem a timeout occurred, then we
delay the afterCompletion processing.

So how, specifically, would this be different in what you propose?

Are you saying that with this listener approach, that the listener would be
notified of disassociation prior to the afterCompletion callback on our
RegisteredSynchronization?  But in the timeout case, the disassociation
would happen later?

On Mon, Mar 9, 2015 at 1:19 PM, Scott Marlow <smarlow at redhat.com> wrote:

> With a proposed TM level listener, we will have an SPI for notification
> of when application threads associated with a JTA transaction, become
> disassociated with the transaction (tm.commit/rollback/suspend time).
> Having this knowledge in a synchronization callback, can determine
> whether the persistence context should be cleared directly from the
> Synchronization.afterCompletion(int) call or should be deferred until
> the transaction is disassociated from the JTA transaction.
>
> This idea is based on a TM level listener approach that Tom Jenkinson
> [1] suggested.  Mike Musgrove has a "proof of concept" implementation of
> the suggested changes [2].  I did some testing with [3] to see if the
> improvement helps with clearing entities that might still be in the
> persistence context after a background tx timeout.
>
> I'm wondering if in the Hibernate ORM
> Synchronization.afterCompletion(int status) implementation, in case of
> tx rollback, if we could defer the clearing of the Hibernate session to
> be handled by the JtaPlatform.  This could be setup at
> EntityManager.joinTransaction() time (if a new property like
> "hibernate.transaction.defer_clear_session" is true).  Perhaps via a
> JtaPlatform.joinTransaction(EntityManager) registration call?
>
> Thoughts?
>
> Scott
>
> [1] https://developer.jboss.org/thread/252572?start=45&tstart=0
>
> [2]
>
> https://github.com/mmusgrov/jboss-transaction-spi/blob/threadDisassociationListener/src/main/java/org/jboss/tm/
>
> [3]
>
> https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut_noejb_wildfly9_march5_2015
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Mar 10 11:50:11 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 10 Mar 2015 10:50:11 -0500
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <CADGJaX8vO0M6CKN6omc2yjOk+X+yYcRHOgDaTpRe4RZxmPchWw@mail.gmail.com>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
	<54FEF3F9.9090204@redhat.com>
	<CADGJaX8vO0M6CKN6omc2yjOk+X+yYcRHOgDaTpRe4RZxmPchWw@mail.gmail.com>
Message-ID: <CAFdSV9s0cjb+rN_Dy+NdJ=NH=VSAm_VzfWCidbJHo=mrV6VnkQ@mail.gmail.com>

Gunnar, WildFly uses its own JtaPlatform...

On Tue, Mar 10, 2015 at 10:44 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> > I believe that your workaround, mentioned below, of using
> JtaPlatform#registerSynchronization() on WildFly, is registering your
> synchronization as interposed via the TransactionSynchronizationRegistry
> [2].
>
> That seems not to be the case. If you check out AbstractJtaPlatform and
> TransactionManagerBasedSynchronizationStrategy in ORM,
> registerSynchronization() adds the Sync as non-interposed via
> TransactionManager.getTransaction().registerSynchronization().
>
> But the ordering is indeed what makes me wonder. As SessionSynchronization
> is interposed, the non-interposed beforeCompletion() hooks are run, but the
> non-interposed afterCompletion() hooks managed via
> RegisteredSynchronization are never run, as the session has been closed and
> thus the list of syncs to be invoked through RegisteredSynchronization has
> been cleared at this point. At least this behaviour was surprising to me.
>
> My work-around works because my non-interposed sync is added through
> JtaPlatform to the actual (Arjuna) Transaction instance directly (rather
> than indirectly via RegisteredSynchronization) and thus gets invoked
> properly.
>
> 2015-03-10 14:39 GMT+01:00 Scott Marlow <smarlow at redhat.com>:
>
> > Hi Gunnar,
> >
> > Yes, this behaviour is expected since you registered an non-interposed
> > synchronization.  For what purpose are you registering the transaction
> > synchronization?  I would like to be aware of the synchronizations that
> we
> > register in WildFly.
> >
> > The non-interposed sync beforeCompletion callback are invoked first, then
> > the interposed sync beforeCompletion calls, then the interposed
> > afterCompletion(int status) calls and finally, the non-interposed
> > afterCompletion(int status) calls.
> >
> > The Synchronizations that are registered via the javax.transaction.
> >
> TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization)
> > [2] are interposed.
> >
> > Synchronizations that are registered via the
> javax.transaction.Transaction.
> > registerSynchronization(Synchronization) [3] are non-interposed.
> >
> > In WildFly, the transaction manager uses the registration order within
> the
> > interposed/non-interposed group.  Before completion syncs (within their
> > respective group), are run in registration order.  After completion syncs
> > (within their respective group), are run in reverse registration order.
> >
> > I believe that your workaround, mentioned below, of using
> JtaPlatform#registerSynchronization()
> > on WildFly, is registering your synchronization as interposed via the
> > TransactionSynchronizationRegistry [2]. There might be a way to register
> > a sync callback at the Hibernate session level (which would also run as
> > interposed sync on WildFly).
> >
> > Not sure if you saw my email yesterday to Hibernate-dev ml.  You should
> be
> > aware that the afterCompletion(int status) callback, may be called from a
> > non-application thread when the WildFly tm reaper handles tx timeout
> (this
> > can happen while the application thread is still invoking calls on the
> > Hibernate session).  Because the Hibernate session is not thread safe, we
> > need to ensure that the Hibernate session afterCompletion(int status)
> > callback does not mutate the Hibernate session (e.g. calling
> > session.clear() what status == rolled back).
> >
> > Scott
> >
> > [2] http://docs.oracle.com/javaee/5/api/javax/transaction/
> > TransactionSynchronizationRegistry.html#registerInterposedSynchronizat
> > ion%28javax.transaction.Synchronization%29
> >
> > [3] http://docs.oracle.com/javaee/5/api/javax/transaction/
> > Transaction.html#registerSynchronization%28javax.transaction.
> > Synchronization%29
> >
> >
> > On 03/10/2015 09:03 AM, Gunnar Morling wrote:
> >
> >> Hi,
> >>
> >> I'm trying to perform a specific action upon transaction rollback.
> >>
> >> Assuming this could be done using a custom
> >> javax.transaction.Synchronization, I tried to register a synchronization
> >> as
> >> follows:
> >>
> >>      TransactionImplementor transaction = ...; // e.g. a CMTTransaction
> >>      transaction.registerSynchronization( new MySync() );
> >>
> >> And indeed beforeCompletion() is invoked as expected. But
> >> afterCompletion()
> >> never is. I debugged this a bit on WildFly and observed the following:
> >>
> >> * Hibernate ORM registers RegisteredSynchronization with JTA.
> >> RegisteredSynchronization manages (indirectly, through
> >> TransactionCoordinator, SynchronizationRegistry etc.) those
> >> synchronizations added through o.h.t.Transaction.
> >> registerSynchronization()
> >> * WildFly (specifically, TransactionUtil [1]) registers its own
> >> SessionSynchronization
> >> for closing the entity manager/session
> >>
> >> Now that second synchronization is called first, closing the session.
> Upon
> >> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
> >> afterComplection() is called on RegisteredSynchronization afterwards,
> any
> >> previously registered delegate synchronizations are gone already and
> thus
> >> do not get invoked.
> >>
> >> I believe I found a workaround for my case by registering my
> >> synchronization through JtaPlatform#registerSynchronization() (which
> >> registers it with the actual JTA transaction).
> >>
> >> My questions are:
> >>
> >> * Is this behaviour expected?
> >> * Is the work-around of doing the registration via JtaPlatform viable or
> >> are there any drawbacks which I'm not aware of?
> >>
> >> Thanks,
> >>
> >> --Gunnar
> >>
> >> [1]
> >> https://github.com/wildfly/wildfly/blob/master/jpa/src/
> >> main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
> >> _______________________________________________
> >> 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
>

From smarlow at redhat.com  Tue Mar 10 12:09:58 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 10 Mar 2015 12:09:58 -0400
Subject: [hibernate-dev] new proposal for tx timeout handling using
 transaction DISASSOCIATING event notification...
In-Reply-To: <CAFdSV9umV82vr+6gAnGphnO6NhhqrHisWHYA63kw5VvGHss4Qw@mail.gmail.com>
References: <54FDE444.8060804@redhat.com>
	<CAFdSV9umV82vr+6gAnGphnO6NhhqrHisWHYA63kw5VvGHss4Qw@mail.gmail.com>
Message-ID: <54FF1756.4040400@redhat.com>



On 03/10/2015 11:44 AM, Steve Ebersole wrote:
> Scott, I am not following.  Pardon me if I am being dense :)
>
> Today, in our afterCompletion hooks we have code that, in the case of
> rollback, tries to make a determination of whether the rollback is due
> to a timeout or a "normal" rollback.  If we deem a timeout occurred,
> then we delay the afterCompletion processing.

Currently, in our afterCompletion hooks, the determining code isn't 
aware of the current/last application thread id.  I think that we are 
only tracking the first thread id that is used with the Hibernate 
session but not the last thread id.

>
> So how, specifically, would this be different in what you propose?

The new approach will not use thread id, instead in our afterCompletion 
call, we will have the TM level knowledge, of whether the application 
thread has called tx rollback/suspend/commit yet.  If the application 
thread has called tx rollback/suspend/commit already, the 
afterCompletion call can safely clear managed entities from the session 
without violating concurrency concerns.  If the application has not yet 
called tx rollback/suspend/commit yet, we need to defer the clearing of 
the Hibernate session, until the TM listener calls us back, to let us 
know that the application has called tx rollback/suspend/commit, at 
which time we can safely clear the Hibernate session without violating 
(Hibernate session) concurrency concerns.

>
> Are you saying that with this listener approach, that the listener would
> be notified of disassociation prior to the afterCompletion callback on
> our RegisteredSynchronization?  But in the timeout case, the
> disassociation would happen later?

Yes.  It is also possible that in the timeout case, that the 
disassociation will come first (e.g. if there is a race between the app 
committing the transaction and the reaper thread timing out) but more 
likely that the disassociation comes later for the timeout case.

FYI, the TM level SPI changes [4][5] are still open for review.

Scott

[4] https://github.com/jbosstm/jboss-transaction-spi/pull/5
[5] https://github.com/jbosstm/narayana/pull/810

>
> On Mon, Mar 9, 2015 at 1:19 PM, Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     With a proposed TM level listener, we will have an SPI for notification
>     of when application threads associated with a JTA transaction, become
>     disassociated with the transaction (tm.commit/rollback/suspend time).
>     Having this knowledge in a synchronization callback, can determine
>     whether the persistence context should be cleared directly from the
>     Synchronization.afterCompletion(int) call or should be deferred until
>     the transaction is disassociated from the JTA transaction.
>
>     This idea is based on a TM level listener approach that Tom Jenkinson
>     [1] suggested.  Mike Musgrove has a "proof of concept" implementation of
>     the suggested changes [2].  I did some testing with [3] to see if the
>     improvement helps with clearing entities that might still be in the
>     persistence context after a background tx timeout.
>
>     I'm wondering if in the Hibernate ORM
>     Synchronization.afterCompletion(int status) implementation, in case of
>     tx rollback, if we could defer the clearing of the Hibernate session to
>     be handled by the JtaPlatform.  This could be setup at
>     EntityManager.joinTransaction() time (if a new property like
>     "hibernate.transaction.defer_clear_session" is true).  Perhaps via a
>     JtaPlatform.joinTransaction(EntityManager) registration call?
>
>     Thoughts?
>
>     Scott
>
>     [1] https://developer.jboss.org/thread/252572?start=45&tstart=0
>
>     [2]
>     https://github.com/mmusgrov/jboss-transaction-spi/blob/threadDisassociationListener/src/main/java/org/jboss/tm/
>
>     [3]
>     https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut_noejb_wildfly9_march5_2015
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From emmanuel at hibernate.org  Tue Mar 10 12:16:22 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 10 Mar 2015 17:16:22 +0100
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <54FF056E.10909@redhat.com>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
	<54FEF3F9.9090204@redhat.com>
	<1C6C422E-1B20-4421-A8AB-EA8C6542CCBC@hibernate.org>
	<54FF056E.10909@redhat.com>
Message-ID: <48126962-FD23-47CD-8770-1C1E61C6867A@hibernate.org>

I think we would need the same concurrency protection yes. If not today, in the near future. 


> On 10 mars 2015, at 15:53, Scott Marlow <smarlow at redhat.com> wrote:
> 
> 
> 
>> On 03/10/2015 10:12 AM, Emmanuel Bernard wrote:
>> So Gunnar, your workaround is fine today but will pose problems in the future if we decide that onRollback for ErrorHandler needs access to the session somehow to be able to compensate and undo the already executed operations:
>> - a closed session will do us no good
>> - there is a harder problem that Scott mentions below related to tx reaping in a different thread
>> 
>> Let?s try and find a solution for the first problem.
>> 
>> @Scott, I think what happens is the following:
>> 
>> - Hibernate registers a Sync when the EM is created (for the flush() callbacks and a few other things)
>> - Synchronization attached to the Hibernate Transaction objects are piggybacking on that initial Sync attachement
>> - Wildfly attach a ?close session? Sync once it has the instance of EntityManager
>> - according to your rules, the close session afterTransaction Sync is called before the one Hibernate put
>> - that explains why Gunnar finds an already closed Tx.
>> 
>> But since Gunnar attaches its Sync when the Hibernate TransactionCoordinator creates the Hibernate transaction, which is when the EM is created, I can?t explain why the workaround works.
> 
> Because Gunnar initially registered the Sync, via [3] javax.transaction.Transaction.registerSynchronization(Sync), which might be correct in some non-WildFly environments where perhaps all Syncs are registered via [3] (as non-interposed syncs).  When Gunnar, switched to the Hibernate JtaPlatform mechanism for registering the Sync, we then switched to an interposed Sync.  I suspect that the JtaPlatform sync registration is a good way to register the OGM, however, I have been told that the *best* way is to register only one sync (to avoid ordering issues).
> 
> If OGM could register to share the existing Hibernate EM sync, we would have more control over when the OGM sync is invoked and in which thread (application versus background tm reaping thread).
> 
> Regarding the proposed "new proposal for tx timeout handling using transaction DISASSOCIATING event notification" discussion and how that could impact OGM.  We will continue to run the interposed/non-interposed sync callbacks in whatever thread the TM, calls them from (e.g. beforeCompletion may or may not be called from app thread, afterCompletion will be called from either app thread, background reaping thread or background communications thread).  The reason is that certain resources need to be cleaned up immediately from the Sync.afterCompletion(int status) call.  Certain other resources (like clearing managed entities from persistence context after a rollback), need to be handled from either the application thread or a background thread after the application thread is disassociated from the JTA transaction.
> 
> IMO, the OGM ErrorHandling/Compensation API probably needs to be aware of the same concurrency requirements to avoid presenting the executed operations list, while the application thread is still executing new operations (because it perhaps doesn't yet know that the tx rolled back).
> 
> It would be good to know if OGM will also need the concurrency protection, so that any new Hibernate 5.0 SPI can be used by OGM (e.g. currently the only need is to run the Hibernate Session.clear when we know that the application thread is not actively using the Session).
> 
>> 
>> Emmanuel
>> 
>>> On 10 Mar 2015, at 14:39, Scott Marlow <smarlow at redhat.com> wrote:
>>> 
>>> Hi Gunnar,
>>> 
>>> Yes, this behaviour is expected since you registered an non-interposed
>>> synchronization.  For what purpose are you registering the transaction
>>> synchronization?  I would like to be aware of the synchronizations that
>>> we register in WildFly.
>>> 
>>> The non-interposed sync beforeCompletion callback are invoked first,
>>> then the interposed sync beforeCompletion calls, then the interposed
>>> afterCompletion(int status) calls and finally, the non-interposed
>>> afterCompletion(int status) calls.
>>> 
>>> The Synchronizations that are registered via the
>>> javax.transaction.TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization)
>>> [2] are interposed.
>>> 
>>> Synchronizations that are registered via the
>>> javax.transaction.Transaction.registerSynchronization(Synchronization)
>>> [3] are non-interposed.
>>> 
>>> In WildFly, the transaction manager uses the registration order within
>>> the interposed/non-interposed group.  Before completion syncs (within
>>> their respective group), are run in registration order.  After
>>> completion syncs (within their respective group), are run in reverse
>>> registration order.
>>> 
>>> I believe that your workaround, mentioned below, of using
>>> JtaPlatform#registerSynchronization() on WildFly, is registering your
>>> synchronization as interposed via the TransactionSynchronizationRegistry
>>> [2]. There might be a way to register a sync callback at the Hibernate
>>> session level (which would also run as interposed sync on WildFly).
>>> 
>>> Not sure if you saw my email yesterday to Hibernate-dev ml.  You should
>>> be aware that the afterCompletion(int status) callback, may be called
>>> from a non-application thread when the WildFly tm reaper handles tx
>>> timeout (this can happen while the application thread is still invoking
>>> calls on the Hibernate session).  Because the Hibernate session is not
>>> thread safe, we need to ensure that the Hibernate session
>>> afterCompletion(int status) callback does not mutate the Hibernate
>>> session (e.g. calling session.clear() what status == rolled back).
>>> 
>>> Scott
>>> 
>>> [2]
>>> http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html#registerInterposedSynchronization%28javax.transaction.Synchronization%29
>>> 
>>> [3]
>>> http://docs.oracle.com/javaee/5/api/javax/transaction/Transaction.html#registerSynchronization%28javax.transaction.Synchronization%29
>>> 
>>>> On 03/10/2015 09:03 AM, Gunnar Morling wrote:
>>>> Hi,
>>>> 
>>>> I'm trying to perform a specific action upon transaction rollback.
>>>> 
>>>> Assuming this could be done using a custom
>>>> javax.transaction.Synchronization, I tried to register a synchronization as
>>>> follows:
>>>> 
>>>>     TransactionImplementor transaction = ...; // e.g. a CMTTransaction
>>>>     transaction.registerSynchronization( new MySync() );
>>>> 
>>>> And indeed beforeCompletion() is invoked as expected. But afterCompletion()
>>>> never is. I debugged this a bit on WildFly and observed the following:
>>>> 
>>>> * Hibernate ORM registers RegisteredSynchronization with JTA.
>>>> RegisteredSynchronization manages (indirectly, through
>>>> TransactionCoordinator, SynchronizationRegistry etc.) those
>>>> synchronizations added through o.h.t.Transaction.registerSynchronization()
>>>> * WildFly (specifically, TransactionUtil [1]) registers its own
>>>> SessionSynchronization
>>>> for closing the entity manager/session
>>>> 
>>>> Now that second synchronization is called first, closing the session. Upon
>>>> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
>>>> afterComplection() is called on RegisteredSynchronization afterwards, any
>>>> previously registered delegate synchronizations are gone already and thus
>>>> do not get invoked.
>>>> 
>>>> I believe I found a workaround for my case by registering my
>>>> synchronization through JtaPlatform#registerSynchronization() (which
>>>> registers it with the actual JTA transaction).
>>>> 
>>>> My questions are:
>>>> 
>>>> * Is this behaviour expected?
>>>> * Is the work-around of doing the registration via JtaPlatform viable or
>>>> are there any drawbacks which I'm not aware of?
>>>> 
>>>> Thanks,
>>>> 
>>>> --Gunnar
>>>> 
>>>> [1]
>>>> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
>>>> _______________________________________________
>>>> 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
>> 


From emmanuel at hibernate.org  Tue Mar 10 12:19:43 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 10 Mar 2015 17:19:43 +0100
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <CAFdSV9syf4Dz0_0DuPa5WbKo8VPuVLi9Ytori8LSJNRrNsmRaQ@mail.gmail.com>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
	<EDD8860D-D178-40C2-8C71-37FE02328EBE@hibernate.org>
	<54FF09A8.104@redhat.com>
	<CAFdSV9syf4Dz0_0DuPa5WbKo8VPuVLi9Ytori8LSJNRrNsmRaQ@mail.gmail.com>
Message-ID: <CA35F331-4CD9-4152-B48F-376CC160C3BD@hibernate.org>

That's a good question. For now we implicitly decided not to use a different tx I guess. Remember, there in no actual transaction in those NoSQL backends in the first place. 


> On 10 mars 2015, at 16:36, Steve Ebersole <steve at hibernate.org> wrote:
> 
> Isn't the general approach is for "compensating actions" to be run in a separate transaction?
> 
>> On Tue, Mar 10, 2015 at 10:11 AM, Scott Marlow <smarlow at redhat.com> wrote:
>> I just saw the below email response after I sent the last one.  Sorry
>> about that, will respond here also.  :)
>> 
>> On 03/10/2015 09:14 AM, Emmanuel Bernard wrote:
>> > Ah synchronization ordering, it never gets old :) Steve might remember better but I don?t think we ever managed to convice the tx team to offer guaranteed ordering.
>> 
>> We started discussing synchronization ordering as well (within the
>> interposed group) and there is a WildFly specific code change being
>> worked on to always run the JCA sync last (so IronJacamar can delist a
>> resource that would of otherwise been leaked).
>> 
>> >
>> > Your workaround seems fine (if there is a JtaPlaform) but when we add more logic to your onRollback calls, we might want to offer access tot he Session to try compensating for example. In which case, we would be in trouble with the closed session. I don?t have a good idea.
>> 
>> Hmm, for the new SPI that deals with registering "concurrency safe"
>> OnRollback calls, I wonder if we should have an ordering priority, so
>> that the session clear/OGM operations list presentation, can always run
>> before the JPA container closes the session.  In a discussion about
>> changing the TM level Sync ordering for an unknown set of Syncs, we
>> talked about specifying an ordering priority for registered Syncs, that
>> idea will probably be useful for ordering the OnRollback calls if we
>> enable that.
>> 
>> >
>> > I am a bit surprised WildFly closes the session but that might be per spec that the container manages these calls.
>> 
>> Yes, only for a transaction scoped entity manager, do we have to close
>> the session after the transaction ends.  We don't do this for
>> application managed (application needs to call EM.close()).  For
>> extended persistence contexts, we close the session, after the last
>> referencing stateful bean is destroyed (tracking is done in the JPA
>> container).
>> 
>> Scott
>> 
>> >
>> >> On 10 Mar 2015, at 14:03, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I'm trying to perform a specific action upon transaction rollback.
>> >>
>> >> Assuming this could be done using a custom
>> >> javax.transaction.Synchronization, I tried to register a synchronization as
>> >> follows:
>> >>
>> >>     TransactionImplementor transaction = ...; // e.g. a CMTTransaction
>> >>     transaction.registerSynchronization( new MySync() );
>> >>
>> >> And indeed beforeCompletion() is invoked as expected. But afterCompletion()
>> >> never is. I debugged this a bit on WildFly and observed the following:
>> >>
>> >> * Hibernate ORM registers RegisteredSynchronization with JTA.
>> >> RegisteredSynchronization manages (indirectly, through
>> >> TransactionCoordinator, SynchronizationRegistry etc.) those
>> >> synchronizations added through o.h.t.Transaction.registerSynchronization()
>> >> * WildFly (specifically, TransactionUtil [1]) registers its own
>> >> SessionSynchronization
>> >> for closing the entity manager/session
>> >>
>> >> Now that second synchronization is called first, closing the session. Upon
>> >> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
>> >> afterComplection() is called on RegisteredSynchronization afterwards, any
>> >> previously registered delegate synchronizations are gone already and thus
>> >> do not get invoked.
>> >>
>> >> I believe I found a workaround for my case by registering my
>> >> synchronization through JtaPlatform#registerSynchronization() (which
>> >> registers it with the actual JTA transaction).
>> >>
>> >> My questions are:
>> >>
>> >> * Is this behaviour expected?
>> >> * Is the work-around of doing the registration via JtaPlatform viable or
>> >> are there any drawbacks which I'm not aware of?
>> >>
>> >> Thanks,
>> >>
>> >> --Gunnar
>> >>
>> >> [1]
>> >> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
>> >> _______________________________________________
>> >> 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
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From m.schipperheyn at gmail.com  Tue Mar 10 12:24:04 2015
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Tue, 10 Mar 2015 13:24:04 -0300
Subject: [hibernate-dev] Strange issue massindexer and classbridge
Message-ID: <CAGvEgx7gjN6iM8gPNKZG+rVixO=vSdy6S6oOPuod3+amKW0mFA@mail.gmail.com>

Hi,

I just wanted to share a strange issue I had w the massindexer and a
classbridge where a whole class of entities was not being indexed by the
massindexer (Hibernate Search 5.1).

The entity in question was part of an inheritance hierarchy.

Something like
BaseComment
    Comment
    Post
    RSSPost

I noticed that only the "Post" entities were missing from the index after
running the massindexer against BaseComment. Tried various times.

Any new entity entered would end up in the index correctly.

I finally removed a ClassBridge I use on that entity and restarted.
MassIndexer then worked correctly. And continued to work correctly after
restarts even w the classbridge active again.

I have been switching between Hibernate 4.x and 5.1 regularly and
re-indexing every time without manually cleaning the index directories.
Perhaps this had something to do with it.

Cheers,
Marc

From steve at hibernate.org  Tue Mar 10 12:30:11 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 10 Mar 2015 11:30:11 -0500
Subject: [hibernate-dev] new proposal for tx timeout handling using
 transaction DISASSOCIATING event notification...
In-Reply-To: <54FF1756.4040400@redhat.com>
References: <54FDE444.8060804@redhat.com>
	<CAFdSV9umV82vr+6gAnGphnO6NhhqrHisWHYA63kw5VvGHss4Qw@mail.gmail.com>
	<54FF1756.4040400@redhat.com>
Message-ID: <CAFdSV9u+5oeJANhWDBQu-QiMg1qY7SvvDaKmzpsyYjbcKT_-wQ@mail.gmail.com>

You confused me more :)

One the one had you say that we will use this fact of whether the
transaction has been disassociated to indicate whether the transaction is
completing normally (disassociated == true) or timed-out (disassociated ==
false).  But at the same time you are saying that it is quite possible that
we could still receive the afterCompletion callback in the timed-out case
and have (disassociated == true) due to race conditions.

So what is this buying us?


On Tue, Mar 10, 2015 at 11:09 AM, Scott Marlow <smarlow at redhat.com> wrote:

>
>
> On 03/10/2015 11:44 AM, Steve Ebersole wrote:
>
>> Scott, I am not following.  Pardon me if I am being dense :)
>>
>> Today, in our afterCompletion hooks we have code that, in the case of
>> rollback, tries to make a determination of whether the rollback is due
>> to a timeout or a "normal" rollback.  If we deem a timeout occurred,
>> then we delay the afterCompletion processing.
>>
>
> Currently, in our afterCompletion hooks, the determining code isn't aware
> of the current/last application thread id.  I think that we are only
> tracking the first thread id that is used with the Hibernate session but
> not the last thread id.
>
>
>> So how, specifically, would this be different in what you propose?
>>
>
> The new approach will not use thread id, instead in our afterCompletion
> call, we will have the TM level knowledge, of whether the application
> thread has called tx rollback/suspend/commit yet.  If the application
> thread has called tx rollback/suspend/commit already, the afterCompletion
> call can safely clear managed entities from the session without violating
> concurrency concerns.  If the application has not yet called tx
> rollback/suspend/commit yet, we need to defer the clearing of the Hibernate
> session, until the TM listener calls us back, to let us know that the
> application has called tx rollback/suspend/commit, at which time we can
> safely clear the Hibernate session without violating (Hibernate session)
> concurrency concerns.
>
>
>> Are you saying that with this listener approach, that the listener would
>> be notified of disassociation prior to the afterCompletion callback on
>> our RegisteredSynchronization?  But in the timeout case, the
>> disassociation would happen later?
>>
>
> Yes.  It is also possible that in the timeout case, that the
> disassociation will come first (e.g. if there is a race between the app
> committing the transaction and the reaper thread timing out) but more
> likely that the disassociation comes later for the timeout case.
>
> FYI, the TM level SPI changes [4][5] are still open for review.
>
> Scott
>
> [4] https://github.com/jbosstm/jboss-transaction-spi/pull/5
> [5] https://github.com/jbosstm/narayana/pull/810
>
>
>> On Mon, Mar 9, 2015 at 1:19 PM, Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>>
>>     With a proposed TM level listener, we will have an SPI for
>> notification
>>     of when application threads associated with a JTA transaction, become
>>     disassociated with the transaction (tm.commit/rollback/suspend time).
>>     Having this knowledge in a synchronization callback, can determine
>>     whether the persistence context should be cleared directly from the
>>     Synchronization.afterCompletion(int) call or should be deferred until
>>     the transaction is disassociated from the JTA transaction.
>>
>>     This idea is based on a TM level listener approach that Tom Jenkinson
>>     [1] suggested.  Mike Musgrove has a "proof of concept" implementation
>> of
>>     the suggested changes [2].  I did some testing with [3] to see if the
>>     improvement helps with clearing entities that might still be in the
>>     persistence context after a background tx timeout.
>>
>>     I'm wondering if in the Hibernate ORM
>>     Synchronization.afterCompletion(int status) implementation, in case
>> of
>>     tx rollback, if we could defer the clearing of the Hibernate session
>> to
>>     be handled by the JtaPlatform.  This could be setup at
>>     EntityManager.joinTransaction() time (if a new property like
>>     "hibernate.transaction.defer_clear_session" is true).  Perhaps via a
>>     JtaPlatform.joinTransaction(EntityManager) registration call?
>>
>>     Thoughts?
>>
>>     Scott
>>
>>     [1] https://developer.jboss.org/thread/252572?start=45&tstart=0
>>
>>     [2]
>>     https://github.com/mmusgrov/jboss-transaction-spi/blob/
>> threadDisassociationListener/src/main/java/org/jboss/tm/
>>
>>     [3]
>>     https://github.com/scottmarlow/wildfly/tree/
>> transactiontimeout_clientut_noejb_wildfly9_march5_2015
>>
>>     _______________________________________________
>>     hibernate-dev mailing list
>>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>>

From gunnar at hibernate.org  Tue Mar 10 13:14:15 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 10 Mar 2015 18:14:15 +0100
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <CAFdSV9s0cjb+rN_Dy+NdJ=NH=VSAm_VzfWCidbJHo=mrV6VnkQ@mail.gmail.com>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
	<54FEF3F9.9090204@redhat.com>
	<CADGJaX8vO0M6CKN6omc2yjOk+X+yYcRHOgDaTpRe4RZxmPchWw@mail.gmail.com>
	<CAFdSV9s0cjb+rN_Dy+NdJ=NH=VSAm_VzfWCidbJHo=mrV6VnkQ@mail.gmail.com>
Message-ID: <CADGJaX8d4VUgnf437eoBqu7s-ch5D63fVnRPE1WEt8KCfCcfvA@mail.gmail.com>

For some reason I'm seeing though JBossStandAloneJtaPlatform being used
when debugging an OGM integration test on WildFly.

WF's JtaPlatform seems not to be picked up. Tried to debug a but,
apparently it never comes to the point where JipiJapa would inject the
JBossAppServerJtaPlatform as platform. I could imagine it's due to OGM
being used as persistence provider, so maybe the right implicit module
dependencies don't get added? Scott?

It's all a bit guess work on my side, I don't know that WF/JipiJapa code
very well.



2015-03-10 16:50 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> Gunnar, WildFly uses its own JtaPlatform...
>
> On Tue, Mar 10, 2015 at 10:44 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hi,
>>
>> > I believe that your workaround, mentioned below, of using
>> JtaPlatform#registerSynchronization() on WildFly, is registering your
>> synchronization as interposed via the TransactionSynchronizationRegistry
>> [2].
>>
>> That seems not to be the case. If you check out AbstractJtaPlatform and
>> TransactionManagerBasedSynchronizationStrategy in ORM,
>> registerSynchronization() adds the Sync as non-interposed via
>> TransactionManager.getTransaction().registerSynchronization().
>>
>> But the ordering is indeed what makes me wonder. As SessionSynchronization
>> is interposed, the non-interposed beforeCompletion() hooks are run, but
>> the
>> non-interposed afterCompletion() hooks managed via
>> RegisteredSynchronization are never run, as the session has been closed
>> and
>> thus the list of syncs to be invoked through RegisteredSynchronization has
>> been cleared at this point. At least this behaviour was surprising to me.
>>
>> My work-around works because my non-interposed sync is added through
>> JtaPlatform to the actual (Arjuna) Transaction instance directly (rather
>> than indirectly via RegisteredSynchronization) and thus gets invoked
>> properly.
>>
>> 2015-03-10 14:39 GMT+01:00 Scott Marlow <smarlow at redhat.com>:
>>
>> > Hi Gunnar,
>> >
>> > Yes, this behaviour is expected since you registered an non-interposed
>> > synchronization.  For what purpose are you registering the transaction
>> > synchronization?  I would like to be aware of the synchronizations that
>> we
>> > register in WildFly.
>> >
>> > The non-interposed sync beforeCompletion callback are invoked first,
>> then
>> > the interposed sync beforeCompletion calls, then the interposed
>> > afterCompletion(int status) calls and finally, the non-interposed
>> > afterCompletion(int status) calls.
>> >
>> > The Synchronizations that are registered via the javax.transaction.
>> >
>> TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization)
>> > [2] are interposed.
>> >
>> > Synchronizations that are registered via the
>> javax.transaction.Transaction.
>> > registerSynchronization(Synchronization) [3] are non-interposed.
>> >
>> > In WildFly, the transaction manager uses the registration order within
>> the
>> > interposed/non-interposed group.  Before completion syncs (within their
>> > respective group), are run in registration order.  After completion
>> syncs
>> > (within their respective group), are run in reverse registration order.
>> >
>> > I believe that your workaround, mentioned below, of using
>> JtaPlatform#registerSynchronization()
>> > on WildFly, is registering your synchronization as interposed via the
>> > TransactionSynchronizationRegistry [2]. There might be a way to register
>> > a sync callback at the Hibernate session level (which would also run as
>> > interposed sync on WildFly).
>> >
>> > Not sure if you saw my email yesterday to Hibernate-dev ml.  You should
>> be
>> > aware that the afterCompletion(int status) callback, may be called from
>> a
>> > non-application thread when the WildFly tm reaper handles tx timeout
>> (this
>> > can happen while the application thread is still invoking calls on the
>> > Hibernate session).  Because the Hibernate session is not thread safe,
>> we
>> > need to ensure that the Hibernate session afterCompletion(int status)
>> > callback does not mutate the Hibernate session (e.g. calling
>> > session.clear() what status == rolled back).
>> >
>> > Scott
>> >
>> > [2] http://docs.oracle.com/javaee/5/api/javax/transaction/
>> > TransactionSynchronizationRegistry.html#registerInterposedSynchronizat
>> > ion%28javax.transaction.Synchronization%29
>> >
>> > [3] http://docs.oracle.com/javaee/5/api/javax/transaction/
>> > Transaction.html#registerSynchronization%28javax.transaction.
>> > Synchronization%29
>> >
>> >
>> > On 03/10/2015 09:03 AM, Gunnar Morling wrote:
>> >
>> >> Hi,
>> >>
>> >> I'm trying to perform a specific action upon transaction rollback.
>> >>
>> >> Assuming this could be done using a custom
>> >> javax.transaction.Synchronization, I tried to register a
>> synchronization
>> >> as
>> >> follows:
>> >>
>> >>      TransactionImplementor transaction = ...; // e.g. a CMTTransaction
>> >>      transaction.registerSynchronization( new MySync() );
>> >>
>> >> And indeed beforeCompletion() is invoked as expected. But
>> >> afterCompletion()
>> >> never is. I debugged this a bit on WildFly and observed the following:
>> >>
>> >> * Hibernate ORM registers RegisteredSynchronization with JTA.
>> >> RegisteredSynchronization manages (indirectly, through
>> >> TransactionCoordinator, SynchronizationRegistry etc.) those
>> >> synchronizations added through o.h.t.Transaction.
>> >> registerSynchronization()
>> >> * WildFly (specifically, TransactionUtil [1]) registers its own
>> >> SessionSynchronization
>> >> for closing the entity manager/session
>> >>
>> >> Now that second synchronization is called first, closing the session.
>> Upon
>> >> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
>> >> afterComplection() is called on RegisteredSynchronization afterwards,
>> any
>> >> previously registered delegate synchronizations are gone already and
>> thus
>> >> do not get invoked.
>> >>
>> >> I believe I found a workaround for my case by registering my
>> >> synchronization through JtaPlatform#registerSynchronization() (which
>> >> registers it with the actual JTA transaction).
>> >>
>> >> My questions are:
>> >>
>> >> * Is this behaviour expected?
>> >> * Is the work-around of doing the registration via JtaPlatform viable
>> or
>> >> are there any drawbacks which I'm not aware of?
>> >>
>> >> Thanks,
>> >>
>> >> --Gunnar
>> >>
>> >> [1]
>> >> https://github.com/wildfly/wildfly/blob/master/jpa/src/
>> >> main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
>> >> _______________________________________________
>> >> 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
>>
>
>

From steve at hibernate.org  Tue Mar 10 13:30:10 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 10 Mar 2015 12:30:10 -0500
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <CADGJaX8d4VUgnf437eoBqu7s-ch5D63fVnRPE1WEt8KCfCcfvA@mail.gmail.com>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>
	<54FEF3F9.9090204@redhat.com>
	<CADGJaX8vO0M6CKN6omc2yjOk+X+yYcRHOgDaTpRe4RZxmPchWw@mail.gmail.com>
	<CAFdSV9s0cjb+rN_Dy+NdJ=NH=VSAm_VzfWCidbJHo=mrV6VnkQ@mail.gmail.com>
	<CADGJaX8d4VUgnf437eoBqu7s-ch5D63fVnRPE1WEt8KCfCcfvA@mail.gmail.com>
Message-ID: <CAFdSV9sMNCOSZhTm2B8H5FWXoZQOhHhuZKr9O_ZhY3wWzttwrQ@mail.gmail.com>

Ah, that could be.  Jipijapa does do a lot of things specific to the
provider used.  Probably we just need some proper OGM Jipijapa hooks.

On Tue, Mar 10, 2015 at 12:14 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> For some reason I'm seeing though JBossStandAloneJtaPlatform being used
> when debugging an OGM integration test on WildFly.
>
> WF's JtaPlatform seems not to be picked up. Tried to debug a but,
> apparently it never comes to the point where JipiJapa would inject the
> JBossAppServerJtaPlatform as platform. I could imagine it's due to OGM
> being used as persistence provider, so maybe the right implicit module
> dependencies don't get added? Scott?
>
> It's all a bit guess work on my side, I don't know that WF/JipiJapa code
> very well.
>
>
>
> 2015-03-10 16:50 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> Gunnar, WildFly uses its own JtaPlatform...
>>
>> On Tue, Mar 10, 2015 at 10:44 AM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> Hi,
>>>
>>> > I believe that your workaround, mentioned below, of using
>>> JtaPlatform#registerSynchronization() on WildFly, is registering your
>>> synchronization as interposed via the TransactionSynchronizationRegistry
>>> [2].
>>>
>>> That seems not to be the case. If you check out AbstractJtaPlatform and
>>> TransactionManagerBasedSynchronizationStrategy in ORM,
>>> registerSynchronization() adds the Sync as non-interposed via
>>> TransactionManager.getTransaction().registerSynchronization().
>>>
>>> But the ordering is indeed what makes me wonder. As
>>> SessionSynchronization
>>> is interposed, the non-interposed beforeCompletion() hooks are run, but
>>> the
>>> non-interposed afterCompletion() hooks managed via
>>> RegisteredSynchronization are never run, as the session has been closed
>>> and
>>> thus the list of syncs to be invoked through RegisteredSynchronization
>>> has
>>> been cleared at this point. At least this behaviour was surprising to me.
>>>
>>> My work-around works because my non-interposed sync is added through
>>> JtaPlatform to the actual (Arjuna) Transaction instance directly (rather
>>> than indirectly via RegisteredSynchronization) and thus gets invoked
>>> properly.
>>>
>>> 2015-03-10 14:39 GMT+01:00 Scott Marlow <smarlow at redhat.com>:
>>>
>>> > Hi Gunnar,
>>> >
>>> > Yes, this behaviour is expected since you registered an non-interposed
>>> > synchronization.  For what purpose are you registering the transaction
>>> > synchronization?  I would like to be aware of the synchronizations
>>> that we
>>> > register in WildFly.
>>> >
>>> > The non-interposed sync beforeCompletion callback are invoked first,
>>> then
>>> > the interposed sync beforeCompletion calls, then the interposed
>>> > afterCompletion(int status) calls and finally, the non-interposed
>>> > afterCompletion(int status) calls.
>>> >
>>> > The Synchronizations that are registered via the javax.transaction.
>>> >
>>> TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization)
>>> > [2] are interposed.
>>> >
>>> > Synchronizations that are registered via the
>>> javax.transaction.Transaction.
>>> > registerSynchronization(Synchronization) [3] are non-interposed.
>>> >
>>> > In WildFly, the transaction manager uses the registration order within
>>> the
>>> > interposed/non-interposed group.  Before completion syncs (within their
>>> > respective group), are run in registration order.  After completion
>>> syncs
>>> > (within their respective group), are run in reverse registration order.
>>> >
>>> > I believe that your workaround, mentioned below, of using
>>> JtaPlatform#registerSynchronization()
>>> > on WildFly, is registering your synchronization as interposed via the
>>> > TransactionSynchronizationRegistry [2]. There might be a way to
>>> register
>>> > a sync callback at the Hibernate session level (which would also run as
>>> > interposed sync on WildFly).
>>> >
>>> > Not sure if you saw my email yesterday to Hibernate-dev ml.  You
>>> should be
>>> > aware that the afterCompletion(int status) callback, may be called
>>> from a
>>> > non-application thread when the WildFly tm reaper handles tx timeout
>>> (this
>>> > can happen while the application thread is still invoking calls on the
>>> > Hibernate session).  Because the Hibernate session is not thread safe,
>>> we
>>> > need to ensure that the Hibernate session afterCompletion(int status)
>>> > callback does not mutate the Hibernate session (e.g. calling
>>> > session.clear() what status == rolled back).
>>> >
>>> > Scott
>>> >
>>> > [2] http://docs.oracle.com/javaee/5/api/javax/transaction/
>>> > TransactionSynchronizationRegistry.html#registerInterposedSynchronizat
>>> > ion%28javax.transaction.Synchronization%29
>>> >
>>> > [3] http://docs.oracle.com/javaee/5/api/javax/transaction/
>>> > Transaction.html#registerSynchronization%28javax.transaction.
>>> > Synchronization%29
>>> >
>>> >
>>> > On 03/10/2015 09:03 AM, Gunnar Morling wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> I'm trying to perform a specific action upon transaction rollback.
>>> >>
>>> >> Assuming this could be done using a custom
>>> >> javax.transaction.Synchronization, I tried to register a
>>> synchronization
>>> >> as
>>> >> follows:
>>> >>
>>> >>      TransactionImplementor transaction = ...; // e.g. a
>>> CMTTransaction
>>> >>      transaction.registerSynchronization( new MySync() );
>>> >>
>>> >> And indeed beforeCompletion() is invoked as expected. But
>>> >> afterCompletion()
>>> >> never is. I debugged this a bit on WildFly and observed the following:
>>> >>
>>> >> * Hibernate ORM registers RegisteredSynchronization with JTA.
>>> >> RegisteredSynchronization manages (indirectly, through
>>> >> TransactionCoordinator, SynchronizationRegistry etc.) those
>>> >> synchronizations added through o.h.t.Transaction.
>>> >> registerSynchronization()
>>> >> * WildFly (specifically, TransactionUtil [1]) registers its own
>>> >> SessionSynchronization
>>> >> for closing the entity manager/session
>>> >>
>>> >> Now that second synchronization is called first, closing the session.
>>> Upon
>>> >> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
>>> >> afterComplection() is called on RegisteredSynchronization afterwards,
>>> any
>>> >> previously registered delegate synchronizations are gone already and
>>> thus
>>> >> do not get invoked.
>>> >>
>>> >> I believe I found a workaround for my case by registering my
>>> >> synchronization through JtaPlatform#registerSynchronization() (which
>>> >> registers it with the actual JTA transaction).
>>> >>
>>> >> My questions are:
>>> >>
>>> >> * Is this behaviour expected?
>>> >> * Is the work-around of doing the registration via JtaPlatform viable
>>> or
>>> >> are there any drawbacks which I'm not aware of?
>>> >>
>>> >> Thanks,
>>> >>
>>> >> --Gunnar
>>> >>
>>> >> [1]
>>> >> https://github.com/wildfly/wildfly/blob/master/jpa/src/
>>> >> main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
>>> >> _______________________________________________
>>> >> 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
>>>
>>
>>
>

From smarlow at redhat.com  Tue Mar 10 13:42:42 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 10 Mar 2015 13:42:42 -0400
Subject: [hibernate-dev] new proposal for tx timeout handling using
 transaction DISASSOCIATING event notification...
In-Reply-To: <CAFdSV9u+5oeJANhWDBQu-QiMg1qY7SvvDaKmzpsyYjbcKT_-wQ@mail.gmail.com>
References: <54FDE444.8060804@redhat.com>	<CAFdSV9umV82vr+6gAnGphnO6NhhqrHisWHYA63kw5VvGHss4Qw@mail.gmail.com>	<54FF1756.4040400@redhat.com>
	<CAFdSV9u+5oeJANhWDBQu-QiMg1qY7SvvDaKmzpsyYjbcKT_-wQ@mail.gmail.com>
Message-ID: <54FF2D12.8090207@redhat.com>

On 03/10/2015 12:30 PM, Steve Ebersole wrote:
> You confused me more :)
>
> One the one had you say that we will use this fact of whether the
> transaction has been disassociated to indicate whether the transaction
> is completing normally (disassociated == true) or timed-out
> (disassociated == false).  But at the same time you are saying that it
> is quite possible that we could still receive the
> afterCompletion callback in the timed-out case and have (disassociated
> == true) due to race conditions.

When we have both disassociated == true and afterCompletion has been 
called, then it is safe to clear the Hibernate session.  The order that 
these conditions are detected, does not matter.

>
> So what is this buying us?
>
>
> On Tue, Mar 10, 2015 at 11:09 AM, Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>
>
>     On 03/10/2015 11:44 AM, Steve Ebersole wrote:
>
>         Scott, I am not following.  Pardon me if I am being dense :)
>
>         Today, in our afterCompletion hooks we have code that, in the
>         case of
>         rollback, tries to make a determination of whether the rollback
>         is due
>         to a timeout or a "normal" rollback.  If we deem a timeout occurred,
>         then we delay the afterCompletion processing.
>
>
>     Currently, in our afterCompletion hooks, the determining code isn't
>     aware of the current/last application thread id.  I think that we
>     are only tracking the first thread id that is used with the
>     Hibernate session but not the last thread id.
>
>
>         So how, specifically, would this be different in what you propose?
>
>
>     The new approach will not use thread id, instead in our
>     afterCompletion call, we will have the TM level knowledge, of
>     whether the application thread has called tx rollback/suspend/commit
>     yet.  If the application thread has called tx
>     rollback/suspend/commit already, the afterCompletion call can safely
>     clear managed entities from the session without violating
>     concurrency concerns.  If the application has not yet called tx
>     rollback/suspend/commit yet, we need to defer the clearing of the
>     Hibernate session, until the TM listener calls us back, to let us
>     know that the application has called tx rollback/suspend/commit, at
>     which time we can safely clear the Hibernate session without
>     violating (Hibernate session) concurrency concerns.
>
>
>         Are you saying that with this listener approach, that the
>         listener would
>         be notified of disassociation prior to the afterCompletion
>         callback on
>         our RegisteredSynchronization?  But in the timeout case, the
>         disassociation would happen later?
>
>
>     Yes.  It is also possible that in the timeout case, that the
>     disassociation will come first (e.g. if there is a race between the
>     app committing the transaction and the reaper thread timing out) but
>     more likely that the disassociation comes later for the timeout case.
>
>     FYI, the TM level SPI changes [4][5] are still open for review.
>
>     Scott
>
>     [4] https://github.com/jbosstm/__jboss-transaction-spi/pull/5
>     <https://github.com/jbosstm/jboss-transaction-spi/pull/5>
>     [5] https://github.com/jbosstm/__narayana/pull/810
>     <https://github.com/jbosstm/narayana/pull/810>
>
>
>         On Mon, Mar 9, 2015 at 1:19 PM, Scott Marlow <smarlow at redhat.com
>         <mailto:smarlow at redhat.com>
>         <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>
>              With a proposed TM level listener, we will have an SPI for
>         notification
>              of when application threads associated with a JTA
>         transaction, become
>              disassociated with the transaction
>         (tm.commit/rollback/suspend time).
>              Having this knowledge in a synchronization callback, can
>         determine
>              whether the persistence context should be cleared directly
>         from the
>              Synchronization.__afterCompletion(int) call or should be
>         deferred until
>              the transaction is disassociated from the JTA transaction.
>
>              This idea is based on a TM level listener approach that Tom
>         Jenkinson
>              [1] suggested.  Mike Musgrove has a "proof of concept"
>         implementation of
>              the suggested changes [2].  I did some testing with [3] to
>         see if the
>              improvement helps with clearing entities that might still
>         be in the
>              persistence context after a background tx timeout.
>
>              I'm wondering if in the Hibernate ORM
>              Synchronization.__afterCompletion(int status)
>         implementation, in case of
>              tx rollback, if we could defer the clearing of the
>         Hibernate session to
>              be handled by the JtaPlatform.  This could be setup at
>              EntityManager.joinTransaction(__) time (if a new property like
>              "hibernate.transaction.defer___clear_session" is true).
>         Perhaps via a
>              JtaPlatform.joinTransaction(__EntityManager) registration call?
>
>              Thoughts?
>
>              Scott
>
>              [1]
>         https://developer.jboss.org/__thread/252572?start=45&tstart=__0
>         <https://developer.jboss.org/thread/252572?start=45&tstart=0>
>
>              [2]
>         https://github.com/mmusgrov/__jboss-transaction-spi/blob/__threadDisassociationListener/__src/main/java/org/jboss/tm/
>         <https://github.com/mmusgrov/jboss-transaction-spi/blob/threadDisassociationListener/src/main/java/org/jboss/tm/>
>
>              [3]
>         https://github.com/__scottmarlow/wildfly/tree/__transactiontimeout_clientut___noejb_wildfly9_march5_2015
>         <https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut_noejb_wildfly9_march5_2015>
>
>              _________________________________________________
>              hibernate-dev mailing list
>         hibernate-dev at lists.jboss.org
>         <mailto:hibernate-dev at lists.jboss.org>
>         <mailto:hibernate-dev at lists.__jboss.org
>         <mailto:hibernate-dev at lists.jboss.org>>
>         https://lists.jboss.org/__mailman/listinfo/hibernate-dev
>         <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>
>

From smarlow at redhat.com  Tue Mar 10 13:51:29 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 10 Mar 2015 13:51:29 -0400
Subject: [hibernate-dev] new proposal for tx timeout handling using
 transaction DISASSOCIATING event notification...
In-Reply-To: <CAFdSV9u+5oeJANhWDBQu-QiMg1qY7SvvDaKmzpsyYjbcKT_-wQ@mail.gmail.com>
References: <54FDE444.8060804@redhat.com>	<CAFdSV9umV82vr+6gAnGphnO6NhhqrHisWHYA63kw5VvGHss4Qw@mail.gmail.com>	<54FF1756.4040400@redhat.com>
	<CAFdSV9u+5oeJANhWDBQu-QiMg1qY7SvvDaKmzpsyYjbcKT_-wQ@mail.gmail.com>
Message-ID: <54FF2F21.6000704@redhat.com>

>
> So what is this buying us?
>

The current Hibernate ORM thread id checking, does not properly handle 
the case when the application thread changes between calls to the 
Hibernate session.  The new approach does handle the application thread 
changing between session invocations and also covers a few other cases 
as well (like clearing the persistence context after the application may 
of added another entity after the background thread rolled back the 
transaction).

From smarlow at redhat.com  Tue Mar 10 14:17:58 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 10 Mar 2015 14:17:58 -0400
Subject: [hibernate-dev] JTA synchronizations on WildFly
In-Reply-To: <CADGJaX8d4VUgnf437eoBqu7s-ch5D63fVnRPE1WEt8KCfCcfvA@mail.gmail.com>
References: <CADGJaX89PPbgOmztfyNEiLk7mwd9xDFCXXE+vxsxG8wbX9AbyA@mail.gmail.com>	<54FEF3F9.9090204@redhat.com>	<CADGJaX8vO0M6CKN6omc2yjOk+X+yYcRHOgDaTpRe4RZxmPchWw@mail.gmail.com>	<CAFdSV9s0cjb+rN_Dy+NdJ=NH=VSAm_VzfWCidbJHo=mrV6VnkQ@mail.gmail.com>
	<CADGJaX8d4VUgnf437eoBqu7s-ch5D63fVnRPE1WEt8KCfCcfvA@mail.gmail.com>
Message-ID: <54FF3556.1080902@redhat.com>

Not exactly sure but this might be the way that Jipijapa registers the 
JtaPlatform.  Originally, Jipijapa used the service approach but 
reverted that due to a memory leak (I think in envers?).

This was mentioned a while back via [3].  I think we talked about 
switching Jipijapa back to using a 
META-INF/services/org.hibernate.engine.transaction.jta.platform.spi.JtaPlatformProvider 
but I never bothered since the current non-service approach works 
(except for your use case :).

Scott

[3] http://lists.jboss.org/pipermail/hibernate-dev/2013-July/010140.html

On 03/10/2015 01:14 PM, Gunnar Morling wrote:
> For some reason I'm seeing though JBossStandAloneJtaPlatform being used
> when debugging an OGM integration test on WildFly.
>
> WF's JtaPlatform seems not to be picked up. Tried to debug a but,
> apparently it never comes to the point where JipiJapa would inject the
> JBossAppServerJtaPlatform as platform. I could imagine it's due to OGM
> being used as persistence provider, so maybe the right implicit module
> dependencies don't get added? Scott?
>
> It's all a bit guess work on my side, I don't know that WF/JipiJapa code
> very well.
>
>
>
> 2015-03-10 16:50 GMT+01:00 Steve Ebersole <steve at hibernate.org
> <mailto:steve at hibernate.org>>:
>
>     Gunnar, WildFly uses its own JtaPlatform...
>
>     On Tue, Mar 10, 2015 at 10:44 AM, Gunnar Morling
>     <gunnar at hibernate.org <mailto:gunnar at hibernate.org>> wrote:
>
>         Hi,
>
>         > I believe that your workaround, mentioned below, of using
>         JtaPlatform#registerSynchronization() on WildFly, is registering
>         your
>         synchronization as interposed via the
>         TransactionSynchronizationRegistry
>         [2].
>
>         That seems not to be the case. If you check out
>         AbstractJtaPlatform and
>         TransactionManagerBasedSynchronizationStrategy in ORM,
>         registerSynchronization() adds the Sync as non-interposed via
>         TransactionManager.getTransaction().registerSynchronization().
>
>         But the ordering is indeed what makes me wonder. As
>         SessionSynchronization
>         is interposed, the non-interposed beforeCompletion() hooks are
>         run, but the
>         non-interposed afterCompletion() hooks managed via
>         RegisteredSynchronization are never run, as the session has been
>         closed and
>         thus the list of syncs to be invoked through
>         RegisteredSynchronization has
>         been cleared at this point. At least this behaviour was
>         surprising to me.
>
>         My work-around works because my non-interposed sync is added through
>         JtaPlatform to the actual (Arjuna) Transaction instance directly
>         (rather
>         than indirectly via RegisteredSynchronization) and thus gets invoked
>         properly.
>
>         2015-03-10 14:39 GMT+01:00 Scott Marlow <smarlow at redhat.com
>         <mailto:smarlow at redhat.com>>:
>
>          > Hi Gunnar,
>          >
>          > Yes, this behaviour is expected since you registered an
>         non-interposed
>          > synchronization.  For what purpose are you registering the
>         transaction
>          > synchronization?  I would like to be aware of the
>         synchronizations that we
>          > register in WildFly.
>          >
>          > The non-interposed sync beforeCompletion callback are invoked
>         first, then
>          > the interposed sync beforeCompletion calls, then the interposed
>          > afterCompletion(int status) calls and finally, the non-interposed
>          > afterCompletion(int status) calls.
>          >
>          > The Synchronizations that are registered via the
>         javax.transaction.
>          >
>         TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization)
>          > [2] are interposed.
>          >
>          > Synchronizations that are registered via the
>         javax.transaction.Transaction.
>          > registerSynchronization(Synchronization) [3] are non-interposed.
>          >
>          > In WildFly, the transaction manager uses the registration
>         order within the
>          > interposed/non-interposed group.  Before completion syncs
>         (within their
>          > respective group), are run in registration order.  After
>         completion syncs
>          > (within their respective group), are run in reverse
>         registration order.
>          >
>          > I believe that your workaround, mentioned below, of using
>         JtaPlatform#registerSynchronization()
>          > on WildFly, is registering your synchronization as interposed
>         via the
>          > TransactionSynchronizationRegistry [2]. There might be a way
>         to register
>          > a sync callback at the Hibernate session level (which would
>         also run as
>          > interposed sync on WildFly).
>          >
>          > Not sure if you saw my email yesterday to Hibernate-dev ml.
>         You should be
>          > aware that the afterCompletion(int status) callback, may be
>         called from a
>          > non-application thread when the WildFly tm reaper handles tx
>         timeout (this
>          > can happen while the application thread is still invoking
>         calls on the
>          > Hibernate session).  Because the Hibernate session is not
>         thread safe, we
>          > need to ensure that the Hibernate session afterCompletion(int
>         status)
>          > callback does not mutate the Hibernate session (e.g. calling
>          > session.clear() what status == rolled back).
>          >
>          > Scott
>          >
>          > [2] http://docs.oracle.com/javaee/5/api/javax/transaction/
>          >
>         TransactionSynchronizationRegistry.html#registerInterposedSynchronizat
>          > ion%28javax.transaction.Synchronization%29
>          >
>          > [3] http://docs.oracle.com/javaee/5/api/javax/transaction/
>          > Transaction.html#registerSynchronization%28javax.transaction.
>          > Synchronization%29
>          >
>          >
>          > On 03/10/2015 09:03 AM, Gunnar Morling wrote:
>          >
>          >> Hi,
>          >>
>          >> I'm trying to perform a specific action upon transaction
>         rollback.
>          >>
>          >> Assuming this could be done using a custom
>          >> javax.transaction.Synchronization, I tried to register a
>         synchronization
>          >> as
>          >> follows:
>          >>
>          >>      TransactionImplementor transaction = ...; // e.g. a
>         CMTTransaction
>          >>      transaction.registerSynchronization( new MySync() );
>          >>
>          >> And indeed beforeCompletion() is invoked as expected. But
>          >> afterCompletion()
>          >> never is. I debugged this a bit on WildFly and observed the
>         following:
>          >>
>          >> * Hibernate ORM registers RegisteredSynchronization with JTA.
>          >> RegisteredSynchronization manages (indirectly, through
>          >> TransactionCoordinator, SynchronizationRegistry etc.) those
>          >> synchronizations added through o.h.t.Transaction.
>          >> registerSynchronization()
>          >> * WildFly (specifically, TransactionUtil [1]) registers its own
>          >> SessionSynchronization
>          >> for closing the entity manager/session
>          >>
>          >> Now that second synchronization is called first, closing the
>         session. Upon
>          >> SessionImpl#close(), the SynchronizationRegistry is cleared.
>         Then when
>          >> afterComplection() is called on RegisteredSynchronization
>         afterwards, any
>          >> previously registered delegate synchronizations are gone
>         already and thus
>          >> do not get invoked.
>          >>
>          >> I believe I found a workaround for my case by registering my
>          >> synchronization through
>         JtaPlatform#registerSynchronization() (which
>          >> registers it with the actual JTA transaction).
>          >>
>          >> My questions are:
>          >>
>          >> * Is this behaviour expected?
>          >> * Is the work-around of doing the registration via
>         JtaPlatform viable or
>          >> are there any drawbacks which I'm not aware of?
>          >>
>          >> Thanks,
>          >>
>          >> --Gunnar
>          >>
>          >> [1]
>          >> https://github.com/wildfly/wildfly/blob/master/jpa/src/
>          >> main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
>          >> _______________________________________________
>          >> hibernate-dev mailing list
>          >> hibernate-dev at lists.jboss.org
>         <mailto:hibernate-dev at lists.jboss.org>
>          >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>          >>
>          >>
>         _______________________________________________
>         hibernate-dev mailing list
>         hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>

From steve at hibernate.org  Tue Mar 10 18:17:31 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 10 Mar 2015 17:17:31 -0500
Subject: [hibernate-dev] Master
Message-ID: <CAFdSV9tkSPQFqJtUc3f4PSqpTphTwKbKOCBx5hX7ndLUt3+0dg@mail.gmail.com>

I wanted to given everyone a heads up that I just pushed the work I have
been doing up to master.  It is alot.  It covers most of what was planned
as required for 5.0.  The only outstanding item from that initial work is
to integrate the changes into Envers, but I was still waiting to hear back
from Adam and Lukasz about some design questions before proceeding with
that[1].

The main work involved:
1) breaking up Configuration into the bootstrap APIs we have been
discussing.  Configuration is still around and works as a mechanism to
build SessionFactory as long as that is all you do.
2) split naming strategy into implicit and explicit contracts.
3) switch from using dom4j to process hbm.xml files to JAXB+StAX

This release I started keeping a working list of changes, ideas, todos, and
things-to-discuss in the repo as working-5.0-migration-guide.md[2].  I will
base the Migration Guide for 5.0 on the top list here, so if you run into
anything that is not covered there and you think should be, let me know.
As for the "TODOs" and "Proposals for discussion" lists, take a look and
let me know if you have any thoughts.


[1] At the moment, this means that the top-level build will not run in its
entirety.  It will break as soon as it gets to Envers.
[2]
https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md

From emmanuel at hibernate.org  Wed Mar 11 04:43:49 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 11 Mar 2015 09:43:49 +0100
Subject: [hibernate-dev] Master
In-Reply-To: <CAFdSV9tkSPQFqJtUc3f4PSqpTphTwKbKOCBx5hX7ndLUt3+0dg@mail.gmail.com>
References: <CAFdSV9tkSPQFqJtUc3f4PSqpTphTwKbKOCBx5hX7ndLUt3+0dg@mail.gmail.com>
Message-ID: <20150311084349.GB833@hibernate.org>

Woohoo

On Tue 2015-03-10 17:17, Steve Ebersole wrote:
> I wanted to given everyone a heads up that I just pushed the work I have
> been doing up to master.  It is alot.  It covers most of what was planned
> as required for 5.0.  The only outstanding item from that initial work is
> to integrate the changes into Envers, but I was still waiting to hear back
> from Adam and Lukasz about some design questions before proceeding with
> that[1].
> 
> The main work involved:
> 1) breaking up Configuration into the bootstrap APIs we have been
> discussing.  Configuration is still around and works as a mechanism to
> build SessionFactory as long as that is all you do.
> 2) split naming strategy into implicit and explicit contracts.
> 3) switch from using dom4j to process hbm.xml files to JAXB+StAX
> 
> This release I started keeping a working list of changes, ideas, todos, and
> things-to-discuss in the repo as working-5.0-migration-guide.md[2].  I will
> base the Migration Guide for 5.0 on the top list here, so if you run into
> anything that is not covered there and you think should be, let me know.
> As for the "TODOs" and "Proposals for discussion" lists, take a look and
> let me know if you have any thoughts.
> 
> 
> [1] At the moment, this means that the top-level build will not run in its
> entirety.  It will break as soon as it gets to Envers.
> [2]
> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Wed Mar 11 05:04:31 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 11 Mar 2015 09:04:31 +0000
Subject: [hibernate-dev] Master
In-Reply-To: <20150311084349.GB833@hibernate.org>
References: <CAFdSV9tkSPQFqJtUc3f4PSqpTphTwKbKOCBx5hX7ndLUt3+0dg@mail.gmail.com>
	<20150311084349.GB833@hibernate.org>
Message-ID: <CAFm4XO2LErfWSLNE=LCVMKHVXrcFNwWTBcc3FD9eF4os0mgsLQ@mail.gmail.com>

On 11 March 2015 at 08:43, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Woohoo

+1 Nice!

The Envers module seems broken though?

Sanne

>
> On Tue 2015-03-10 17:17, Steve Ebersole wrote:
>> I wanted to given everyone a heads up that I just pushed the work I have
>> been doing up to master.  It is alot.  It covers most of what was planned
>> as required for 5.0.  The only outstanding item from that initial work is
>> to integrate the changes into Envers, but I was still waiting to hear back
>> from Adam and Lukasz about some design questions before proceeding with
>> that[1].
>>
>> The main work involved:
>> 1) breaking up Configuration into the bootstrap APIs we have been
>> discussing.  Configuration is still around and works as a mechanism to
>> build SessionFactory as long as that is all you do.
>> 2) split naming strategy into implicit and explicit contracts.
>> 3) switch from using dom4j to process hbm.xml files to JAXB+StAX
>>
>> This release I started keeping a working list of changes, ideas, todos, and
>> things-to-discuss in the repo as working-5.0-migration-guide.md[2].  I will
>> base the Migration Guide for 5.0 on the top list here, so if you run into
>> anything that is not covered there and you think should be, let me know.
>> As for the "TODOs" and "Proposals for discussion" lists, take a look and
>> let me know if you have any thoughts.
>>
>>
>> [1] At the moment, this means that the top-level build will not run in its
>> entirety.  It will break as soon as it gets to Envers.
>> [2]
>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>> _______________________________________________
>> 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

From hardy at hibernate.org  Wed Mar 11 05:20:54 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 11 Mar 2015 10:20:54 +0100
Subject: [hibernate-dev] Master
In-Reply-To: <20150311084349.GB833@hibernate.org>
References: <CAFdSV9tkSPQFqJtUc3f4PSqpTphTwKbKOCBx5hX7ndLUt3+0dg@mail.gmail.com>
	<20150311084349.GB833@hibernate.org>
Message-ID: <20150311092054.GA21712@Sarmakand-4.local>

On Wed, Mar 11, 2015 at 09:43:49AM +0100, Emmanuel Bernard wrote:
> Woohoo

Woot!

"1,291 changed files with 34,601 additions and 220 deletions" - not bad ;-)

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150311/fbed7750/attachment.bin 

From steve at hibernate.org  Wed Mar 11 10:29:01 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 11 Mar 2015 09:29:01 -0500
Subject: [hibernate-dev] Master
In-Reply-To: <20150311092054.GA21712@Sarmakand-4.local>
References: <CAFdSV9tkSPQFqJtUc3f4PSqpTphTwKbKOCBx5hX7ndLUt3+0dg@mail.gmail.com>
	<20150311084349.GB833@hibernate.org>
	<20150311092054.GA21712@Sarmakand-4.local>
Message-ID: <CAFdSV9tujyW2gSSiBe=5UP0GHA6B8MSE5nomyAW1YRrJ4aeEzg@mail.gmail.com>

At first I read that as 34,601 files added and was like "whaaaa!!" :)

On Wed, Mar 11, 2015 at 4:20 AM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> On Wed, Mar 11, 2015 at 09:43:49AM +0100, Emmanuel Bernard wrote:
> > Woohoo
>
> Woot!
>
> "1,291 changed files with 34,601 additions and 220 deletions" - not bad ;-)
>
> --Hardy
>

From steve at hibernate.org  Wed Mar 11 10:29:46 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 11 Mar 2015 09:29:46 -0500
Subject: [hibernate-dev] Master
In-Reply-To: <CAFm4XO2LErfWSLNE=LCVMKHVXrcFNwWTBcc3FD9eF4os0mgsLQ@mail.gmail.com>
References: <CAFdSV9tkSPQFqJtUc3f4PSqpTphTwKbKOCBx5hX7ndLUt3+0dg@mail.gmail.com>
	<20150311084349.GB833@hibernate.org>
	<CAFm4XO2LErfWSLNE=LCVMKHVXrcFNwWTBcc3FD9eF4os0mgsLQ@mail.gmail.com>
Message-ID: <CAFdSV9sWSSDbqwq6af3h5-VWLmECW8R8Up0gnm95KtRUTsd3ww@mail.gmail.com>

On Wed, Mar 11, 2015 at 4:04 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 11 March 2015 at 08:43, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> > Woohoo
>
> +1 Nice!
>
> The Envers module seems broken though?
>
> Sanne
>
> >
> > On Tue 2015-03-10 17:17, Steve Ebersole wrote:
> >> I wanted to given everyone a heads up that I just pushed the work I have
> >> been doing up to master.  It is alot.  It covers most of what was
> planned
> >> as required for 5.0.  The only outstanding item from that initial work
> is
> >> to integrate the changes into Envers, but I was still waiting to hear
> back
> >> from Adam and Lukasz about some design questions before proceeding with
> >> that[1].
> >>
> >> [1] At the moment, this means that the top-level build will not run in
> its
> >> entirety.  It will break as soon as it gets to Envers.
>

Yep :)

From gunnar at hibernate.org  Wed Mar 11 10:39:52 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 11 Mar 2015 15:39:52 +0100
Subject: [hibernate-dev] Master
In-Reply-To: <20150311092054.GA21712@Sarmakand-4.local>
References: <CAFdSV9tkSPQFqJtUc3f4PSqpTphTwKbKOCBx5hX7ndLUt3+0dg@mail.gmail.com>
	<20150311084349.GB833@hibernate.org>
	<20150311092054.GA21712@Sarmakand-4.local>
Message-ID: <CADGJaX8dZJGP+LTyShfg0G7hTaPFixHX7G9N5nFGVOtRTOscAA@mail.gmail.com>

2015-03-11 10:20 GMT+01:00 Hardy Ferentschik <hardy at hibernate.org>:

> On Wed, Mar 11, 2015 at 09:43:49AM +0100, Emmanuel Bernard wrote:
> > Woohoo
>
> Woot!
>
> "1,291 changed files with 34,601 additions and 220 deletions" - not bad ;-)
>

My thoughts are with the poor soul who had to review that PR ;)


>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Mar 11 11:27:31 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 11 Mar 2015 15:27:31 +0000
Subject: [hibernate-dev] Strange issue massindexer and classbridge
In-Reply-To: <CAGvEgx7gjN6iM8gPNKZG+rVixO=vSdy6S6oOPuod3+amKW0mFA@mail.gmail.com>
References: <CAGvEgx7gjN6iM8gPNKZG+rVixO=vSdy6S6oOPuod3+amKW0mFA@mail.gmail.com>
Message-ID: <CAFm4XO1TvfgpiH9Xu0aOkxNUBaSuzRaK0ay6-osyT15-v=yFSw@mail.gmail.com>

Hi Marc,
my first guess would be that somehow the custom ClassBridge causes an
error? maybe an exception you can find in the logs?
Remember exceptions during indexing are not propagated to the
originator thread, but handled by the ErrorHandler - which by default
logs them.

Sanne

On 10 March 2015 at 16:24, Marc Schipperheyn <m.schipperheyn at gmail.com> wrote:
> Hi,
>
> I just wanted to share a strange issue I had w the massindexer and a
> classbridge where a whole class of entities was not being indexed by the
> massindexer (Hibernate Search 5.1).
>
> The entity in question was part of an inheritance hierarchy.
>
> Something like
> BaseComment
>     Comment
>     Post
>     RSSPost
>
> I noticed that only the "Post" entities were missing from the index after
> running the massindexer against BaseComment. Tried various times.
>
> Any new entity entered would end up in the index correctly.
>
> I finally removed a ClassBridge I use on that entity and restarted.
> MassIndexer then worked correctly. And continued to work correctly after
> restarts even w the classbridge active again.
>
> I have been switching between Hibernate 4.x and 5.1 regularly and
> re-indexing every time without manually cleaning the index directories.
> Perhaps this had something to do with it.
>
> Cheers,
> Marc
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Mar 11 11:45:14 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 11 Mar 2015 10:45:14 -0500
Subject: [hibernate-dev] Master
In-Reply-To: <CADGJaX8dZJGP+LTyShfg0G7hTaPFixHX7G9N5nFGVOtRTOscAA@mail.gmail.com>
References: <CAFdSV9tkSPQFqJtUc3f4PSqpTphTwKbKOCBx5hX7ndLUt3+0dg@mail.gmail.com>
	<20150311084349.GB833@hibernate.org>
	<20150311092054.GA21712@Sarmakand-4.local>
	<CADGJaX8dZJGP+LTyShfg0G7hTaPFixHX7G9N5nFGVOtRTOscAA@mail.gmail.com>
Message-ID: <CAFdSV9vBzjNH0+jJMtcmifjFfNEzjWZXVu095+Wh2ua8id=jvw@mail.gmail.com>

You mean y'all? ;)

On Wed, Mar 11, 2015 at 9:39 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

>
>
> 2015-03-11 10:20 GMT+01:00 Hardy Ferentschik <hardy at hibernate.org>:
>
>> On Wed, Mar 11, 2015 at 09:43:49AM +0100, Emmanuel Bernard wrote:
>> > Woohoo
>>
>> Woot!
>>
>> "1,291 changed files with 34,601 additions and 220 deletions" - not bad
>> ;-)
>>
>
> My thoughts are with the poor soul who had to review that PR ;)
>
>
>>
>> --Hardy
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From m.schipperheyn at gmail.com  Wed Mar 11 14:48:00 2015
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Wed, 11 Mar 2015 15:48:00 -0300
Subject: [hibernate-dev] Strange issue massindexer and classbridge
In-Reply-To: <CAFm4XO1TvfgpiH9Xu0aOkxNUBaSuzRaK0ay6-osyT15-v=yFSw@mail.gmail.com>
References: <CAGvEgx7gjN6iM8gPNKZG+rVixO=vSdy6S6oOPuod3+amKW0mFA@mail.gmail.com>
	<CAFm4XO1TvfgpiH9Xu0aOkxNUBaSuzRaK0ay6-osyT15-v=yFSw@mail.gmail.com>
Message-ID: <CAGvEgx4FNgqt1q32CZTvqTm+Zk7Qnk+nqTVUsfT71L0Mk7d9Zg@mail.gmail.com>

Nope, no errors.

From hardy at hibernate.org  Wed Mar 11 15:07:47 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 11 Mar 2015 20:07:47 +0100
Subject: [hibernate-dev] Strange issue massindexer and classbridge
In-Reply-To: <CAGvEgx4FNgqt1q32CZTvqTm+Zk7Qnk+nqTVUsfT71L0Mk7d9Zg@mail.gmail.com>
References: <CAGvEgx7gjN6iM8gPNKZG+rVixO=vSdy6S6oOPuod3+amKW0mFA@mail.gmail.com>
	<CAFm4XO1TvfgpiH9Xu0aOkxNUBaSuzRaK0ay6-osyT15-v=yFSw@mail.gmail.com>
	<CAGvEgx4FNgqt1q32CZTvqTm+Zk7Qnk+nqTVUsfT71L0Mk7d9Zg@mail.gmail.com>
Message-ID: <20150311190747.GF21712@Sarmakand-4.local>

On Wed, Mar 11, 2015 at 03:48:00PM -0300, Marc Schipperheyn wrote:
> Nope, no errors.

Are you able to extract a test case. It is really nothing which rings a bell directly.
I think we would need to see this happen in a test scenario to be able to dig deeper.

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150311/9f9ebd36/attachment.bin 

From m.schipperheyn at gmail.com  Wed Mar 11 16:50:21 2015
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Wed, 11 Mar 2015 17:50:21 -0300
Subject: [hibernate-dev] Strange issue massindexer and classbridge
In-Reply-To: <20150311190747.GF21712@Sarmakand-4.local>
References: <CAGvEgx7gjN6iM8gPNKZG+rVixO=vSdy6S6oOPuod3+amKW0mFA@mail.gmail.com>
	<CAFm4XO1TvfgpiH9Xu0aOkxNUBaSuzRaK0ay6-osyT15-v=yFSw@mail.gmail.com>
	<CAGvEgx4FNgqt1q32CZTvqTm+Zk7Qnk+nqTVUsfT71L0Mk7d9Zg@mail.gmail.com>
	<20150311190747.GF21712@Sarmakand-4.local>
Message-ID: <CAGvEgx74jEC0weNNZgtDq3rwtbqsYPEnE_uKFNysmZ4n4wp_9w@mail.gmail.com>

Are you able to extract a test case. It is really nothing which rings a
bell directly.
I think we would need to see this happen in a test scenario to be able to
dig deeper.

> No, don't have time for that. It's a little too edgy for me to spend time
on. If it happens again, I'll try to physically delete the index and
reindexing. I'll report if I can add anything interesting.

Cheers,
Marc

From sanne at hibernate.org  Wed Mar 11 21:03:53 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 12 Mar 2015 01:03:53 +0000
Subject: [hibernate-dev] New testing utility for the Logger
Message-ID: <CAFm4XO2e59OMpJ23JPYV25a29W9PkA6jOjbMPDhJbXu=wzVnCw@mail.gmail.com>

Hi all,
since we recently had some issues to solve with the general theme
"verify X will not be logged", or sometimes we need the opposite: to
make sure that something *is* logged, I've abused a new feature of
JBoss Logger to make it easier to test.

Details on the PR:
 - https://github.com/hibernate/hibernate-orm/pull/906

I was hoping to use it in other projects too but the "catch" section
explains why that's not going to work yet, so I'd suggest start
benefiting from it in ORM 5 and then see how it evolves.

Happy logging :)

Sanne

From sanne at hibernate.org  Thu Mar 12 09:21:42 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 12 Mar 2015 13:21:42 +0000
Subject: [hibernate-dev] [Hibernate Search] Validating the Sort field
Message-ID: <CAFm4XO1jaoo1=JKgAR4PCSGBLb3gVuqRpzdXP+unOg98yNbAwA@mail.gmail.com>

A forums user asked why we don't validate the Sort field being set on
a FullTextQuery.

I've tried to summarize some of the reasons of why it's a complex
thing, still it's something worth considering.

Let's keep it in mind as yet another reason to try intercept which
fields are being written by custom FieldBridge instances?

Considering the special needs of a Sort field - being unique, being
fieldcacheable/documentValues enabled, maybe we should even consider
that adding them should have its own API, maybe even dedicated mapping
annotations.
Or other ideas very welcome.

https://forum.hibernate.org/viewtopic.php?f=9&t=1038601

Thanks,
Sanne

From steve at hibernate.org  Thu Mar 12 21:35:54 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 12 Mar 2015 20:35:54 -0500
Subject: [hibernate-dev] Master
In-Reply-To: <CAFdSV9vBzjNH0+jJMtcmifjFfNEzjWZXVu095+Wh2ua8id=jvw@mail.gmail.com>
References: <CAFdSV9tkSPQFqJtUc3f4PSqpTphTwKbKOCBx5hX7ndLUt3+0dg@mail.gmail.com>
	<20150311084349.GB833@hibernate.org>
	<20150311092054.GA21712@Sarmakand-4.local>
	<CADGJaX8dZJGP+LTyShfg0G7hTaPFixHX7G9N5nFGVOtRTOscAA@mail.gmail.com>
	<CAFdSV9vBzjNH0+jJMtcmifjFfNEzjWZXVu095+Wh2ua8id=jvw@mail.gmail.com>
Message-ID: <CAFdSV9v8rSraWx0Xso7AiReQcxqNGi-edy6OcnrvWYM1XRnKYg@mail.gmail.com>

OK, so I ran into a speed bump with Envers.  For those not familiar, Envers
essentially iterates over all the entity mappings Hibernate has built for
user entities and dynamically builds a DOM(4J) Document representing the
audit entity corollaries.  I had planned to simply bridge that to our JAXB
process in ORM using a DOMSource to wrap the Document Envers built as input
into the StAX+JAXB pipeline.  Well it turns out that does not really work.
It did not work with the JDK built in parsers.  I even tried swapping in
Woodstox but ran into problems there too.

So, unless someone has a quick suggestion for this, I will have to convert
Envers to build the JAXB model directly.  Which will take some time.

On Wed, Mar 11, 2015 at 10:45 AM, Steve Ebersole <steve at hibernate.org>
wrote:

> You mean y'all? ;)
>
> On Wed, Mar 11, 2015 at 9:39 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>>
>>
>> 2015-03-11 10:20 GMT+01:00 Hardy Ferentschik <hardy at hibernate.org>:
>>
>>> On Wed, Mar 11, 2015 at 09:43:49AM +0100, Emmanuel Bernard wrote:
>>> > Woohoo
>>>
>>> Woot!
>>>
>>> "1,291 changed files with 34,601 additions and 220 deletions" - not bad
>>> ;-)
>>>
>>
>> My thoughts are with the poor soul who had to review that PR ;)
>>
>>
>>>
>>> --Hardy
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From sanne at hibernate.org  Fri Mar 13 08:35:05 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 13 Mar 2015 12:35:05 +0000
Subject: [hibernate-dev] ci@hibernate.org vs jenkins@hibernate.org
Message-ID: <CAFm4XO3BbK7t5eL2Zdt253eR2Bp3gORx64MPpezbFXvXecrW=g@mail.gmail.com>

All,
in various build configuration on ci.hibernate.org, it's using an
email alias "jenkins at hibernate.org".

Please use "ci at hibernate.org" instead, as the other one triggers
errors being sent to me in large volumes..
I've tried to get rid of them myself over time, but it seems you all
are fighting back on that when updating / creating new jobs :)

So the right email to use is:
 ci at hibernate.org

thanks,
Sanne

From steve at hibernate.org  Fri Mar 13 10:37:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Mar 2015 09:37:55 -0500
Subject: [hibernate-dev] Master
In-Reply-To: <CAFdSV9v8rSraWx0Xso7AiReQcxqNGi-edy6OcnrvWYM1XRnKYg@mail.gmail.com>
References: <CAFdSV9tkSPQFqJtUc3f4PSqpTphTwKbKOCBx5hX7ndLUt3+0dg@mail.gmail.com>
	<20150311084349.GB833@hibernate.org>
	<20150311092054.GA21712@Sarmakand-4.local>
	<CADGJaX8dZJGP+LTyShfg0G7hTaPFixHX7G9N5nFGVOtRTOscAA@mail.gmail.com>
	<CAFdSV9vBzjNH0+jJMtcmifjFfNEzjWZXVu095+Wh2ua8id=jvw@mail.gmail.com>
	<CAFdSV9v8rSraWx0Xso7AiReQcxqNGi-edy6OcnrvWYM1XRnKYg@mail.gmail.com>
Message-ID: <CAFdSV9sO7RLJ3zj8n5xGSzLCJCHnHvUJQdc=xjC+hUa+07TU5w@mail.gmail.com>

Interesting.  If I disable schema (xml) validation, it works.  Seems that
Envers is just not producing valid XML.

On Thu, Mar 12, 2015 at 8:35 PM, Steve Ebersole <steve at hibernate.org> wrote:

> OK, so I ran into a speed bump with Envers.  For those not familiar,
> Envers essentially iterates over all the entity mappings Hibernate has
> built for user entities and dynamically builds a DOM(4J) Document
> representing the audit entity corollaries.  I had planned to simply bridge
> that to our JAXB process in ORM using a DOMSource to wrap the Document
> Envers built as input into the StAX+JAXB pipeline.  Well it turns out that
> does not really work.  It did not work with the JDK built in parsers.  I
> even tried swapping in Woodstox but ran into problems there too.
>
> So, unless someone has a quick suggestion for this, I will have to convert
> Envers to build the JAXB model directly.  Which will take some time.
>
> On Wed, Mar 11, 2015 at 10:45 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> You mean y'all? ;)
>>
>> On Wed, Mar 11, 2015 at 9:39 AM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>>
>>>
>>> 2015-03-11 10:20 GMT+01:00 Hardy Ferentschik <hardy at hibernate.org>:
>>>
>>>> On Wed, Mar 11, 2015 at 09:43:49AM +0100, Emmanuel Bernard wrote:
>>>> > Woohoo
>>>>
>>>> Woot!
>>>>
>>>> "1,291 changed files with 34,601 additions and 220 deletions" - not bad
>>>> ;-)
>>>>
>>>
>>> My thoughts are with the poor soul who had to review that PR ;)
>>>
>>>
>>>>
>>>> --Hardy
>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>
>

From sanne at hibernate.org  Sun Mar 15 19:36:00 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 15 Mar 2015 23:36:00 +0000
Subject: [hibernate-dev] ORM5 : Reusing the Configuration instance
Message-ID: <CAFm4XO3SOE3Z1-_O2rEcg9sttZsAU5bb=2nqEbp_Vs+HUqyQ0w@mail.gmail.com>

Hi all,
I'm trying to get an experimental branch of Hibernate Search to work
with the latest snapshot of Hibernate ORM 5.

After a bit of refactoring of our integration SPIs I thought it was
ready for some testing, but came to some surprising errors from the
ServiceLoader not finding the implementations from Hibernate Search -
although it would find the service definition of it.

After a bit more investigating, it turns out that the Integrator works
fine for each first test of our testsuite; it turns out that the
ClassLoaderService is referenced by the Configuration instance, and
this specific service nulls out all references to classloaders on
shutdown of the SessionFactory (which happens at the end of each of
our tests).

When the second test runs, it's reusing the same instance of ORM's
Configuration and so the ClassLoaderService gets reused and not
properly re-initialized, so it's not able to load any class.

So I'm wondering now if we should stop re-using the Configuration
instance in Search across tests, or if the ClassLoaderService in ORM
should be re-initialized on restart?
(this re-using business is mostly a convenience for how the Search
testsuite works but not strictly necessary)

If we should stop reusing the Configuration instances, then I'd like
to add a validation in ORM as the errormessage thrown from the
java.util.ServiceConfigurationError is confusing.

Thanks,
Sanne

From hardy at hibernate.org  Mon Mar 16 16:57:19 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 16 Mar 2015 21:57:19 +0100
Subject: [hibernate-dev] ORM5 : Reusing the Configuration instance
In-Reply-To: <CAFm4XO3SOE3Z1-_O2rEcg9sttZsAU5bb=2nqEbp_Vs+HUqyQ0w@mail.gmail.com>
References: <CAFm4XO3SOE3Z1-_O2rEcg9sttZsAU5bb=2nqEbp_Vs+HUqyQ0w@mail.gmail.com>
Message-ID: <20150316205719.GB24576@Nineveh.local>

Hi,

given that the SessionFactory gets closed after each test, I think it would 
only be fair to also rebuild the Configuration on each test set-up.
What is the reason for keeping it around anyways? Do the tests run
considerably slower when re-building the Configuration for each test?

--Hardy

On Sun, Mar 15, 2015 at 11:36:00PM +0000, Sanne Grinovero wrote:
> Hi all,
> I'm trying to get an experimental branch of Hibernate Search to work
> with the latest snapshot of Hibernate ORM 5.
> 
> After a bit of refactoring of our integration SPIs I thought it was
> ready for some testing, but came to some surprising errors from the
> ServiceLoader not finding the implementations from Hibernate Search -
> although it would find the service definition of it.
> 
> After a bit more investigating, it turns out that the Integrator works
> fine for each first test of our testsuite; it turns out that the
> ClassLoaderService is referenced by the Configuration instance, and
> this specific service nulls out all references to classloaders on
> shutdown of the SessionFactory (which happens at the end of each of
> our tests).
> 
> When the second test runs, it's reusing the same instance of ORM's
> Configuration and so the ClassLoaderService gets reused and not
> properly re-initialized, so it's not able to load any class.
> 
> So I'm wondering now if we should stop re-using the Configuration
> instance in Search across tests, or if the ClassLoaderService in ORM
> should be re-initialized on restart?
> (this re-using business is mostly a convenience for how the Search
> testsuite works but not strictly necessary)
> 
> If we should stop reusing the Configuration instances, then I'd like
> to add a validation in ORM as the errormessage thrown from the
> java.util.ServiceConfigurationError is confusing.
> 
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150316/68e5b999/attachment.bin 

From sanne at hibernate.org  Mon Mar 16 17:21:33 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 16 Mar 2015 21:21:33 +0000
Subject: [hibernate-dev] ORM5 : Reusing the Configuration instance
In-Reply-To: <20150316205719.GB24576@Nineveh.local>
References: <CAFm4XO3SOE3Z1-_O2rEcg9sttZsAU5bb=2nqEbp_Vs+HUqyQ0w@mail.gmail.com>
	<20150316205719.GB24576@Nineveh.local>
Message-ID: <CAFm4XO39_7VXFopCUdozE_jHFRUWtNaE3Av8_NSLhOYH+HMr=A@mail.gmail.com>

On 16 March 2015 at 20:57, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> given that the SessionFactory gets closed after each test, I think it would
> only be fair to also rebuild the Configuration on each test set-up.
> What is the reason for keeping it around anyways? Do the tests run
> considerably slower when re-building the Configuration for each test?

I'm not sure, git is pointing to your name :-) See:
org.hibernate.search.test.TestResourceManager
It probably grew a bit of complexity over time and while I'm not sure
of what the original intention could be, I tend to agree with the
basic idea.

Even if we probably won't win much in terms of performance /
practicality and we were to agree to simplify this, the following
message is confusing:

java.util.ServiceConfigurationError:
org.hibernate.service.spi.ServiceContributor: Provider
org.hibernate.search.hcore.impl.SearchFactoryServiceContributor not
found
     at java.util.ServiceLoader.fail(ServiceLoader.java:231)
     at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
     at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:365)
     at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
     at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:339)
     at org.hibernate.boot.registry.StandardServiceRegistryBuilder.applyServiceContributors(StandardServiceRegistryBuilder.java:319)
     at org.hibernate.boot.registry.StandardServiceRegistryBuilder.build(StandardServiceRegistryBuilder.java:296)
     at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:740)

As an Hibernate ORM user I would expect the Configuration to be
reusable, and probably immutable as well.

Sanne


>
> --Hardy
>
> On Sun, Mar 15, 2015 at 11:36:00PM +0000, Sanne Grinovero wrote:
>> Hi all,
>> I'm trying to get an experimental branch of Hibernate Search to work
>> with the latest snapshot of Hibernate ORM 5.
>>
>> After a bit of refactoring of our integration SPIs I thought it was
>> ready for some testing, but came to some surprising errors from the
>> ServiceLoader not finding the implementations from Hibernate Search -
>> although it would find the service definition of it.
>>
>> After a bit more investigating, it turns out that the Integrator works
>> fine for each first test of our testsuite; it turns out that the
>> ClassLoaderService is referenced by the Configuration instance, and
>> this specific service nulls out all references to classloaders on
>> shutdown of the SessionFactory (which happens at the end of each of
>> our tests).
>>
>> When the second test runs, it's reusing the same instance of ORM's
>> Configuration and so the ClassLoaderService gets reused and not
>> properly re-initialized, so it's not able to load any class.
>>
>> So I'm wondering now if we should stop re-using the Configuration
>> instance in Search across tests, or if the ClassLoaderService in ORM
>> should be re-initialized on restart?
>> (this re-using business is mostly a convenience for how the Search
>> testsuite works but not strictly necessary)
>>
>> If we should stop reusing the Configuration instances, then I'd like
>> to add a validation in ORM as the errormessage thrown from the
>> java.util.ServiceConfigurationError is confusing.
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sfikes at redhat.com  Mon Mar 16 18:31:14 2015
From: sfikes at redhat.com (Stephen Fikes)
Date: Mon, 16 Mar 2015 17:31:14 -0500
Subject: [hibernate-dev] org.hibernate.AnnotationException: No identifier
 specified for entity
Message-ID: <1426545074.14038.6.camel@sfikes.localdomain>

https://docs.jboss.org/hibernate/orm/4.2/manual/en-US/html_single/#persistent-classes-pojo-identifier

The link above observes that the requirement to provide an identifier
for every entity is "... still not (yet) enforced" but "... should be
considered a deprecated feature as it will be completely required to
provide a identifier property in an upcoming release."

When using annotations, it seems to be required as far back as 3.3.2.GA.

Perhaps the requirement is not enforced when using hbm.xml ... but is
only for annotations.

Should we update the document comment to clarify?

Thanks!
Stephen


From elliot.huntington at gmail.com  Mon Mar 16 18:59:55 2015
From: elliot.huntington at gmail.com (Elliot Huntington)
Date: Mon, 16 Mar 2015 16:59:55 -0600
Subject: [hibernate-dev] Hibernate support for JSR-354?
Message-ID: <CAEm7nbFim=wcZXNZWFWMWf0in15DyhwaOVvwDbw2GuJnDDkyHw@mail.gmail.com>

Hi,

It looks like JSR-354 is progressing nicely and might be included in Java
9. It also looks like the SpringFramework is actively working on including
binding and formatting support for this JSR (
https://jira.spring.io/browse/SPR-12209). Has there been any discussion for
Hibernate to support an out of the box UserType to support persisting a
MonetaryAmount?

I am in the process of writing my own solution but this is the first
UserType I've created and I hope someone here can help me with it. I posted
a question on StackOverflow (
http://stackoverflow.com/questions/29084830/multi-column-usertype-comparable-operations-not-working)
about how to customize the sql query that is generated by hibernate for a
custom multi-column UserType. I'm hoping someone reading this mailing list
will be able to provide a helpful answer.

Thank you,
Elliot Huntington

From smarlow at redhat.com  Tue Mar 17 09:40:52 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 17 Mar 2015 09:40:52 -0400
Subject: [hibernate-dev] Question about Jandex composite indexes passed into
 via "hibernate.jandex_index" and whether ORM keeps a strong reference to
 Jandex indexes after deployment...
Message-ID: <55082EE4.7080305@redhat.com>

Steve,

Wildfly-dev [1] brings up a change expected for WildFly 10, to not 
reference the Jandex indexes after deployment completes.  I'm curious if 
our current/planned ORM 5.0 jandex using code, keeps a reference to the 
passed in "hibernate.jandex_index"?

How how hard would it be for ORM, to only reference the composite Jandex 
index during application deployment time?  Deployment time ends when 
PersistenceProvider.createContainerEntityManagerFactory() returns.

Scott

[1] http://lists.jboss.org/pipermail/wildfly-dev/2015-March/003679.html

From hardy at hibernate.org  Tue Mar 17 10:48:13 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 17 Mar 2015 15:48:13 +0100
Subject: [hibernate-dev] ORM5 : Reusing the Configuration instance
In-Reply-To: <CAFm4XO39_7VXFopCUdozE_jHFRUWtNaE3Av8_NSLhOYH+HMr=A@mail.gmail.com>
References: <CAFm4XO3SOE3Z1-_O2rEcg9sttZsAU5bb=2nqEbp_Vs+HUqyQ0w@mail.gmail.com>
	<20150316205719.GB24576@Nineveh.local>
	<CAFm4XO39_7VXFopCUdozE_jHFRUWtNaE3Av8_NSLhOYH+HMr=A@mail.gmail.com>
Message-ID: <20150317144813.GA75073@Nineveh.lan>

Hi,

On Mon, Mar 16, 2015 at 09:21:33PM +0000, Sanne Grinovero wrote:
> > given that the SessionFactory gets closed after each test, I think it would
> > only be fair to also rebuild the Configuration on each test set-up.
> > What is the reason for keeping it around anyways? Do the tests run
> > considerably slower when re-building the Configuration for each test?
> 
> I'm not sure, git is pointing to your name :-) See:
> org.hibernate.search.test.TestResourceManager

Sure, I remember changing and refactoring the test base class quite often.
However, the re-use of the Configuration is something which has been in the code
as long as I remember. 

> It probably grew a bit of complexity over time and while I'm not sure
> of what the original intention could be, I tend to agree with the
> basic idea

That the Configuration should be re-usable?

> Even if we probably won't win much in terms of performance /
> practicality and we were to agree to simplify this, the following
> message is confusing:
> 
> java.util.ServiceConfigurationError:
> org.hibernate.service.spi.ServiceContributor: Provider
> org.hibernate.search.hcore.impl.SearchFactoryServiceContributor not
> found
>      at java.util.ServiceLoader.fail(ServiceLoader.java:231)
>      at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
>      at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:365)
>      at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
>      at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:339)
>      at org.hibernate.boot.registry.StandardServiceRegistryBuilder.applyServiceContributors(StandardServiceRegistryBuilder.java:319)
>      at org.hibernate.boot.registry.StandardServiceRegistryBuilder.build(StandardServiceRegistryBuilder.java:296)
>      at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:740)

+1

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150317/cfe272d0/attachment.bin 

From sanne at hibernate.org  Tue Mar 17 21:03:25 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 18 Mar 2015 01:03:25 +0000
Subject: [hibernate-dev] An update on Jenkins slaves
Message-ID: <CAFm4XO07qKZQ_Da8RgnOyJM88f9oh1PzynF98=PigSycdFLSfg@mail.gmail.com>

Our ci.hibernate.org now has 3 slaves connected; we can reconfigure
some jobs to use the new slaves already, and gradually move all of them so
that we can re-enable parallel builds, and then scale back on the
compute power of our master node.

The bad news is that I've been waiting 3 hours now for the first build
of Hibernate Search to get at least to run the tests, but it's still
downloading Maven dependencies at the staggering speed of 10Kb/sec.

 http://ci.hibernate.org/job/hibernate-search-master/387/console

I'll try to find out if there is something wrong with our
configuration, or maybe Nexus having maintenance, or some maintenance
of the OS1 cloud...
but if not, that's a deal breaker.

Sanne

From sanne at hibernate.org  Wed Mar 18 09:47:13 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 18 Mar 2015 13:47:13 +0000
Subject: [hibernate-dev] Hibernate support for JSR-354?
In-Reply-To: <CAEm7nbFim=wcZXNZWFWMWf0in15DyhwaOVvwDbw2GuJnDDkyHw@mail.gmail.com>
References: <CAEm7nbFim=wcZXNZWFWMWf0in15DyhwaOVvwDbw2GuJnDDkyHw@mail.gmail.com>
Message-ID: <CAFm4XO1=RFvMFmZ-Y9DMUDky49cRAGH_tmY44qnV+xs0Gsm5TQ@mail.gmail.com>

Hi Elliot,
I'm not the best person to answer your more technical questions, but
since those who are are currently on holidays I'd just like to answer
you already and confirm it's an interesting topic.

We had a similar discussion around Date/Time types in Java8: they also
aren't supported yet out of the box, but we'd really like to add
those, as JSR-354 when it will be included.
The main problem is to split support for these into JDK8, and JDK9
specific modules, and get the build scripts patched to deal with
different requirements of language levels. I hope we'll do that soon,
at that point it would be awesome to include your custom types,
assuming you want to contribute.

This project seems to have types for both Time and Money types:
 http://jadira.sourceforge.net/usertype-userguide.html

I have no experience with it, I just found it by following a link from
the Joda Time project, which is known to have created good extensions
in the past - although I think it was best known for Time types only.
Could be nice to join forces with Jadira or at least study their
proposal?

Thanks,
Sanne


On 16 March 2015 at 22:59, Elliot Huntington
<elliot.huntington at gmail.com> wrote:
> Hi,
>
> It looks like JSR-354 is progressing nicely and might be included in Java
> 9. It also looks like the SpringFramework is actively working on including
> binding and formatting support for this JSR (
> https://jira.spring.io/browse/SPR-12209). Has there been any discussion for
> Hibernate to support an out of the box UserType to support persisting a
> MonetaryAmount?
>
> I am in the process of writing my own solution but this is the first
> UserType I've created and I hope someone here can help me with it. I posted
> a question on StackOverflow (
> http://stackoverflow.com/questions/29084830/multi-column-usertype-comparable-operations-not-working)
> about how to customize the sql query that is generated by hibernate for a
> custom multi-column UserType. I'm hoping someone reading this mailing list
> will be able to provide a helpful answer.
>
> Thank you,
> Elliot Huntington
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Mar 18 11:20:44 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Mar 2015 10:20:44 -0500
Subject: [hibernate-dev] Getting back
Message-ID: <CAFdSV9tYrWiMry2TFTopCO6TFj1246_1uEkworsASR+j97yYiw@mail.gmail.com>

Hey all.  Just a heads up that I had been in Big Bend the last few days.
No data service out there; yes, I choose my getaway spots well ;)

Anyway, I will be getting to the emails from the past few days today and
tomorrow.

From steve at hibernate.org  Wed Mar 18 11:22:03 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Mar 2015 10:22:03 -0500
Subject: [hibernate-dev] Question about Jandex composite indexes passed
 into via "hibernate.jandex_index" and whether ORM keeps a strong reference
 to Jandex indexes after deployment...
In-Reply-To: <55082EE4.7080305@redhat.com>
References: <55082EE4.7080305@redhat.com>
Message-ID: <CAFdSV9s5ydYUqzQzw7oQCXJxvH4UeZ4dWi0gFO2PqhRtpCYqwA@mail.gmail.com>

I don't *think* we do, but it sounds like something we definitely need to
make sure we aren't doing.
On Mar 17, 2015 8:41 AM, "Scott Marlow" <smarlow at redhat.com> wrote:

> Steve,
>
> Wildfly-dev [1] brings up a change expected for WildFly 10, to not
> reference the Jandex indexes after deployment completes.  I'm curious if
> our current/planned ORM 5.0 jandex using code, keeps a reference to the
> passed in "hibernate.jandex_index"?
>
> How how hard would it be for ORM, to only reference the composite Jandex
> index during application deployment time?  Deployment time ends when
> PersistenceProvider.createContainerEntityManagerFactory() returns.
>
> Scott
>
> [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-March/003679.html
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Mar 18 13:05:02 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Mar 2015 12:05:02 -0500
Subject: [hibernate-dev] Question about Jandex composite indexes passed
 into via "hibernate.jandex_index" and whether ORM keeps a strong reference
 to Jandex indexes after deployment...
In-Reply-To: <CAFdSV9s5ydYUqzQzw7oQCXJxvH4UeZ4dWi0gFO2PqhRtpCYqwA@mail.gmail.com>
References: <55082EE4.7080305@redhat.com>
	<CAFdSV9s5ydYUqzQzw7oQCXJxvH4UeZ4dWi0gFO2PqhRtpCYqwA@mail.gmail.com>
Message-ID: <CAFdSV9tei=spvHEStY6dgwpJbAmqTZ-wCqCaRR8_qcPTu-Nwyg@mail.gmail.com>

Well I should also clarify that currently we are not using Jandex.  That
was all work done as part of the mapping/metamodel redesign which we
decided to push to 6.0.

On Wed, Mar 18, 2015 at 10:22 AM, Steve Ebersole <steve at hibernate.org>
wrote:

> I don't *think* we do, but it sounds like something we definitely need to
> make sure we aren't doing.
> On Mar 17, 2015 8:41 AM, "Scott Marlow" <smarlow at redhat.com> wrote:
>
>> Steve,
>>
>> Wildfly-dev [1] brings up a change expected for WildFly 10, to not
>> reference the Jandex indexes after deployment completes.  I'm curious if
>> our current/planned ORM 5.0 jandex using code, keeps a reference to the
>> passed in "hibernate.jandex_index"?
>>
>> How how hard would it be for ORM, to only reference the composite Jandex
>> index during application deployment time?  Deployment time ends when
>> PersistenceProvider.createContainerEntityManagerFactory() returns.
>>
>> Scott
>>
>> [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-March/003679.html
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Wed Mar 18 13:06:12 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Mar 2015 12:06:12 -0500
Subject: [hibernate-dev] org.hibernate.AnnotationException: No
 identifier specified for entity
In-Reply-To: <1426545074.14038.6.camel@sfikes.localdomain>
References: <1426545074.14038.6.camel@sfikes.localdomain>
Message-ID: <CAFdSV9uZOaiuy8D5Tzq63rtZ4Zm1wodpfP1+DTJRykdMWsZK0g@mail.gmail.com>

That sounds reasonable to me.  Create a JIRA if you please.

On Mon, Mar 16, 2015 at 5:31 PM, Stephen Fikes <sfikes at redhat.com> wrote:

>
> https://docs.jboss.org/hibernate/orm/4.2/manual/en-US/html_single/#persistent-classes-pojo-identifier
>
> The link above observes that the requirement to provide an identifier
> for every entity is "... still not (yet) enforced" but "... should be
> considered a deprecated feature as it will be completely required to
> provide a identifier property in an upcoming release."
>
> When using annotations, it seems to be required as far back as 3.3.2.GA.
>
> Perhaps the requirement is not enforced when using hbm.xml ... but is
> only for annotations.
>
> Should we update the document comment to clarify?
>
> Thanks!
> Stephen
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Mar 18 13:10:06 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Mar 2015 12:10:06 -0500
Subject: [hibernate-dev] ORM5 : Reusing the Configuration instance
In-Reply-To: <20150317144813.GA75073@Nineveh.lan>
References: <CAFm4XO3SOE3Z1-_O2rEcg9sttZsAU5bb=2nqEbp_Vs+HUqyQ0w@mail.gmail.com>
	<20150316205719.GB24576@Nineveh.local>
	<CAFm4XO39_7VXFopCUdozE_jHFRUWtNaE3Av8_NSLhOYH+HMr=A@mail.gmail.com>
	<20150317144813.GA75073@Nineveh.lan>
Message-ID: <CAFdSV9tA05MtW39_ctK988hw1A=X93EVj=R-0PvSf=u0oK+YEA@mail.gmail.com>

Probably we should re-initialize the service registries and builders held
within Configuration after the SF is built during
Configuration#buildSessionFactory.

Although, arguably what you are trying falls under the concept of sharing
service registries, and from that perspective is better handled through not
auto-closing them.

On Tue, Mar 17, 2015 at 9:48 AM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> On Mon, Mar 16, 2015 at 09:21:33PM +0000, Sanne Grinovero wrote:
> > > given that the SessionFactory gets closed after each test, I think it
> would
> > > only be fair to also rebuild the Configuration on each test set-up.
> > > What is the reason for keeping it around anyways? Do the tests run
> > > considerably slower when re-building the Configuration for each test?
> >
> > I'm not sure, git is pointing to your name :-) See:
> > org.hibernate.search.test.TestResourceManager
>
> Sure, I remember changing and refactoring the test base class quite often.
> However, the re-use of the Configuration is something which has been in
> the code
> as long as I remember.
>
> > It probably grew a bit of complexity over time and while I'm not sure
> > of what the original intention could be, I tend to agree with the
> > basic idea
>
> That the Configuration should be re-usable?
>
> > Even if we probably won't win much in terms of performance /
> > practicality and we were to agree to simplify this, the following
> > message is confusing:
> >
> > java.util.ServiceConfigurationError:
> > org.hibernate.service.spi.ServiceContributor: Provider
> > org.hibernate.search.hcore.impl.SearchFactoryServiceContributor not
> > found
> >      at java.util.ServiceLoader.fail(ServiceLoader.java:231)
> >      at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
> >      at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:365)
> >      at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
> >      at
> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:339)
> >      at
> org.hibernate.boot.registry.StandardServiceRegistryBuilder.applyServiceContributors(StandardServiceRegistryBuilder.java:319)
> >      at
> org.hibernate.boot.registry.StandardServiceRegistryBuilder.build(StandardServiceRegistryBuilder.java:296)
> >      at
> org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:740)
>
> +1
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Wed Mar 18 13:44:18 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 18 Mar 2015 13:44:18 -0400
Subject: [hibernate-dev] Question about Jandex composite indexes passed
 into via "hibernate.jandex_index" and whether ORM keeps a strong reference
 to Jandex indexes after deployment...
In-Reply-To: <CAFdSV9tei=spvHEStY6dgwpJbAmqTZ-wCqCaRR8_qcPTu-Nwyg@mail.gmail.com>
References: <55082EE4.7080305@redhat.com>	<CAFdSV9s5ydYUqzQzw7oQCXJxvH4UeZ4dWi0gFO2PqhRtpCYqwA@mail.gmail.com>
	<CAFdSV9tei=spvHEStY6dgwpJbAmqTZ-wCqCaRR8_qcPTu-Nwyg@mail.gmail.com>
Message-ID: <5509B972.9020701@redhat.com>

On 03/18/2015 01:05 PM, Steve Ebersole wrote:
> Well I should also clarify that currently we are not using Jandex.  That
> was all work done as part of the mapping/metamodel redesign which we
> decided to push to 6.0.

I assume you mean the master (5.0) code base doesn't use Jandex but it 
looks like [2] in 4.3, is building/using the Jandex index.

How big of a change would it be to use Jandex (via 
"hibernate.jandex_index") in ORM 4.3/5.0 mapping?  Would be nice to have 
a comparison of how long it takes to deploy a large application with and 
without Jandex.

Scott

[2] 
https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/boot/internal/EntityManagerFactoryBuilderImpl.java

>
> On Wed, Mar 18, 2015 at 10:22 AM, Steve Ebersole <steve at hibernate.org
> <mailto:steve at hibernate.org>> wrote:
>
>     I don't *think* we do, but it sounds like something we definitely
>     need to make sure we aren't doing.
>
>     On Mar 17, 2015 8:41 AM, "Scott Marlow" <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>> wrote:
>
>         Steve,
>
>         Wildfly-dev [1] brings up a change expected for WildFly 10, to not
>         reference the Jandex indexes after deployment completes.  I'm
>         curious if
>         our current/planned ORM 5.0 jandex using code, keeps a reference
>         to the
>         passed in "hibernate.jandex_index"?
>
>         How how hard would it be for ORM, to only reference the
>         composite Jandex
>         index during application deployment time?  Deployment time ends when
>         PersistenceProvider.createContainerEntityManagerFactory() returns.
>
>         Scott
>
>         [1]
>         http://lists.jboss.org/pipermail/wildfly-dev/2015-March/003679.html
>         _______________________________________________
>         hibernate-dev mailing list
>         hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Wed Mar 18 13:48:57 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Mar 2015 12:48:57 -0500
Subject: [hibernate-dev] Hibernate support for JSR-354?
In-Reply-To: <CAFm4XO1=RFvMFmZ-Y9DMUDky49cRAGH_tmY44qnV+xs0Gsm5TQ@mail.gmail.com>
References: <CAEm7nbFim=wcZXNZWFWMWf0in15DyhwaOVvwDbw2GuJnDDkyHw@mail.gmail.com>
	<CAFm4XO1=RFvMFmZ-Y9DMUDky49cRAGH_tmY44qnV+xs0Gsm5TQ@mail.gmail.com>
Message-ID: <CAFdSV9u=7gYsZavxTukRYOAQ89GZE3qnqBP8=CinqgQR4LAGvA@mail.gmail.com>

Both Date/Time (JDK8) and Money/Currency (JDK9) support are covered as
required development items for 5.0.

On Wed, Mar 18, 2015 at 8:47 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hi Elliot,
> I'm not the best person to answer your more technical questions, but
> since those who are are currently on holidays I'd just like to answer
> you already and confirm it's an interesting topic.
>
> We had a similar discussion around Date/Time types in Java8: they also
> aren't supported yet out of the box, but we'd really like to add
> those, as JSR-354 when it will be included.
> The main problem is to split support for these into JDK8, and JDK9
> specific modules, and get the build scripts patched to deal with
> different requirements of language levels. I hope we'll do that soon,
> at that point it would be awesome to include your custom types,
> assuming you want to contribute.
>
> This project seems to have types for both Time and Money types:
>  http://jadira.sourceforge.net/usertype-userguide.html
>
> I have no experience with it, I just found it by following a link from
> the Joda Time project, which is known to have created good extensions
> in the past - although I think it was best known for Time types only.
> Could be nice to join forces with Jadira or at least study their
> proposal?
>
> Thanks,
> Sanne
>
>
> On 16 March 2015 at 22:59, Elliot Huntington
> <elliot.huntington at gmail.com> wrote:
> > Hi,
> >
> > It looks like JSR-354 is progressing nicely and might be included in Java
> > 9. It also looks like the SpringFramework is actively working on
> including
> > binding and formatting support for this JSR (
> > https://jira.spring.io/browse/SPR-12209). Has there been any discussion
> for
> > Hibernate to support an out of the box UserType to support persisting a
> > MonetaryAmount?
> >
> > I am in the process of writing my own solution but this is the first
> > UserType I've created and I hope someone here can help me with it. I
> posted
> > a question on StackOverflow (
> >
> http://stackoverflow.com/questions/29084830/multi-column-usertype-comparable-operations-not-working
> )
> > about how to customize the sql query that is generated by hibernate for a
> > custom multi-column UserType. I'm hoping someone reading this mailing
> list
> > will be able to provide a helpful answer.
> >
> > Thank you,
> > Elliot Huntington
> > _______________________________________________
> > 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
>

From steve at hibernate.org  Wed Mar 18 13:49:34 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Mar 2015 12:49:34 -0500
Subject: [hibernate-dev] Question about Jandex composite indexes passed
 into via "hibernate.jandex_index" and whether ORM keeps a strong reference
 to Jandex indexes after deployment...
In-Reply-To: <5509B972.9020701@redhat.com>
References: <55082EE4.7080305@redhat.com>
	<CAFdSV9s5ydYUqzQzw7oQCXJxvH4UeZ4dWi0gFO2PqhRtpCYqwA@mail.gmail.com>
	<CAFdSV9tei=spvHEStY6dgwpJbAmqTZ-wCqCaRR8_qcPTu-Nwyg@mail.gmail.com>
	<5509B972.9020701@redhat.com>
Message-ID: <CAFdSV9txzbRSE7cgNWnapzY_pvM17FesZm8PdPeqivR=5DoE9A@mail.gmail.com>

Massive.

On Wed, Mar 18, 2015 at 12:44 PM, Scott Marlow <smarlow at redhat.com> wrote:

> On 03/18/2015 01:05 PM, Steve Ebersole wrote:
>
>> Well I should also clarify that currently we are not using Jandex.  That
>> was all work done as part of the mapping/metamodel redesign which we
>> decided to push to 6.0.
>>
>
> I assume you mean the master (5.0) code base doesn't use Jandex but it
> looks like [2] in 4.3, is building/using the Jandex index.
>
> How big of a change would it be to use Jandex (via
> "hibernate.jandex_index") in ORM 4.3/5.0 mapping?  Would be nice to have a
> comparison of how long it takes to deploy a large application with and
> without Jandex.
>
> Scott
>
> [2] https://github.com/hibernate/hibernate-orm/blob/4.3/
> hibernate-entitymanager/src/main/java/org/hibernate/jpa/boot/internal/
> EntityManagerFactoryBuilderImpl.java
>
>
>> On Wed, Mar 18, 2015 at 10:22 AM, Steve Ebersole <steve at hibernate.org
>> <mailto:steve at hibernate.org>> wrote:
>>
>>     I don't *think* we do, but it sounds like something we definitely
>>     need to make sure we aren't doing.
>>
>>     On Mar 17, 2015 8:41 AM, "Scott Marlow" <smarlow at redhat.com
>>     <mailto:smarlow at redhat.com>> wrote:
>>
>>         Steve,
>>
>>         Wildfly-dev [1] brings up a change expected for WildFly 10, to not
>>         reference the Jandex indexes after deployment completes.  I'm
>>         curious if
>>         our current/planned ORM 5.0 jandex using code, keeps a reference
>>         to the
>>         passed in "hibernate.jandex_index"?
>>
>>         How how hard would it be for ORM, to only reference the
>>         composite Jandex
>>         index during application deployment time?  Deployment time ends
>> when
>>         PersistenceProvider.createContainerEntityManagerFactory()
>> returns.
>>
>>         Scott
>>
>>         [1]
>>         http://lists.jboss.org/pipermail/wildfly-dev/2015-
>> March/003679.html
>>         _______________________________________________
>>         hibernate-dev mailing list
>>         hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.
>> jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>>

From steve at hibernate.org  Wed Mar 18 13:53:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Mar 2015 12:53:55 -0500
Subject: [hibernate-dev] Question about Jandex composite indexes passed
 into via "hibernate.jandex_index" and whether ORM keeps a strong reference
 to Jandex indexes after deployment...
In-Reply-To: <CAFdSV9txzbRSE7cgNWnapzY_pvM17FesZm8PdPeqivR=5DoE9A@mail.gmail.com>
References: <55082EE4.7080305@redhat.com>
	<CAFdSV9s5ydYUqzQzw7oQCXJxvH4UeZ4dWi0gFO2PqhRtpCYqwA@mail.gmail.com>
	<CAFdSV9tei=spvHEStY6dgwpJbAmqTZ-wCqCaRR8_qcPTu-Nwyg@mail.gmail.com>
	<5509B972.9020701@redhat.com>
	<CAFdSV9txzbRSE7cgNWnapzY_pvM17FesZm8PdPeqivR=5DoE9A@mail.gmail.com>
Message-ID: <CAFdSV9sUUj+7kY25ijigRqUTUmDiXyy70ErOkz_CLK-75OLnZQ@mail.gmail.com>

Out of curiosity though, since you want more and more and more things
pushed to "second phase bootstrapping", I am curious how this new
expectation plays in with that.  Specifically, us "using" Jandex will
certainly include us accessing classes, unless Jason has added the expanded
capabilities he and I have discussed to Jandex wrt accessing Class members
outside of the annotations they may or may not have.

On Wed, Mar 18, 2015 at 12:49 PM, Steve Ebersole <steve at hibernate.org>
wrote:

> Massive.
>
> On Wed, Mar 18, 2015 at 12:44 PM, Scott Marlow <smarlow at redhat.com> wrote:
>
>> On 03/18/2015 01:05 PM, Steve Ebersole wrote:
>>
>>> Well I should also clarify that currently we are not using Jandex.  That
>>> was all work done as part of the mapping/metamodel redesign which we
>>> decided to push to 6.0.
>>>
>>
>> I assume you mean the master (5.0) code base doesn't use Jandex but it
>> looks like [2] in 4.3, is building/using the Jandex index.
>>
>> How big of a change would it be to use Jandex (via
>> "hibernate.jandex_index") in ORM 4.3/5.0 mapping?  Would be nice to have a
>> comparison of how long it takes to deploy a large application with and
>> without Jandex.
>>
>> Scott
>>
>> [2] https://github.com/hibernate/hibernate-orm/blob/4.3/
>> hibernate-entitymanager/src/main/java/org/hibernate/jpa/boot/internal/
>> EntityManagerFactoryBuilderImpl.java
>>
>>
>>> On Wed, Mar 18, 2015 at 10:22 AM, Steve Ebersole <steve at hibernate.org
>>> <mailto:steve at hibernate.org>> wrote:
>>>
>>>     I don't *think* we do, but it sounds like something we definitely
>>>     need to make sure we aren't doing.
>>>
>>>     On Mar 17, 2015 8:41 AM, "Scott Marlow" <smarlow at redhat.com
>>>     <mailto:smarlow at redhat.com>> wrote:
>>>
>>>         Steve,
>>>
>>>         Wildfly-dev [1] brings up a change expected for WildFly 10, to
>>> not
>>>         reference the Jandex indexes after deployment completes.  I'm
>>>         curious if
>>>         our current/planned ORM 5.0 jandex using code, keeps a reference
>>>         to the
>>>         passed in "hibernate.jandex_index"?
>>>
>>>         How how hard would it be for ORM, to only reference the
>>>         composite Jandex
>>>         index during application deployment time?  Deployment time ends
>>> when
>>>         PersistenceProvider.createContainerEntityManagerFactory()
>>> returns.
>>>
>>>         Scott
>>>
>>>         [1]
>>>         http://lists.jboss.org/pipermail/wildfly-dev/2015-
>>> March/003679.html
>>>         _______________________________________________
>>>         hibernate-dev mailing list
>>>         hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.
>>> jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>>
>

From smarlow at redhat.com  Wed Mar 18 14:56:15 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 18 Mar 2015 14:56:15 -0400
Subject: [hibernate-dev] Question about Jandex composite indexes passed
 into via "hibernate.jandex_index" and whether ORM keeps a strong reference
 to Jandex indexes after deployment...
In-Reply-To: <CAFdSV9sUUj+7kY25ijigRqUTUmDiXyy70ErOkz_CLK-75OLnZQ@mail.gmail.com>
References: <55082EE4.7080305@redhat.com>	<CAFdSV9s5ydYUqzQzw7oQCXJxvH4UeZ4dWi0gFO2PqhRtpCYqwA@mail.gmail.com>	<CAFdSV9tei=spvHEStY6dgwpJbAmqTZ-wCqCaRR8_qcPTu-Nwyg@mail.gmail.com>	<5509B972.9020701@redhat.com>	<CAFdSV9txzbRSE7cgNWnapzY_pvM17FesZm8PdPeqivR=5DoE9A@mail.gmail.com>
	<CAFdSV9sUUj+7kY25ijigRqUTUmDiXyy70ErOkz_CLK-75OLnZQ@mail.gmail.com>
Message-ID: <5509CA4F.9060401@redhat.com>


On 03/18/2015 01:53 PM, Steve Ebersole wrote:
> Out of curiosity though, since you want more and more and more things
> pushed to "second phase bootstrapping", I am curious how this new
> expectation plays in with that.  Specifically, us "using" Jandex will
> certainly include us accessing classes, unless Jason has added the
> expanded capabilities he and I have discussed to Jandex wrt accessing
> Class members outside of the annotations they may or may not have.

If we use the application classloader during the "first phase 
bootstrapping", entity class enhancement will not work (application 
classes will be loaded before they can be rewritten).  Classloading 
during the "first phase bootstrapping" with 
javax.persistence.spi.PersistenceUnitInfo.getNewTempClassLoader() would 
still work with entity class enhancement.

>
> On Wed, Mar 18, 2015 at 12:49 PM, Steve Ebersole <steve at hibernate.org
> <mailto:steve at hibernate.org>> wrote:
>
>     Massive.
>
>     On Wed, Mar 18, 2015 at 12:44 PM, Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>> wrote:
>
>         On 03/18/2015 01:05 PM, Steve Ebersole wrote:
>
>             Well I should also clarify that currently we are not using
>             Jandex.  That
>             was all work done as part of the mapping/metamodel redesign
>             which we
>             decided to push to 6.0.
>
>
>         I assume you mean the master (5.0) code base doesn't use Jandex
>         but it looks like [2] in 4.3, is building/using the Jandex index.
>
>         How big of a change would it be to use Jandex (via
>         "hibernate.jandex_index") in ORM 4.3/5.0 mapping?  Would be nice
>         to have a comparison of how long it takes to deploy a large
>         application with and without Jandex.
>
>         Scott
>
>         [2]
>         https://github.com/hibernate/__hibernate-orm/blob/4.3/__hibernate-entitymanager/src/__main/java/org/hibernate/jpa/__boot/internal/__EntityManagerFactoryBuilderImp__l.java
>         <https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/boot/internal/EntityManagerFactoryBuilderImpl.java>
>
>
>             On Wed, Mar 18, 2015 at 10:22 AM, Steve Ebersole
>             <steve at hibernate.org <mailto:steve at hibernate.org>
>             <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>>
>             wrote:
>
>                  I don't *think* we do, but it sounds like something we
>             definitely
>                  need to make sure we aren't doing.
>
>                  On Mar 17, 2015 8:41 AM, "Scott Marlow"
>             <smarlow at redhat.com <mailto:smarlow at redhat.com>
>                  <mailto:smarlow at redhat.com
>             <mailto:smarlow at redhat.com>>> wrote:
>
>                      Steve,
>
>                      Wildfly-dev [1] brings up a change expected for
>             WildFly 10, to not
>                      reference the Jandex indexes after deployment
>             completes.  I'm
>                      curious if
>                      our current/planned ORM 5.0 jandex using code,
>             keeps a reference
>                      to the
>                      passed in "hibernate.jandex_index"?
>
>                      How how hard would it be for ORM, to only reference the
>                      composite Jandex
>                      index during application deployment time?
>             Deployment time ends when
>
>             PersistenceProvider.__createContainerEntityManagerFa__ctory() returns.
>
>                      Scott
>
>                      [1]
>             http://lists.jboss.org/__pipermail/wildfly-dev/2015-__March/003679.html
>             <http://lists.jboss.org/pipermail/wildfly-dev/2015-March/003679.html>
>                      _________________________________________________
>                      hibernate-dev mailing list
>             hibernate-dev at lists.jboss.org
>             <mailto:hibernate-dev at lists.jboss.org>
>             <mailto:hibernate-dev at lists.__jboss.org
>             <mailto:hibernate-dev at lists.jboss.org>>
>             https://lists.jboss.org/__mailman/listinfo/hibernate-dev
>             <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>
>
>

From smarlow at redhat.com  Wed Mar 18 15:24:02 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 18 Mar 2015 15:24:02 -0400
Subject: [hibernate-dev] Question about Jandex composite indexes passed
 into via "hibernate.jandex_index" and whether ORM keeps a strong reference
 to Jandex indexes after deployment...
In-Reply-To: <5509CA4F.9060401@redhat.com>
References: <55082EE4.7080305@redhat.com>	<CAFdSV9s5ydYUqzQzw7oQCXJxvH4UeZ4dWi0gFO2PqhRtpCYqwA@mail.gmail.com>	<CAFdSV9tei=spvHEStY6dgwpJbAmqTZ-wCqCaRR8_qcPTu-Nwyg@mail.gmail.com>	<5509B972.9020701@redhat.com>	<CAFdSV9txzbRSE7cgNWnapzY_pvM17FesZm8PdPeqivR=5DoE9A@mail.gmail.com>	<CAFdSV9sUUj+7kY25ijigRqUTUmDiXyy70ErOkz_CLK-75OLnZQ@mail.gmail.com>
	<5509CA4F.9060401@redhat.com>
Message-ID: <5509D0D2.2030503@redhat.com>



On 03/18/2015 02:56 PM, Scott Marlow wrote:
>
> On 03/18/2015 01:53 PM, Steve Ebersole wrote:
>> Out of curiosity though, since you want more and more and more things
>> pushed to "second phase bootstrapping", I am curious how this new
>> expectation plays in with that.  Specifically, us "using" Jandex will
>> certainly include us accessing classes, unless Jason has added the
>> expanded capabilities he and I have discussed to Jandex wrt accessing
>> Class members outside of the annotations they may or may not have.
>
> If we use the application classloader during the "first phase
> bootstrapping", entity class enhancement will not work (application
> classes will be loaded before they can be rewritten).  Classloading
> during the "first phase bootstrapping" with
> javax.persistence.spi.PersistenceUnitInfo.getNewTempClassLoader() would
> still work with entity class enhancement.

Jipijapa for ORM 4.1 is currently using the 
PersistenceUnitInfo.getNewTempClassLoader() [3] and that works well. 
Jason asked why we dropped using Jandex in our integration with ORM 4.3. 
  The 4.3 integration in Jipijapa is more elegant/better except it might 
not be as fast as using Jandex with 
org.hibernate.boot.archive.scan.spi.Scanner.

Should we look at switching Jipijapa back to 
org.hibernate.boot.archive.scan.spi.Scanner (so we can use Jandex) and 
remove Jandex from 4.3.x?

In the Jipijapa integration for ORM 5.0, should we use 
org.hibernate.boot.archive.scan.spi.Scanner so that we are using jandex?

[3] 
https://github.com/jipijapa/jipijapa/blob/master/hibernate4_1/src/main/java/org/jboss/as/jpa/hibernate4/HibernateAnnotationScanner.java#L167

>
>>
>> On Wed, Mar 18, 2015 at 12:49 PM, Steve Ebersole <steve at hibernate.org
>> <mailto:steve at hibernate.org>> wrote:
>>
>>      Massive.
>>
>>      On Wed, Mar 18, 2015 at 12:44 PM, Scott Marlow <smarlow at redhat.com
>>      <mailto:smarlow at redhat.com>> wrote:
>>
>>          On 03/18/2015 01:05 PM, Steve Ebersole wrote:
>>
>>              Well I should also clarify that currently we are not using
>>              Jandex.  That
>>              was all work done as part of the mapping/metamodel redesign
>>              which we
>>              decided to push to 6.0.
>>
>>
>>          I assume you mean the master (5.0) code base doesn't use Jandex
>>          but it looks like [2] in 4.3, is building/using the Jandex index.
>>
>>          How big of a change would it be to use Jandex (via
>>          "hibernate.jandex_index") in ORM 4.3/5.0 mapping?  Would be nice
>>          to have a comparison of how long it takes to deploy a large
>>          application with and without Jandex.
>>
>>          Scott
>>
>>          [2]
>>          https://github.com/hibernate/__hibernate-orm/blob/4.3/__hibernate-entitymanager/src/__main/java/org/hibernate/jpa/__boot/internal/__EntityManagerFactoryBuilderImp__l.java
>>          <https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/boot/internal/EntityManagerFactoryBuilderImpl.java>
>>
>>
>>              On Wed, Mar 18, 2015 at 10:22 AM, Steve Ebersole
>>              <steve at hibernate.org <mailto:steve at hibernate.org>
>>              <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>>
>>              wrote:
>>
>>                   I don't *think* we do, but it sounds like something we
>>              definitely
>>                   need to make sure we aren't doing.
>>
>>                   On Mar 17, 2015 8:41 AM, "Scott Marlow"
>>              <smarlow at redhat.com <mailto:smarlow at redhat.com>
>>                   <mailto:smarlow at redhat.com
>>              <mailto:smarlow at redhat.com>>> wrote:
>>
>>                       Steve,
>>
>>                       Wildfly-dev [1] brings up a change expected for
>>              WildFly 10, to not
>>                       reference the Jandex indexes after deployment
>>              completes.  I'm
>>                       curious if
>>                       our current/planned ORM 5.0 jandex using code,
>>              keeps a reference
>>                       to the
>>                       passed in "hibernate.jandex_index"?
>>
>>                       How how hard would it be for ORM, to only reference the
>>                       composite Jandex
>>                       index during application deployment time?
>>              Deployment time ends when
>>
>>              PersistenceProvider.__createContainerEntityManagerFa__ctory() returns.
>>
>>                       Scott
>>
>>                       [1]
>>              http://lists.jboss.org/__pipermail/wildfly-dev/2015-__March/003679.html
>>              <http://lists.jboss.org/pipermail/wildfly-dev/2015-March/003679.html>
>>                       _________________________________________________
>>                       hibernate-dev mailing list
>>              hibernate-dev at lists.jboss.org
>>              <mailto:hibernate-dev at lists.jboss.org>
>>              <mailto:hibernate-dev at lists.__jboss.org
>>              <mailto:hibernate-dev at lists.jboss.org>>
>>              https://lists.jboss.org/__mailman/listinfo/hibernate-dev
>>              <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
>

From emmanuel at hibernate.org  Thu Mar 19 04:35:39 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 19 Mar 2015 09:35:39 +0100
Subject: [hibernate-dev] Sharing an association table between two
	associations
In-Reply-To: <CAFdSV9t507tVCWe_M6DdrjedkE7q621xZos9XdnJrBdfGkn=TQ@mail.gmail.com>
References: <20150318152713.GA32713@hibernate.org>
	<CAFdSV9t507tVCWe_M6DdrjedkE7q621xZos9XdnJrBdfGkn=TQ@mail.gmail.com>
Message-ID: <21CF2D27-E440-4EC4-A8AE-AD6B526F3D55@hibernate.org>

Oops, Adding the mailing list.
Thanks for the input, we went for two explicit table names in the OGM test. Looks like we are aligned. 

Emmanuel


> On 18 mars 2015, at 18:59, Steve Ebersole <steve at hibernate.org> wrote:
> 
> Well considering I am the only recipient... ;)
> 
> I have actually seen this scenario in one of your annotation test cases.  Currently, the outcome is actually highly dependent upon the naming strategy used.  In my opinion, this should be an invalid mapping.  The spec may or may not back me up there, but to me it just "feels" wrong.  
> 
> 
> 
>> On Wed, Mar 18, 2015 at 10:27 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> Hi Steve and all,
>> 
>> There is a borderline case that Hibenate OGM trips on. I would like to
>> know whether you consider this case valid enough or if we can safely
>> ignore it.
>> 
>> @Entity
>> public class SnowFlake {
>>     @Id
>>     private String id;
>>     private String description;
>> }
>> 
>> @Entity
>> public class Cloud {
>>     @Id
>>     private String id;
>>     private String type;
>>     private double length;
>>     @OneToMany
>>     @JoinTable
>>     private Set<SnowFlake> producedSnowFlakes = new HashSet<SnowFlake>();
>>     @OneToMany
>>     @JoinTable
>>     private Set<SnowFlake> backupSnowFlakes = new HashSet<SnowFlake>();
>> }
>> 
>> Here, producedSnowFlakes and backupSnowFlakes have the set semantic, so a PK is
>> created for the association tables.  Except that we use the same association
>> table name Cloud_SnowFlake) for both. The PK offered in Hibernate ORM metadata
>> ends up being wrong.
>> The runtime code works as the target fk columns are named differently.
>> 
>> I have always considered it wrong to share the same table for two associations.
>> Are you with me, or should we try to amke the ORM physical model smarter to
>> relax the PK generation when an association table is shared?
>> 
>> Emmanuel
> 

From steve at hibernate.org  Thu Mar 19 12:26:27 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 19 Mar 2015 11:26:27 -0500
Subject: [hibernate-dev] Sharing an association table between two
	associations
In-Reply-To: <21CF2D27-E440-4EC4-A8AE-AD6B526F3D55@hibernate.org>
References: <20150318152713.GA32713@hibernate.org>
	<CAFdSV9t507tVCWe_M6DdrjedkE7q621xZos9XdnJrBdfGkn=TQ@mail.gmail.com>
	<21CF2D27-E440-4EC4-A8AE-AD6B526F3D55@hibernate.org>
Message-ID: <CAFdSV9vyGTKykF7Xu-V9wgem+WQUyP4u1t2nL8nUs49d_U42Nw@mail.gmail.com>

The difficulty is recognizing this as an exception condition, which I'd
really prefer to do.  But I just don't see a way to accomplish that without
tables keeping a "nature" indicating how they are used.

On Thu, Mar 19, 2015 at 3:35 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Oops, Adding the mailing list.
> Thanks for the input, we went for two explicit table names in the OGM
> test. Looks like we are aligned.
>
> Emmanuel
>
>
> On 18 mars 2015, at 18:59, Steve Ebersole <steve at hibernate.org> wrote:
>
> Well considering I am the only recipient... ;)
>
> I have actually seen this scenario in one of your annotation test cases.
> Currently, the outcome is actually highly dependent upon the naming
> strategy used.  In my opinion, this should be an invalid mapping.  The spec
> may or may not back me up there, but to me it just "feels" wrong.
>
>
>
> On Wed, Mar 18, 2015 at 10:27 AM, Emmanuel Bernard <emmanuel at hibernate.org
> > wrote:
>
>> Hi Steve and all,
>>
>> There is a borderline case that Hibenate OGM trips on. I would like to
>> know whether you consider this case valid enough or if we can safely
>> ignore it.
>>
>> @Entity
>> public class SnowFlake {
>>     @Id
>>     private String id;
>>     private String description;
>> }
>>
>> @Entity
>> public class Cloud {
>>     @Id
>>     private String id;
>>     private String type;
>>     private double length;
>>     @OneToMany
>>     @JoinTable
>>     private Set<SnowFlake> producedSnowFlakes = new HashSet<SnowFlake>();
>>     @OneToMany
>>     @JoinTable
>>     private Set<SnowFlake> backupSnowFlakes = new HashSet<SnowFlake>();
>> }
>>
>> Here, producedSnowFlakes and backupSnowFlakes have the set semantic, so a
>> PK is
>> created for the association tables.  Except that we use the same
>> association
>> table name Cloud_SnowFlake) for both. The PK offered in Hibernate ORM
>> metadata
>> ends up being wrong.
>> The runtime code works as the target fk columns are named differently.
>>
>> I have always considered it wrong to share the same table for two
>> associations.
>> Are you with me, or should we try to amke the ORM physical model smarter
>> to
>> relax the PK generation when an association table is shared?
>>
>> Emmanuel
>>
>
>

From sanne at hibernate.org  Thu Mar 19 15:47:42 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 19 Mar 2015 19:47:42 +0000
Subject: [hibernate-dev] Hibernate Search 5.1.1.Final
Message-ID: <CAFm4XO2CZBym97dDefV09BP_jLCPEXFbKr=-=9pWj8Y-L0Ubmg@mail.gmail.com>

Hello all,
Hibernate Search 5.1.1.Final is now released and available in Maven Central.

http://in.relation.to/Bloggers/ACommunityImprovedVersionOfHibernateSearch511Final

Best Regards,
Sanne

From sanne at hibernate.org  Thu Mar 19 21:13:58 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 20 Mar 2015 01:13:58 +0000
Subject: [hibernate-dev] Usage of the Service pattern in Hibernate Search
Message-ID: <CAFm4XO3R4PBt_r44e_j27WJGTsnjHaum4cER36T72vzV9gW+9Q@mail.gmail.com>

Looks like the ServiceRegistry pattern is getting quite popular in
Hibernate Search.

There are three default implementations (of three services) which are
provided by the hibernate-search-engine itself.
Essentially the hibernate-search-engine code looks it up, and loads
from its very same jar; I'm finding this a bit weird.

Wouldn't it make more sense to actually look up for the service only
for alternative (non-default) implementations?

We don't have a strategy to pick one implementation if there are
multiple implementations around (other than throwing an exception), so
having a service defined in the engine jar, essentially means noone
can plug an alternative, unless he overrides the
SearchConfiguration#getProvidedServices() method.

So if the intention was to allow choice, something is missing. If not,
I'd rather load the default implementations explicitly (via their
traditional constructor).

From steve at hibernate.org  Sat Mar 21 11:55:58 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 21 Mar 2015 10:55:58 -0500
Subject: [hibernate-dev] Usage of the Service pattern in Hibernate Search
In-Reply-To: <CAFm4XO3R4PBt_r44e_j27WJGTsnjHaum4cER36T72vzV9gW+9Q@mail.gmail.com>
References: <CAFm4XO3R4PBt_r44e_j27WJGTsnjHaum4cER36T72vzV9gW+9Q@mail.gmail.com>
Message-ID: <CAFdSV9v0RX7iX-2QRSdn8hOqgVkwmcTPsTxayFHkLCg2STY1sA@mail.gmail.com>

For me its a matter of consistency.  Put simply a Service comes from a
ServiceRegistry.  That's consistent.  This idea that some particular
Service might come from here or there or this other place is not
consistent.  To me.

Now, I understand that there is likely a performance impact to this (Map
lookup) which I assume is likely more the driver of this question.  But I
prefer the consistency/readability when the performance is
equal/negligible.  However, were the performance impact big, obviously that
changes things.

That's my take and my means of weighing this for ORM.

On Thu, Mar 19, 2015 at 8:13 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Looks like the ServiceRegistry pattern is getting quite popular in
> Hibernate Search.
>
> There are three default implementations (of three services) which are
> provided by the hibernate-search-engine itself.
> Essentially the hibernate-search-engine code looks it up, and loads
> from its very same jar; I'm finding this a bit weird.
>
> Wouldn't it make more sense to actually look up for the service only
> for alternative (non-default) implementations?
>
> We don't have a strategy to pick one implementation if there are
> multiple implementations around (other than throwing an exception), so
> having a service defined in the engine jar, essentially means noone
> can plug an alternative, unless he overrides the
> SearchConfiguration#getProvidedServices() method.
>
> So if the intention was to allow choice, something is missing. If not,
> I'd rather load the default implementations explicitly (via their
> traditional constructor).
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Sat Mar 21 14:09:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 21 Mar 2015 13:09:41 -0500
Subject: [hibernate-dev] SessionFactory building APIs
Message-ID: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>

I had not heard anything back in regards to this, so I wanted to ask one
more time before I get ready to start cutting 5.0 pre-releases in a week or
2.

I'd love to heard feedback of any kind about the new APIs, but specific
things I know I personally question:

1) What do you think of the split in MetadataSources and MetadataBuilder?
Does the aplit make sense?  Or does it make more sense to combine them into
one contract?

2) What do you think of all the overloaded methods named #with tacking
different argument types, versus distinctly named methods?  E.g.
MetadataBuilder#with(ImplicitNamingStrategy),
MetadataBuilder#with(PhysicalNamingStrategy), etc rather than
MetadataBuilder#withImplicitNamingStrategy(ImplicitNamingStrategy),
MetadataBuilder#withPhysicalNamingStrategy(PhysicalNamingStrategy)

Also, I am not so sure about the term "with" anymore.  I had chosen that at
the time because I thought it flowed nicely with method chaining.

From steve at hibernate.org  Sat Mar 21 17:08:51 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 21 Mar 2015 16:08:51 -0500
Subject: [hibernate-dev] ORM Team "triage" meeting
Message-ID: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>

Gail and I discussed Jira a little bit last week and how to best manage
scheduling issues.

We both agreed that a team get together, either weekly or every-other-week,
to discuss new issues to triage them would be a great idea.

One thing I absolutely do not want happening is just scheduling issues as a
means to come back and triage them later.  Scheduling an issue, on a "real
version" anyway, should mean something.  It should mean some level of
dedication to finish that task for that release.  In short, unless you are
volunteering to take on a task *yourself* for that release, please do not
schedule it for that release.

As for the triage meeting, I would definitely like Gail and Andrea
involved.  Of course anyone is welcome.  The reason I mention this is that
Gail is usually left on early side of scheduling these.  So we will find a
time that works best for us 3 and go from there.  I recommend that we
leverage HipChat for these discussion.

Andrea is coming to Austin for a few days starting Monday, so I would like
to start this triaging while he is here.  Gail, I am thinking 1pm my time
(11am yours) would be a good time.  Andrea, does that work for you after
Austin?

From steve at hibernate.org  Sat Mar 21 20:15:47 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 21 Mar 2015 19:15:47 -0500
Subject: [hibernate-dev] CI Server
Message-ID: <CAFdSV9uXLrDGLmhZpGfqAZCnjO=Mxqse1UKwsNmKvLqUVcsjHA@mail.gmail.com>

I just finished work on HHH-8697 and HHH-9320 and pushed that work to
master and 4.3.  After my push, the CI jobs for each started failing in a
way I could not reproduce locally.  But I did eventually divine what was
going on.  The failure is actually indicative of problem elsewhere.  And it
may or may not be a problem outside of our test suite.  The issue is with
fact that we register org.hibernate.type.descriptor.sql.SqlTypeDescriptor
instances with
a org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry that is
unfortunately for now defined statically via a static INSTANCE variable.
Our SqlTypeDescriptor implementations register themselves with the registry
on creation.

<backstory>
This is all code I added for implementing AttributeConverter support.  When
we see an AttributeConverter we use the defined "database type" to perform
a resolution from the defined type to the recommended JDBC style code for
that type, and we then ask the SqlTypeDescriptorRegistry for the
SqlTypeDescriptor corresponding to that JDBC type code.
</backstory>

There is a test that subclasses our internal VarcharTypeDescriptor.
VarcharTypeDescriptor, like all the SqlTypeDescriptor impls, registers
itself with the SqlTypeDescriptorRegistry during its instantiation.  The
"issue" here is that this subclass also registers itself into the
SqlTypeDescriptorRegistry during its instantiation via the call to the
super ctor.  And because the SqlTypeDescriptorRegistry is static, this
causes the "bleeding".

How to fix this?  There are a few options.  Ideally
SqlTypeDescriptorRegistry would not be static and we could just move on.
However that is not possible given the current design of Types.  Now this
does feed into some changes I wanted to make as we move forward in the Type
system.  As I was developing our AttributeConverter support I thought it
would be really awesome if a Type (a BasicType anyway) was just a dynamic
combining of a SqlTypeDescriptor and a JavaTypeDescriptor (unless a
specific Type was named).  Take a counter-example.  Today we have multiple
Type impls to deal with storing a UUID (UUIDCharType, UUIDBinaryType,
PostgresUUIDType).  But literally these are all just 3 different combinings
of SqlTypeDescriptor and JavaTypeDescriptor:
* UUIDCharType is a combo of UUIDTypeDescriptor and VarcharTypeDescriptor
* UUIDBinaryType is a combo of UUIDTypeDescriptor and BinaryTypeDescriptor
* PostgresUUIDType is a combo of UUIDTypeDescriptor and a specialed
pgsql-specific SqlTypeDescriptor for its UUID dtype.

The idea is similar to what I stated above in the backstory when
determining an implicit type.  Today we use the java attribute type to do a
look up into the based on registration keys *for the Type*.  Instead in
this future model we would use the java attribute type to determine the
recommended JDBC type code (String->Types.VARCHAR, etc) and then use that
JDBC type code to determine the SqlTypeDescriptor to use.  Then combine
that with the JavaTypeDescriptor for the java attribute type.  This
approach has a lot of potential benefits including the ability to
leverage java.sql.DatabaseMetaData#getTypeInfo.  The benefits aside, this
is a big change, so I am not sure it is best to take that on for 5.0.

The other solution I can think of for now is basically to limit what gets
added to the SqlTypeDescriptorRegistry so that it is just Hibernate defined
SqlTypeDescriptors.

Hopefully I explained that well enough.  Anyway... thoughts?

From steve at hibernate.org  Sat Mar 21 20:38:03 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 21 Mar 2015 19:38:03 -0500
Subject: [hibernate-dev] JSR 354 - Money and Currency
Message-ID: <CAFdSV9vh5XCCpPNOd41RWKoXP9H9y1u_aUTa+aYtvZyycORjpw@mail.gmail.com>

So it sounds like JSR 354 may not be included in Java 9.  Do we still want
to support this for ORM 5?  I am not sure if "moneta" requires Java 9...

From adamstawicki91 at gmail.com  Sun Mar 22 04:28:48 2015
From: adamstawicki91 at gmail.com (Adam Stawicki)
Date: Sun, 22 Mar 2015 09:28:48 +0100
Subject: [hibernate-dev] GSOC15 OGM
Message-ID: <CAO9N6GoJov7Ss5+C6ygSrgh7J3TSpW-iBTaqfdaia0_iARwChg@mail.gmail.com>

Do we still have enough time to suggest an additional idea?
I think about picking, interesting form me, already existing JIRA issues
like: [1] [2] [3] [4].

What do you think?


[1] https://hibernate.atlassian.net/browse/OGM-728
[2] https://hibernate.atlassian.net/browse/OGM-768
[3] https://hibernate.atlassian.net/browse/OGM-785
[4] https://hibernate.atlassian.net/browse/OGM-786

From dreborier at gmail.com  Sun Mar 22 15:45:01 2015
From: dreborier at gmail.com (andrea boriero)
Date: Sun, 22 Mar 2015 19:45:01 +0000
Subject: [hibernate-dev] ORM Team "triage" meeting
In-Reply-To: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
References: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
Message-ID: <CAL00eSSffdM6dzSecLvObx9KZttDbpoxMUL09fEXzQ7KL=cWLA@mail.gmail.com>

for me at the moment it would be 6pm and it should be good.

On 21 March 2015 at 21:08, Steve Ebersole <steve at hibernate.org> wrote:

> Gail and I discussed Jira a little bit last week and how to best manage
> scheduling issues.
>
> We both agreed that a team get together, either weekly or every-other-week,
> to discuss new issues to triage them would be a great idea.
>
> One thing I absolutely do not want happening is just scheduling issues as a
> means to come back and triage them later.  Scheduling an issue, on a "real
> version" anyway, should mean something.  It should mean some level of
> dedication to finish that task for that release.  In short, unless you are
> volunteering to take on a task *yourself* for that release, please do not
> schedule it for that release.
>
> As for the triage meeting, I would definitely like Gail and Andrea
> involved.  Of course anyone is welcome.  The reason I mention this is that
> Gail is usually left on early side of scheduling these.  So we will find a
> time that works best for us 3 and go from there.  I recommend that we
> leverage HipChat for these discussion.
>
> Andrea is coming to Austin for a few days starting Monday, so I would like
> to start this triaging while he is here.  Gail, I am thinking 1pm my time
> (11am yours) would be a good time.  Andrea, does that work for you after
> Austin?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Sun Mar 22 22:54:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 22 Mar 2015 21:54:55 -0500
Subject: [hibernate-dev] Date/Time Support and timezones
Message-ID: <CAFdSV9sbcwkyRJ7oNN8PX=LFUyhrOZVdn7UDoH7ATENRk6h0sQ@mail.gmail.com>

As I start work on supporting Java 8 Date/Time types, I wanted to get
everyone's opinion on handling OffsetDateTime, OffsetTime and ZonedDateTime
with regards to timezone.  Each represent a date/time in a particular
timezone/offset (much like a Calendar).  A few options:

1) Forego OffsetDateTime, OffsetTime and ZonedDateTime support and just
stick with LocalDateTime, LocalDate and LocalTime.
2) Use the timezone/offset to pass along to the driver (for proper
conversion); when reading back we'd have to read back based on the default
timezone.  This is essentially the old strategy used in CalendarType which
I never really liked because its not reflexive.
3) Break them into a tuple of the store each piece.  E.g., for
OffsetDateTime the Tuple is a LocalDateTime (the Timestamp) and a TZ
offset.  So we'd store each individually in the database and be able to
rebuild them in a fully reflexive manner.
4) Handle them using UTC or GMT at the JDBC level.  This is essentially the
same as (2)

From steve at hibernate.org  Sun Mar 22 23:11:32 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 22 Mar 2015 22:11:32 -0500
Subject: [hibernate-dev] Gradle build and multiple JDKs
Message-ID: <CAFdSV9sVATfxkzwUELmhj7pEUhrpkk+7=LKXQ=0u9t=jiOivcQ@mail.gmail.com>

Ran across an interesting proof-of-concept project for setting up a Gradle
build to use multiple JDKs: https://github.com/rwinch/gradle-multi-jdk

Curious what y'all think of this approach versus what we do know with
AnimalSniffer...

From hardy at hibernate.org  Mon Mar 23 05:33:19 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 23 Mar 2015 10:33:19 +0100
Subject: [hibernate-dev] Usage of the Service pattern in Hibernate Search
In-Reply-To: <CAFdSV9v0RX7iX-2QRSdn8hOqgVkwmcTPsTxayFHkLCg2STY1sA@mail.gmail.com>
References: <CAFm4XO3R4PBt_r44e_j27WJGTsnjHaum4cER36T72vzV9gW+9Q@mail.gmail.com>
	<CAFdSV9v0RX7iX-2QRSdn8hOqgVkwmcTPsTxayFHkLCg2STY1sA@mail.gmail.com>
Message-ID: <20150323093319.GA82757@Nineveh.local>

Hi,

On Sat, Mar 21, 2015 at 10:55:58AM -0500, Steve Ebersole wrote:
> For me its a matter of consistency.  Put simply a Service comes from a
> ServiceRegistry.  That's consistent.  This idea that some particular
> Service might come from here or there or this other place is not
> consistent.  To me.

+1 This is the exactly the point I tried to make earlier as well.

> > We don't have a strategy to pick one implementation if there are
> > multiple implementations around (other than throwing an exception), so
> > having a service defined in the engine jar, essentially means noone
> > can plug an alternative, unless he overrides the
> > SearchConfiguration#getProvidedServices() method.

If we have a need for a selection strategy we should investigate how this
can be solved. We explicitly deferred it at the time, since we thought it
was not needed for now.

> > So if the intention was to allow choice, something is missing

+1

>> If not, I'd rather load the default implementations explicitly (via their
> > traditional constructor).

Where and how would you do that?

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150323/ea31af43/attachment.bin 

From brmeyer at redhat.com  Mon Mar 23 09:51:49 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Mon, 23 Mar 2015 09:51:49 -0400 (EDT)
Subject: [hibernate-dev] ORM Team "triage" meeting
In-Reply-To: <CAL00eSSffdM6dzSecLvObx9KZttDbpoxMUL09fEXzQ7KL=cWLA@mail.gmail.com>
References: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
	<CAL00eSSffdM6dzSecLvObx9KZttDbpoxMUL09fEXzQ7KL=cWLA@mail.gmail.com>
Message-ID: <622303598.2758003.1427118709845.JavaMail.zimbra@redhat.com>

Big +1 from me -- I'd be more than happy to be involved.

----- Original Message -----
> From: "andrea boriero" <dreborier at gmail.com>
> To: "Steve Ebersole" <steve at hibernate.org>
> Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Sunday, March 22, 2015 3:45:01 PM
> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> 
> for me at the moment it would be 6pm and it should be good.
> 
> On 21 March 2015 at 21:08, Steve Ebersole <steve at hibernate.org> wrote:
> 
> > Gail and I discussed Jira a little bit last week and how to best manage
> > scheduling issues.
> >
> > We both agreed that a team get together, either weekly or every-other-week,
> > to discuss new issues to triage them would be a great idea.
> >
> > One thing I absolutely do not want happening is just scheduling issues as a
> > means to come back and triage them later.  Scheduling an issue, on a "real
> > version" anyway, should mean something.  It should mean some level of
> > dedication to finish that task for that release.  In short, unless you are
> > volunteering to take on a task *yourself* for that release, please do not
> > schedule it for that release.
> >
> > As for the triage meeting, I would definitely like Gail and Andrea
> > involved.  Of course anyone is welcome.  The reason I mention this is that
> > Gail is usually left on early side of scheduling these.  So we will find a
> > time that works best for us 3 and go from there.  I recommend that we
> > leverage HipChat for these discussion.
> >
> > Andrea is coming to Austin for a few days starting Monday, so I would like
> > to start this triaging while he is here.  Gail, I am thinking 1pm my time
> > (11am yours) would be a good time.  Andrea, does that work for you after
> > Austin?
> > _______________________________________________
> > 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
> 

From steve at hibernate.org  Mon Mar 23 12:14:21 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 23 Mar 2015 11:14:21 -0500
Subject: [hibernate-dev] CI Server
In-Reply-To: <CAFdSV9uXLrDGLmhZpGfqAZCnjO=Mxqse1UKwsNmKvLqUVcsjHA@mail.gmail.com>
References: <CAFdSV9uXLrDGLmhZpGfqAZCnjO=Mxqse1UKwsNmKvLqUVcsjHA@mail.gmail.com>
Message-ID: <CAFdSV9s2p=c3MKD-V=_+1Fe2xKSoxybOAGC5Ccs357qB1cio0Q@mail.gmail.com>

https://hibernate.atlassian.net/browse/HHH-9678

For the time being I will go with the "simpler route".

On Sat, Mar 21, 2015 at 7:15 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I just finished work on HHH-8697 and HHH-9320 and pushed that work to
> master and 4.3.  After my push, the CI jobs for each started failing in a
> way I could not reproduce locally.  But I did eventually divine what was
> going on.  The failure is actually indicative of problem elsewhere.  And it
> may or may not be a problem outside of our test suite.  The issue is with
> fact that we register org.hibernate.type.descriptor.sql.SqlTypeDescriptor
> instances with
> a org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry that is
> unfortunately for now defined statically via a static INSTANCE variable.
> Our SqlTypeDescriptor implementations register themselves with the registry
> on creation.
>
> <backstory>
> This is all code I added for implementing AttributeConverter support.
> When we see an AttributeConverter we use the defined "database type" to
> perform a resolution from the defined type to the recommended JDBC style
> code for that type, and we then ask the SqlTypeDescriptorRegistry for the
> SqlTypeDescriptor corresponding to that JDBC type code.
> </backstory>
>
> There is a test that subclasses our internal VarcharTypeDescriptor.
> VarcharTypeDescriptor, like all the SqlTypeDescriptor impls, registers
> itself with the SqlTypeDescriptorRegistry during its instantiation.  The
> "issue" here is that this subclass also registers itself into the
> SqlTypeDescriptorRegistry during its instantiation via the call to the
> super ctor.  And because the SqlTypeDescriptorRegistry is static, this
> causes the "bleeding".
>
> How to fix this?  There are a few options.  Ideally
> SqlTypeDescriptorRegistry would not be static and we could just move on.
> However that is not possible given the current design of Types.  Now this
> does feed into some changes I wanted to make as we move forward in the Type
> system.  As I was developing our AttributeConverter support I thought it
> would be really awesome if a Type (a BasicType anyway) was just a dynamic
> combining of a SqlTypeDescriptor and a JavaTypeDescriptor (unless a
> specific Type was named).  Take a counter-example.  Today we have multiple
> Type impls to deal with storing a UUID (UUIDCharType, UUIDBinaryType,
> PostgresUUIDType).  But literally these are all just 3 different combinings
> of SqlTypeDescriptor and JavaTypeDescriptor:
> * UUIDCharType is a combo of UUIDTypeDescriptor and VarcharTypeDescriptor
> * UUIDBinaryType is a combo of UUIDTypeDescriptor and BinaryTypeDescriptor
> * PostgresUUIDType is a combo of UUIDTypeDescriptor and a specialed
> pgsql-specific SqlTypeDescriptor for its UUID dtype.
>
> The idea is similar to what I stated above in the backstory when
> determining an implicit type.  Today we use the java attribute type to do a
> look up into the based on registration keys *for the Type*.  Instead in
> this future model we would use the java attribute type to determine the
> recommended JDBC type code (String->Types.VARCHAR, etc) and then use that
> JDBC type code to determine the SqlTypeDescriptor to use.  Then combine
> that with the JavaTypeDescriptor for the java attribute type.  This
> approach has a lot of potential benefits including the ability to
> leverage java.sql.DatabaseMetaData#getTypeInfo.  The benefits aside, this
> is a big change, so I am not sure it is best to take that on for 5.0.
>
> The other solution I can think of for now is basically to limit what gets
> added to the SqlTypeDescriptorRegistry so that it is just Hibernate defined
> SqlTypeDescriptors.
>
> Hopefully I explained that well enough.  Anyway... thoughts?
>

From gbadner at redhat.com  Mon Mar 23 15:10:46 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 23 Mar 2015 15:10:46 -0400 (EDT)
Subject: [hibernate-dev] ORM Team "triage" meeting
In-Reply-To: <622303598.2758003.1427118709845.JavaMail.zimbra@redhat.com>
References: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
	<CAL00eSSffdM6dzSecLvObx9KZttDbpoxMUL09fEXzQ7KL=cWLA@mail.gmail.com>
	<622303598.2758003.1427118709845.JavaMail.zimbra@redhat.com>
Message-ID: <826763478.3552493.1427137846428.JavaMail.zimbra@redhat.com>

11am Seattle time would be ideal. Thanks!
Gail

----- Original Message -----
> From: "Brett Meyer" <brmeyer at redhat.com>
> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Monday, March 23, 2015 6:51:49 AM
> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> 
> Big +1 from me -- I'd be more than happy to be involved.
> 
> ----- Original Message -----
> > From: "andrea boriero" <dreborier at gmail.com>
> > To: "Steve Ebersole" <steve at hibernate.org>
> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > Sent: Sunday, March 22, 2015 3:45:01 PM
> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> > 
> > for me at the moment it would be 6pm and it should be good.
> > 
> > On 21 March 2015 at 21:08, Steve Ebersole <steve at hibernate.org> wrote:
> > 
> > > Gail and I discussed Jira a little bit last week and how to best manage
> > > scheduling issues.
> > >
> > > We both agreed that a team get together, either weekly or
> > > every-other-week,
> > > to discuss new issues to triage them would be a great idea.
> > >
> > > One thing I absolutely do not want happening is just scheduling issues as
> > > a
> > > means to come back and triage them later.  Scheduling an issue, on a
> > > "real
> > > version" anyway, should mean something.  It should mean some level of
> > > dedication to finish that task for that release.  In short, unless you
> > > are
> > > volunteering to take on a task *yourself* for that release, please do not
> > > schedule it for that release.
> > >
> > > As for the triage meeting, I would definitely like Gail and Andrea
> > > involved.  Of course anyone is welcome.  The reason I mention this is
> > > that
> > > Gail is usually left on early side of scheduling these.  So we will find
> > > a
> > > time that works best for us 3 and go from there.  I recommend that we
> > > leverage HipChat for these discussion.
> > >
> > > Andrea is coming to Austin for a few days starting Monday, so I would
> > > like
> > > to start this triaging while he is here.  Gail, I am thinking 1pm my time
> > > (11am yours) would be a good time.  Andrea, does that work for you after
> > > Austin?
> > > _______________________________________________
> > > 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
> > 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From hardy at hibernate.org  Mon Mar 23 16:57:03 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 23 Mar 2015 21:57:03 +0100
Subject: [hibernate-dev] Gradle build and multiple JDKs
In-Reply-To: <CAFdSV9sVATfxkzwUELmhj7pEUhrpkk+7=LKXQ=0u9t=jiOivcQ@mail.gmail.com>
References: <CAFdSV9sVATfxkzwUELmhj7pEUhrpkk+7=LKXQ=0u9t=jiOivcQ@mail.gmail.com>
Message-ID: <20150323205703.GB16871@Nineveh.lan>

Hi,

On Sun, Mar 22, 2015 at 10:11:32PM -0500, Steve Ebersole wrote:
> Ran across an interesting proof-of-concept project for setting up a Gradle
> build to use multiple JDKs: https://github.com/rwinch/gradle-multi-jdk
> 
> Curious what y'all think of this approach versus what we do know with
> AnimalSniffer...

I think the approach with AnimalSniffer is simpler. I only looked briefly at
the setup you are referring to and on top of the fact that we are back to
defining user specific properties (locations of the JDK home directories), I
got the impression that there is a fair bit more of configuration required.

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150323/3a2ae8fe/attachment.bin 

From hardy at hibernate.org  Mon Mar 23 17:01:10 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 23 Mar 2015 22:01:10 +0100
Subject: [hibernate-dev] Date/Time Support and timezones
In-Reply-To: <CAFdSV9sbcwkyRJ7oNN8PX=LFUyhrOZVdn7UDoH7ATENRk6h0sQ@mail.gmail.com>
References: <CAFdSV9sbcwkyRJ7oNN8PX=LFUyhrOZVdn7UDoH7ATENRk6h0sQ@mail.gmail.com>
Message-ID: <20150323210110.GC16871@Nineveh.lan>

> A few options:
> 
> 1) Forego OffsetDateTime, OffsetTime and ZonedDateTime support and just
> stick with LocalDateTime, LocalDate and LocalTime.
> 2) Use the timezone/offset to pass along to the driver (for proper
> conversion); when reading back we'd have to read back based on the default
> timezone.  This is essentially the old strategy used in CalendarType which
> I never really liked because its not reflexive.
> 3) Break them into a tuple of the store each piece.  E.g., for
> OffsetDateTime the Tuple is a LocalDateTime (the Timestamp) and a TZ
> offset.  So we'd store each individually in the database and be able to
> rebuild them in a fully reflexive manner.
> 4) Handle them using UTC or GMT at the JDBC level.  This is essentially the
> same as (2)

Personally, I think I'd prefer #3. I am not sure whether all users would be happy
with two columns for a OffsetDateTime. Could we support multiple options, for example 
#3 and #4 and make it configurable?

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150323/9dbebedc/attachment.bin 

From sanne at hibernate.org  Mon Mar 23 17:17:40 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 23 Mar 2015 21:17:40 +0000
Subject: [hibernate-dev] ORM Team "triage" meeting
In-Reply-To: <826763478.3552493.1427137846428.JavaMail.zimbra@redhat.com>
References: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
	<CAL00eSSffdM6dzSecLvObx9KZttDbpoxMUL09fEXzQ7KL=cWLA@mail.gmail.com>
	<622303598.2758003.1427118709845.JavaMail.zimbra@redhat.com>
	<826763478.3552493.1427137846428.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO2wNgSckVzqjnB_52fAjDBuBO=SVmyLf+zHvy39grMSAg@mail.gmail.com>

+1 it's a nice time to allow me to join occasionally as needed

Sanne

On 23 March 2015 at 19:10, Gail Badner <gbadner at redhat.com> wrote:
> 11am Seattle time would be ideal. Thanks!
> Gail
>
> ----- Original Message -----
>> From: "Brett Meyer" <brmeyer at redhat.com>
>> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>> Sent: Monday, March 23, 2015 6:51:49 AM
>> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
>>
>> Big +1 from me -- I'd be more than happy to be involved.
>>
>> ----- Original Message -----
>> > From: "andrea boriero" <dreborier at gmail.com>
>> > To: "Steve Ebersole" <steve at hibernate.org>
>> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>> > Sent: Sunday, March 22, 2015 3:45:01 PM
>> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
>> >
>> > for me at the moment it would be 6pm and it should be good.
>> >
>> > On 21 March 2015 at 21:08, Steve Ebersole <steve at hibernate.org> wrote:
>> >
>> > > Gail and I discussed Jira a little bit last week and how to best manage
>> > > scheduling issues.
>> > >
>> > > We both agreed that a team get together, either weekly or
>> > > every-other-week,
>> > > to discuss new issues to triage them would be a great idea.
>> > >
>> > > One thing I absolutely do not want happening is just scheduling issues as
>> > > a
>> > > means to come back and triage them later.  Scheduling an issue, on a
>> > > "real
>> > > version" anyway, should mean something.  It should mean some level of
>> > > dedication to finish that task for that release.  In short, unless you
>> > > are
>> > > volunteering to take on a task *yourself* for that release, please do not
>> > > schedule it for that release.
>> > >
>> > > As for the triage meeting, I would definitely like Gail and Andrea
>> > > involved.  Of course anyone is welcome.  The reason I mention this is
>> > > that
>> > > Gail is usually left on early side of scheduling these.  So we will find
>> > > a
>> > > time that works best for us 3 and go from there.  I recommend that we
>> > > leverage HipChat for these discussion.
>> > >
>> > > Andrea is coming to Austin for a few days starting Monday, so I would
>> > > like
>> > > to start this triaging while he is here.  Gail, I am thinking 1pm my time
>> > > (11am yours) would be a good time.  Andrea, does that work for you after
>> > > Austin?
>> > > _______________________________________________
>> > > 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
>> >
>> _______________________________________________
>> 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

From steve at hibernate.org  Mon Mar 23 22:00:54 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 23 Mar 2015 21:00:54 -0500
Subject: [hibernate-dev] Date/Time Support and timezones
In-Reply-To: <20150323210110.GC16871@Nineveh.lan>
References: <CAFdSV9sbcwkyRJ7oNN8PX=LFUyhrOZVdn7UDoH7ATENRk6h0sQ@mail.gmail.com>
	<20150323210110.GC16871@Nineveh.lan>
Message-ID: <CAFdSV9u-M0R9Q5oWuUXgGYbnNh2djDk4QA1Uz=EQQ7EPC4JSDw@mail.gmail.com>

Not in the same Type.  But of course "Type swapping" is so easy nowadays...

On Mon, Mar 23, 2015 at 4:01 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> > A few options:
> >
> > 1) Forego OffsetDateTime, OffsetTime and ZonedDateTime support and just
> > stick with LocalDateTime, LocalDate and LocalTime.
> > 2) Use the timezone/offset to pass along to the driver (for proper
> > conversion); when reading back we'd have to read back based on the
> default
> > timezone.  This is essentially the old strategy used in CalendarType
> which
> > I never really liked because its not reflexive.
> > 3) Break them into a tuple of the store each piece.  E.g., for
> > OffsetDateTime the Tuple is a LocalDateTime (the Timestamp) and a TZ
> > offset.  So we'd store each individually in the database and be able to
> > rebuild them in a fully reflexive manner.
> > 4) Handle them using UTC or GMT at the JDBC level.  This is essentially
> the
> > same as (2)
>
> Personally, I think I'd prefer #3. I am not sure whether all users would
> be happy
> with two columns for a OffsetDateTime. Could we support multiple options,
> for example
> #3 and #4 and make it configurable?
>
> --Hardy
>

From gunnar at hibernate.org  Tue Mar 24 08:30:29 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 24 Mar 2015 13:30:29 +0100
Subject: [hibernate-dev] Date/Time Support and timezones
In-Reply-To: <CAFdSV9u-M0R9Q5oWuUXgGYbnNh2djDk4QA1Uz=EQQ7EPC4JSDw@mail.gmail.com>
References: <CAFdSV9sbcwkyRJ7oNN8PX=LFUyhrOZVdn7UDoH7ATENRk6h0sQ@mail.gmail.com>
	<20150323210110.GC16871@Nineveh.lan>
	<CAFdSV9u-M0R9Q5oWuUXgGYbnNh2djDk4QA1Uz=EQQ7EPC4JSDw@mail.gmail.com>
Message-ID: <CADGJaX9keAf=UKreLyoN+MLPhnRqrzRXv0LR6LVu_0zdKu6+ag@mail.gmail.com>

3) seems most desirable to me, too.

What type would your "TZ" column have? Just a numeric offset? Or a VARCHAR,
also capable of storing textual TZ representations such as "+01:00
Europe/Paris"? I think the latter would be needed to make it fully
reflexive for ZonedDateTime.

Another variant of 3) could be to leverage DB-specific types such as
TIMESTAMP WITH TIME ZONE on Oracle. I could imagine that'd be what users of
databases supporting such a type might want.

--Gunnar


2015-03-24 3:00 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> Not in the same Type.  But of course "Type swapping" is so easy nowadays...
>
> On Mon, Mar 23, 2015 at 4:01 PM, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
>
> > > A few options:
> > >
> > > 1) Forego OffsetDateTime, OffsetTime and ZonedDateTime support and just
> > > stick with LocalDateTime, LocalDate and LocalTime.
> > > 2) Use the timezone/offset to pass along to the driver (for proper
> > > conversion); when reading back we'd have to read back based on the
> > default
> > > timezone.  This is essentially the old strategy used in CalendarType
> > which
> > > I never really liked because its not reflexive.
> > > 3) Break them into a tuple of the store each piece.  E.g., for
> > > OffsetDateTime the Tuple is a LocalDateTime (the Timestamp) and a TZ
> > > offset.  So we'd store each individually in the database and be able to
> > > rebuild them in a fully reflexive manner.
> > > 4) Handle them using UTC or GMT at the JDBC level.  This is essentially
> > the
> > > same as (2)
> >
> > Personally, I think I'd prefer #3. I am not sure whether all users would
> > be happy
> > with two columns for a OffsetDateTime. Could we support multiple options,
> > for example
> > #3 and #4 and make it configurable?
> >
> > --Hardy
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Mar 24 09:40:05 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 24 Mar 2015 08:40:05 -0500
Subject: [hibernate-dev] Gradle build and multiple JDKs
In-Reply-To: <20150323205703.GB16871@Nineveh.lan>
References: <CAFdSV9sVATfxkzwUELmhj7pEUhrpkk+7=LKXQ=0u9t=jiOivcQ@mail.gmail.com>
	<20150323205703.GB16871@Nineveh.lan>
Message-ID: <CAFdSV9sL5F6HERyKe7OcB=t2j1onrZa+vj8LW74uWi5bayx5Qg@mail.gmail.com>

AnimalSniffer is causing us a lot of headaches in conjunction with Java 8.

Gunnar suggested overriding the ASM version used, but that did not help for
us in Gradle (this could very well be a difference between Maven/Gradle).



On Mon, Mar 23, 2015 at 3:57 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> On Sun, Mar 22, 2015 at 10:11:32PM -0500, Steve Ebersole wrote:
> > Ran across an interesting proof-of-concept project for setting up a
> Gradle
> > build to use multiple JDKs: https://github.com/rwinch/gradle-multi-jdk
> >
> > Curious what y'all think of this approach versus what we do know with
> > AnimalSniffer...
>
> I think the approach with AnimalSniffer is simpler. I only looked briefly
> at
> the setup you are referring to and on top of the fact that we are back to
> defining user specific properties (locations of the JDK home directories),
> I
> got the impression that there is a fair bit more of configuration required.
>
> --Hardy
>

From hardy at hibernate.org  Wed Mar 25 05:05:05 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 25 Mar 2015 10:05:05 +0100
Subject: [hibernate-dev] Gradle build and multiple JDKs
In-Reply-To: <CAFdSV9sL5F6HERyKe7OcB=t2j1onrZa+vj8LW74uWi5bayx5Qg@mail.gmail.com>
References: <CAFdSV9sVATfxkzwUELmhj7pEUhrpkk+7=LKXQ=0u9t=jiOivcQ@mail.gmail.com>
	<20150323205703.GB16871@Nineveh.lan>
	<CAFdSV9sL5F6HERyKe7OcB=t2j1onrZa+vj8LW74uWi5bayx5Qg@mail.gmail.com>
Message-ID: <20150325090505.GA92855@Nineveh.lan>

On Tue, Mar 24, 2015 at 08:40:05AM -0500, Steve Ebersole wrote:
> AnimalSniffer is causing us a lot of headaches in conjunction with Java 8.

Ahh, right. I forgot about this. I somehow thought that was resolved by now.

> Gunnar suggested overriding the ASM version used, but that did not help for
> us in Gradle (this could very well be a difference between Maven/Gradle).

Back to Maven!? ;-)

Is this a problem of  AnimalSniffer itself? Did anyone bother to report it?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150325/188a4d0f/attachment.bin 

From steve at hibernate.org  Wed Mar 25 09:13:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 Mar 2015 08:13:23 -0500
Subject: [hibernate-dev] Gradle build and multiple JDKs
In-Reply-To: <20150325090505.GA92855@Nineveh.lan>
References: <CAFdSV9sVATfxkzwUELmhj7pEUhrpkk+7=LKXQ=0u9t=jiOivcQ@mail.gmail.com>
	<20150323205703.GB16871@Nineveh.lan>
	<CAFdSV9sL5F6HERyKe7OcB=t2j1onrZa+vj8LW74uWi5bayx5Qg@mail.gmail.com>
	<20150325090505.GA92855@Nineveh.lan>
Message-ID: <CAFdSV9tTbg=VBy8XSHCRL6+Oc-05cV9X55-jy+HVraxmStD+Lw@mail.gmail.com>

We eventually got something working.  Was a PITA though.
On Mar 25, 2015 4:18 AM, "Hardy Ferentschik" <hardy at hibernate.org> wrote:

> On Tue, Mar 24, 2015 at 08:40:05AM -0500, Steve Ebersole wrote:
> > AnimalSniffer is causing us a lot of headaches in conjunction with Java
> 8.
>
> Ahh, right. I forgot about this. I somehow thought that was resolved by
> now.
>
> > Gunnar suggested overriding the ASM version used, but that did not help
> for
> > us in Gradle (this could very well be a difference between Maven/Gradle).
>
> Back to Maven!? ;-)
>
> Is this a problem of  AnimalSniffer itself? Did anyone bother to report it?
>
>

From gunnar at hibernate.org  Wed Mar 25 12:28:13 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 25 Mar 2015 17:28:13 +0100
Subject: [hibernate-dev] SessionFactory building APIs
In-Reply-To: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>
References: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>
Message-ID: <CADGJaX8RFUFH4NUZHtmkJr9Mvj9ow697GQSmd8p_8HbT_6ff=g@mail.gmail.com>

2) What do you think of all the overloaded methods named #with tacking
different argument types, versus distinctly named methods?

I find it sub-optimal as it falls apart if there are several parameters of
the same type (e.g. String or boolean). This leads to some irregularities
in the names, e.g. atm. there is withImplicitSchemaName(String),
withImplicitCatalogName(String) but then with(PhysicalNamingStrategy).

Personally, I'd do implicitSchemaName(String), implicitCatalogName(String),
physicalNamingStrategy(PhysicalNamingStrategy) etc. i.e. just the name of
the property to set.

2015-03-21 19:09 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> I had not heard anything back in regards to this, so I wanted to ask one
> more time before I get ready to start cutting 5.0 pre-releases in a week or
> 2.
>
> I'd love to heard feedback of any kind about the new APIs, but specific
> things I know I personally question:
>
> 1) What do you think of the split in MetadataSources and MetadataBuilder?
> Does the aplit make sense?  Or does it make more sense to combine them into
> one contract?
>
> 2) What do you think of all the overloaded methods named #with tacking
> different argument types, versus distinctly named methods?  E.g.
> MetadataBuilder#with(ImplicitNamingStrategy),
> MetadataBuilder#with(PhysicalNamingStrategy), etc rather than
> MetadataBuilder#withImplicitNamingStrategy(ImplicitNamingStrategy),
> MetadataBuilder#withPhysicalNamingStrategy(PhysicalNamingStrategy)
>
> Also, I am not so sure about the term "with" anymore.  I had chosen that at
> the time because I thought it flowed nicely with method chaining.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Mar 25 13:19:33 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 Mar 2015 12:19:33 -0500
Subject: [hibernate-dev] Transaction
Message-ID: <CAFdSV9sE5k50n8=BWiXNG8Uy81Jf+6a7yJHpRH7SsTLeL0tOCA@mail.gmail.com>

I thought I had asked this before, but maybe not.  Andrea and I are working
through the transaction/jdbc changes and I really would like to clean up
the org.hibernate.Transaction API.  But before I start cutting I wanted to
make sure noone is using the methods I plan on getting rid of...

Here is the new proposed contract:

public interface Transsaction {
    public void begin();
    public void commit();
    public void rollback();
    public void markRollbackOnly();

    public Status getStatus();

    public int getTimeout();
    public void setTimeout(int seconds);

    public void registerSynchronization(Synchronization synchronization);
}

public enum Status {
  NOT_ACTIVE,
  ACTIVE,
  COMMITTED,
  ROLLED_BACK,
    FAILED_COMMIT
}

Notes:
1) isInitiator() has been removed with no real replacement.  I could not
really see when that would be useful.
2) isParticipating() has been removed with no real replacement.
2) isActive(), wasCommitted() and wasRolledBack has all been removed with
call to getStatus() as replacement
3) getLocalStatus() is gone.  Who cares :)  If users are asking us this, we
really should be checking the REAL state of the transaction
4) Transaction is now a single impl.  The distinctions are all handled
internally.  TransactionImplementor is gone too.

Thoughts?  Concerns?

From steve at hibernate.org  Wed Mar 25 13:20:27 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 Mar 2015 12:20:27 -0500
Subject: [hibernate-dev] SessionFactory building APIs
In-Reply-To: <CADGJaX8RFUFH4NUZHtmkJr9Mvj9ow697GQSmd8p_8HbT_6ff=g@mail.gmail.com>
References: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>
	<CADGJaX8RFUFH4NUZHtmkJr9Mvj9ow697GQSmd8p_8HbT_6ff=g@mail.gmail.com>
Message-ID: <CAFdSV9vqMu9Y-gH0Y+DMU+TfVp_Uy6dSUeaAXZONuKDQG5zaqQ@mail.gmail.com>

I can get behind that.

Anyone else?

On Wed, Mar 25, 2015 at 11:28 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> 2) What do you think of all the overloaded methods named #with tacking
> different argument types, versus distinctly named methods?
>
> I find it sub-optimal as it falls apart if there are several parameters of
> the same type (e.g. String or boolean). This leads to some irregularities
> in the names, e.g. atm. there is withImplicitSchemaName(String),
> withImplicitCatalogName(String) but then with(PhysicalNamingStrategy).
>
> Personally, I'd do implicitSchemaName(String),
> implicitCatalogName(String), physicalNamingStrategy(PhysicalNamingStrategy)
> etc. i.e. just the name of the property to set.
>
> 2015-03-21 19:09 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> I had not heard anything back in regards to this, so I wanted to ask one
>> more time before I get ready to start cutting 5.0 pre-releases in a week
>> or
>> 2.
>>
>> I'd love to heard feedback of any kind about the new APIs, but specific
>> things I know I personally question:
>>
>> 1) What do you think of the split in MetadataSources and MetadataBuilder?
>> Does the aplit make sense?  Or does it make more sense to combine them
>> into
>> one contract?
>>
>> 2) What do you think of all the overloaded methods named #with tacking
>> different argument types, versus distinctly named methods?  E.g.
>> MetadataBuilder#with(ImplicitNamingStrategy),
>> MetadataBuilder#with(PhysicalNamingStrategy), etc rather than
>> MetadataBuilder#withImplicitNamingStrategy(ImplicitNamingStrategy),
>> MetadataBuilder#withPhysicalNamingStrategy(PhysicalNamingStrategy)
>>
>> Also, I am not so sure about the term "with" anymore.  I had chosen that
>> at
>> the time because I thought it flowed nicely with method chaining.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Wed Mar 25 16:15:52 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 Mar 2015 15:15:52 -0500
Subject: [hibernate-dev] Transaction
In-Reply-To: <CAFdSV9sE5k50n8=BWiXNG8Uy81Jf+6a7yJHpRH7SsTLeL0tOCA@mail.gmail.com>
References: <CAFdSV9sE5k50n8=BWiXNG8Uy81Jf+6a7yJHpRH7SsTLeL0tOCA@mail.gmail.com>
Message-ID: <CAFdSV9sVQuNjxjUbTQDQcX_9mR=HSsjbiiEpvC+UQkUqxfefvQ@mail.gmail.com>

We also identified needs for Status#ROLLING_BACK and Status#COMMITTING, so
consider those in the enum as well.

On Wed, Mar 25, 2015 at 12:19 PM, Steve Ebersole <steve at hibernate.org>
wrote:

> I thought I had asked this before, but maybe not.  Andrea and I are
> working through the transaction/jdbc changes and I really would like to
> clean up the org.hibernate.Transaction API.  But before I start cutting I
> wanted to make sure noone is using the methods I plan on getting rid of...
>
> Here is the new proposed contract:
>
> public interface Transsaction {
>     public void begin();
>     public void commit();
>     public void rollback();
>     public void markRollbackOnly();
>
>     public Status getStatus();
>
>     public int getTimeout();
>     public void setTimeout(int seconds);
>
>     public void registerSynchronization(Synchronization synchronization);
> }
>
> public enum Status {
>   NOT_ACTIVE,
>   ACTIVE,
>   COMMITTED,
>   ROLLED_BACK,
>     FAILED_COMMIT
> }
>
> Notes:
> 1) isInitiator() has been removed with no real replacement.  I could not
> really see when that would be useful.
> 2) isParticipating() has been removed with no real replacement.
> 2) isActive(), wasCommitted() and wasRolledBack has all been removed with
> call to getStatus() as replacement
> 3) getLocalStatus() is gone.  Who cares :)  If users are asking us this,
> we really should be checking the REAL state of the transaction
> 4) Transaction is now a single impl.  The distinctions are all handled
> internally.  TransactionImplementor is gone too.
>
> Thoughts?  Concerns?
>

From hardy at hibernate.org  Wed Mar 25 17:42:30 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 25 Mar 2015 22:42:30 +0100
Subject: [hibernate-dev] SessionFactory building APIs
In-Reply-To: <CAFdSV9vqMu9Y-gH0Y+DMU+TfVp_Uy6dSUeaAXZONuKDQG5zaqQ@mail.gmail.com>
References: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>
	<CADGJaX8RFUFH4NUZHtmkJr9Mvj9ow697GQSmd8p_8HbT_6ff=g@mail.gmail.com>
	<CAFdSV9vqMu9Y-gH0Y+DMU+TfVp_Uy6dSUeaAXZONuKDQG5zaqQ@mail.gmail.com>
Message-ID: <20150325214230.GB548@Nineveh.lan>

On Wed, Mar 25, 2015 at 12:20:27PM -0500, Steve Ebersole wrote:
> I can get behind that.
> 
> Anyone else?

+1

--Hardy 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150325/dce02a73/attachment.bin 

From gunnar at hibernate.org  Wed Mar 25 17:57:01 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 25 Mar 2015 22:57:01 +0100
Subject: [hibernate-dev] SessionFactory building APIs
In-Reply-To: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>
References: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>
Message-ID: <CADGJaX_+mPnzP6gThinXNJZJVPmXA41au8HLxrh=O2NV8-umCA@mail.gmail.com>

> 1) What do you think of the split in MetadataSources and MetadataBuilder?
> Does the aplit make sense?  Or does it make more sense to combine them
into
> one contract?

I think the split makes sense, as I understand that there are two different
"phases" of configuration here:

* add multiple sources of configuration (XML files, annotated classes)
* apply further configuration (naming strategy etc.)

Assuming one first needs to configure all the sources before applying the
configuration from the second category, it seems useful to express that in
the API.

The name "MetadataSources" made me stumble a bit, though. Generally I find
pluralized class names a bit odd, only really useful for either
collection-like classes or static helper classes dealing with a specific
type (e.g. Strings, Collections). What would you think about
MetadataSources not being a top-level class itself, but rather an inner
class of MetadataBuilder (e.g. named MetadataBuilderContext) which is
returned by a static creator method on MetadataBuilder:

MetadataBuilder builder = MetadataBuilder.configure() // returns
MetadataBuilderContext
    .addFile(...)
    .addAnnotatedClass(...)
    .addResource(...)
    .getBuilder();

IMO that would help users a bit to find the right entry point.

Some more questions/thoughts:

* Who is the intended client for the getter methods on MetadataSources?
Only ORM, or also user code? In case of the former, should the public
MetadataSources
contract be an interface with the addXy() methods only, whereas getters are
only accessible via an internal implementation class? That would narrow
down the exposed API.
* Are MetadataSources#addAttributeConverter(), addAuxiliaryDatabaseObject()
and addSqlFunction() adding a *source* for meta-data really? Somehow it
seems they should rather be located on MetadataBuilder?
* I don't think MetadataSources is intended for concurrent usage from
several threads, right? If so, it should not be needed to have a
ConcurrentHashMap as a member
* MetadataSources#addInputStream() et al.: What schema have passed streams
to adhere to? Are these orm.xml, hbm.xml or both? Would be nice to have
this documented
* MetadataBuilder#setSourceProcessOrdering: May be a bit nicer to use if
modelled with var-args:

    sourceTypeProcessingOrder(MetadataSourceType first,
MetadataSourceType... others) -> used like sourceTypeProcessingOrder(
CLASS, HBM );

--Gunnar


2015-03-21 19:09 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> I had not heard anything back in regards to this, so I wanted to ask one
> more time before I get ready to start cutting 5.0 pre-releases in a week or
> 2.
>
> I'd love to heard feedback of any kind about the new APIs, but specific
> things I know I personally question:
>
> 1) What do you think of the split in MetadataSources and MetadataBuilder?
> Does the aplit make sense?  Or does it make more sense to combine them into
> one contract?
>
> 2) What do you think of all the overloaded methods named #with tacking
> different argument types, versus distinctly named methods?  E.g.
> MetadataBuilder#with(ImplicitNamingStrategy),
> MetadataBuilder#with(PhysicalNamingStrategy), etc rather than
> MetadataBuilder#withImplicitNamingStrategy(ImplicitNamingStrategy),
> MetadataBuilder#withPhysicalNamingStrategy(PhysicalNamingStrategy)
>
> Also, I am not so sure about the term "with" anymore.  I had chosen that at
> the time because I thought it flowed nicely with method chaining.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mih_vlad at yahoo.com  Wed Mar 25 18:05:24 2015
From: mih_vlad at yahoo.com (Mihalcea Vlad)
Date: Wed, 25 Mar 2015 22:05:24 +0000 (UTC)
Subject: [hibernate-dev] Support for DELETE statements ActionQueue sorting
Message-ID: <1593310606.1663202.1427321124917.JavaMail.yahoo@mail.yahoo.com>

Hi,
While INSERT sorting is handled by ActionQueue.InsertActionSorter, DELETE statements are not sorted at all.
A DeleteActionSorter woudl have to rearrange DELETES in the opposite order as the INSERT sorting, the Children having to be deleted first.
The current work-around is to dissociate all Children and manually flush the Session, so that the orphan-removal kicks in before the Parent entities delete occurs.
Any plans for supporting such a feature?

Vlad Mihalcea

From steve at hibernate.org  Wed Mar 25 19:21:48 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 Mar 2015 18:21:48 -0500
Subject: [hibernate-dev] SessionFactory building APIs
In-Reply-To: <CADGJaX_+mPnzP6gThinXNJZJVPmXA41au8HLxrh=O2NV8-umCA@mail.gmail.com>
References: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>
	<CADGJaX_+mPnzP6gThinXNJZJVPmXA41au8HLxrh=O2NV8-umCA@mail.gmail.com>
Message-ID: <CAFdSV9tPF8smQfUNaKa3Yr6n7YbOKRhG5Da2JNhEWTG-J-LqZw@mail.gmail.com>

On Wed, Mar 25, 2015 at 4:57 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> > 1) What do you think of the split in MetadataSources and MetadataBuilder?
> > Does the aplit make sense?  Or does it make more sense to combine them
> into
> > one contract?
>
> I think the split makes sense, as I understand that there are two
> different "phases" of configuration here:
>
> * add multiple sources of configuration (XML files, annotated classes)
> * apply further configuration (naming strategy etc.)
>

> Assuming one first needs to configure all the sources before applying the
> configuration from the second category, it seems useful to express that in
> the API.
>

MetadataSources is used to collect the sources of mapping information.
However, its really not necessary that the split exists in terms of "this
needs to be set before that".  Its more a functional split because they
each serve different roles.  One collects the sources of metadata
information.  One builds that into a Metadata object (based on some config).



>
> The name "MetadataSources" made me stumble a bit, though. Generally I find
> pluralized class names a bit odd, only really useful for either
> collection-like classes or static helper classes dealing with a specific
> type (e.g. Strings, Collections). What would you think about
> MetadataSources not being a top-level class itself, but rather an inner
> class of MetadataBuilder (e.g. named MetadataBuilderContext) which is
> returned by a static creator method on MetadataBuilder:
>
> MetadataBuilder builder = MetadataBuilder.configure() // returns
> MetadataBuilderContext
>     .addFile(...)
>     .addAnnotatedClass(...)
>     .addResource(...)
>     .getBuilder();
>
> IMO that would help users a bit to find the right entry point.
>

Not sure about the naming.  I think MetadataSources is much better
than MetadataBuilderContext.
That's my take.  We can see what others think.

As far as the API, I am ok with changing that up if others agree.  I could
see something like:

MetadataBuilder.defineSources()
    .addFile(...)
    .addAnnotatedClass(...)
    .addResource(...)
    .getBuilder();

defineSources (or whatever we call it) needs to be overloaded to be able to
accept a ServiceRegistry:

MetadataBuilder.defineSources()

versus:

MetadataBuilder.defineSources( new
StandardServiceRegistryBuilder()...build() )




> Some more questions/thoughts:
>
> * Who is the intended client for the getter methods on MetadataSources?
> Only ORM, or also user code? In case of the former, should the public MetadataSources
> contract be an interface with the addXy() methods only, whereas getters are
> only accessible via an internal implementation class? That would narrow
> down the exposed API.
>

Yes, the intended usage is just Hibernate itself.  However, the exposure is
just a natural follow on of the design that MetadataSources is a class that
one instantiates directly.  Can't instantiate an interface of course.  An
approach such as above addresses that.


> * Are MetadataSources#addAttributeConverter(),
> addAuxiliaryDatabaseObject() and addSqlFunction() adding a *source* for
> meta-data really? Somehow it seems they should rather be located on
> MetadataBuilder?
>

>From one perspective yes.  Not *sources* per-se, but they are things that
the user supplies that become part of the Metadata; as opposed to simply
options that are used during the process of building a Metadata
(MetadataBuilder).  And especially since you want to rename "sources" to
"building context"; imo that makes the argument that these belong here even
stronger.



> * I don't think MetadataSources is intended for concurrent usage from
> several threads, right? If so, it should not be needed to have a
> ConcurrentHashMap as a member
>

True.  Not sure why it stores those in ConcurrentHashMap...



> * MetadataSources#addInputStream() et al.: What schema have passed streams
> to adhere to? Are these orm.xml, hbm.xml or both? Would be nice to have
> this documented
>

Well same is true of addResources, addFile, add..  I get what you are
saying, but why do you single out addInputStream here?  To be honest, I
would personally love to get rid of addInputStream.  I think
addInputStreamAccess(InputStreamAccess) is a MUCH better solution there.



> * MetadataBuilder#setSourceProcessOrdering: May be a bit nicer to use if
> modelled with var-args:
>
>     sourceTypeProcessingOrder(MetadataSourceType first,
> MetadataSourceType... others) -> used like sourceTypeProcessingOrder(
> CLASS, HBM );
>


+1

From steve at hibernate.org  Wed Mar 25 22:56:16 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 Mar 2015 21:56:16 -0500
Subject: [hibernate-dev] SessionFactory building APIs
In-Reply-To: <CAFdSV9tPF8smQfUNaKa3Yr6n7YbOKRhG5Da2JNhEWTG-J-LqZw@mail.gmail.com>
References: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>
	<CADGJaX_+mPnzP6gThinXNJZJVPmXA41au8HLxrh=O2NV8-umCA@mail.gmail.com>
	<CAFdSV9tPF8smQfUNaKa3Yr6n7YbOKRhG5Da2JNhEWTG-J-LqZw@mail.gmail.com>
Message-ID: <CAFdSV9uKJr_kpJLa63r0fL5KQ7D1NZcx2w+7Ci_uPKQbOyizcg@mail.gmail.com>

On second thought...

MetadataBuilder is also an interface (unless you are suggesting to change
that for some reason), so not sure how a call like this would work:

MetadataBuilder.defineSources()



On Wed, Mar 25, 2015 at 6:21 PM, Steve Ebersole <steve at hibernate.org> wrote:

> On Wed, Mar 25, 2015 at 4:57 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> > 1) What do you think of the split in MetadataSources and
>> MetadataBuilder?
>> > Does the aplit make sense?  Or does it make more sense to combine them
>> into
>> > one contract?
>>
>> I think the split makes sense, as I understand that there are two
>> different "phases" of configuration here:
>>
>> * add multiple sources of configuration (XML files, annotated classes)
>> * apply further configuration (naming strategy etc.)
>>
>
>> Assuming one first needs to configure all the sources before applying the
>> configuration from the second category, it seems useful to express that in
>> the API.
>>
>
> MetadataSources is used to collect the sources of mapping information.
> However, its really not necessary that the split exists in terms of "this
> needs to be set before that".  Its more a functional split because they
> each serve different roles.  One collects the sources of metadata
> information.  One builds that into a Metadata object (based on some config).
>
>
>
>>
>> The name "MetadataSources" made me stumble a bit, though. Generally I
>> find pluralized class names a bit odd, only really useful for either
>> collection-like classes or static helper classes dealing with a specific
>> type (e.g. Strings, Collections). What would you think about
>> MetadataSources not being a top-level class itself, but rather an inner
>> class of MetadataBuilder (e.g. named MetadataBuilderContext) which is
>> returned by a static creator method on MetadataBuilder:
>>
>> MetadataBuilder builder = MetadataBuilder.configure() // returns
>> MetadataBuilderContext
>>     .addFile(...)
>>     .addAnnotatedClass(...)
>>     .addResource(...)
>>     .getBuilder();
>>
>> IMO that would help users a bit to find the right entry point.
>>
>
> Not sure about the naming.  I think MetadataSources is much better than MetadataBuilderContext.
> That's my take.  We can see what others think.
>
> As far as the API, I am ok with changing that up if others agree.  I could
> see something like:
>
> MetadataBuilder.defineSources()
>     .addFile(...)
>     .addAnnotatedClass(...)
>     .addResource(...)
>     .getBuilder();
>
> defineSources (or whatever we call it) needs to be overloaded to be able
> to accept a ServiceRegistry:
>
> MetadataBuilder.defineSources()
>
> versus:
>
> MetadataBuilder.defineSources( new
> StandardServiceRegistryBuilder()...build() )
>
>
>
>
>> Some more questions/thoughts:
>>
>> * Who is the intended client for the getter methods on MetadataSources?
>> Only ORM, or also user code? In case of the former, should the public MetadataSources
>> contract be an interface with the addXy() methods only, whereas getters are
>> only accessible via an internal implementation class? That would narrow
>> down the exposed API.
>>
>
> Yes, the intended usage is just Hibernate itself.  However, the exposure
> is just a natural follow on of the design that MetadataSources is a class
> that one instantiates directly.  Can't instantiate an interface of course.
> An approach such as above addresses that.
>
>
>> * Are MetadataSources#addAttributeConverter(),
>> addAuxiliaryDatabaseObject() and addSqlFunction() adding a *source* for
>> meta-data really? Somehow it seems they should rather be located on
>> MetadataBuilder?
>>
>
> From one perspective yes.  Not *sources* per-se, but they are things that
> the user supplies that become part of the Metadata; as opposed to simply
> options that are used during the process of building a Metadata
> (MetadataBuilder).  And especially since you want to rename "sources" to
> "building context"; imo that makes the argument that these belong here even
> stronger.
>
>
>
>> * I don't think MetadataSources is intended for concurrent usage from
>> several threads, right? If so, it should not be needed to have a
>> ConcurrentHashMap as a member
>>
>
> True.  Not sure why it stores those in ConcurrentHashMap...
>
>
>
>> * MetadataSources#addInputStream() et al.: What schema have passed
>> streams to adhere to? Are these orm.xml, hbm.xml or both? Would be nice to
>> have this documented
>>
>
> Well same is true of addResources, addFile, add..  I get what you are
> saying, but why do you single out addInputStream here?  To be honest, I
> would personally love to get rid of addInputStream.  I think
> addInputStreamAccess(InputStreamAccess) is a MUCH better solution there.
>
>
>
>> * MetadataBuilder#setSourceProcessOrdering: May be a bit nicer to use if
>> modelled with var-args:
>>
>>     sourceTypeProcessingOrder(MetadataSourceType first,
>> MetadataSourceType... others) -> used like sourceTypeProcessingOrder(
>> CLASS, HBM );
>>
>
>
> +1
>
>

From steve at hibernate.org  Thu Mar 26 00:31:47 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 Mar 2015 23:31:47 -0500
Subject: [hibernate-dev] SessionFactory building APIs
In-Reply-To: <CAFdSV9tPF8smQfUNaKa3Yr6n7YbOKRhG5Da2JNhEWTG-J-LqZw@mail.gmail.com>
References: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>
	<CADGJaX_+mPnzP6gThinXNJZJVPmXA41au8HLxrh=O2NV8-umCA@mail.gmail.com>
	<CAFdSV9tPF8smQfUNaKa3Yr6n7YbOKRhG5Da2JNhEWTG-J-LqZw@mail.gmail.com>
Message-ID: <CAFdSV9vV-nHnePDH2m1Xq0S8K01Btz1v0MMOSgrT-kGD0ghGrA@mail.gmail.com>

>
>
>> * Are MetadataSources#addAttributeConverter(),
>> addAuxiliaryDatabaseObject() and addSqlFunction() adding a *source* for
>> meta-data really? Somehow it seems they should rather be located on
>> MetadataBuilder?
>>
>
> From one perspective yes.  Not *sources* per-se, but they are things that
> the user supplies that become part of the Metadata; as opposed to simply
> options that are used during the process of building a Metadata
> (MetadataBuilder).  And especially since you want to rename "sources" to
> "building context"; imo that makes the argument that these belong here even
> stronger.
>

I went back and investigated these.  I had added them there more out of
convenience to continue to support Configuration.  But I think you are
right, they do not belong there.  So these are now moved to MetadataBuilder

From gunnar at hibernate.org  Thu Mar 26 04:05:43 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 26 Mar 2015 09:05:43 +0100
Subject: [hibernate-dev] SessionFactory building APIs
In-Reply-To: <CAFdSV9tPF8smQfUNaKa3Yr6n7YbOKRhG5Da2JNhEWTG-J-LqZw@mail.gmail.com>
References: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>
	<CADGJaX_+mPnzP6gThinXNJZJVPmXA41au8HLxrh=O2NV8-umCA@mail.gmail.com>
	<CAFdSV9tPF8smQfUNaKa3Yr6n7YbOKRhG5Da2JNhEWTG-J-LqZw@mail.gmail.com>
Message-ID: <CADGJaX93Thn0-RLnveP20aHkB04GU0E1BDZUXVuGfGZ4XdiYsg@mail.gmail.com>

2015-03-26 0:21 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> On Wed, Mar 25, 2015 at 4:57 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> > 1) What do you think of the split in MetadataSources and
>> MetadataBuilder?
>> > Does the aplit make sense?  Or does it make more sense to combine them
>> into
>> > one contract?
>>
>> I think the split makes sense, as I understand that there are two
>> different "phases" of configuration here:
>>
>> * add multiple sources of configuration (XML files, annotated classes)
>> * apply further configuration (naming strategy etc.)
>>
>
>> Assuming one first needs to configure all the sources before applying the
>> configuration from the second category, it seems useful to express that in
>> the API.
>>
>
> MetadataSources is used to collect the sources of mapping information.
> However, its really not necessary that the split exists in terms of "this
> needs to be set before that".  Its more a functional split because they
> each serve different roles.  One collects the sources of metadata
> information.  One builds that into a Metadata object (based on some config).
>

I see. Also if it's not strictly needed, I kind of like the split, as it
enforces some structuring of client code which should help with readability.


> The name "MetadataSources" made me stumble a bit, though. Generally I find
>> pluralized class names a bit odd, only really useful for either
>> collection-like classes or static helper classes dealing with a specific
>> type (e.g. Strings, Collections). What would you think about
>> MetadataSources not being a top-level class itself, but rather an inner
>> class of MetadataBuilder (e.g. named MetadataBuilderContext) which is
>> returned by a static creator method on MetadataBuilder:
>>
>> MetadataBuilder builder = MetadataBuilder.configure() // returns
>> MetadataBuilderContext
>>     .addFile(...)
>>     .addAnnotatedClass(...)
>>     .addResource(...)
>>     .getBuilder();
>>
>> IMO that would help users a bit to find the right entry point.
>>
>
> Not sure about the naming.  I think MetadataSources is much better than MetadataBuilderContext.
> That's my take.  We can see what others think.
>
> As far as the API, I am ok with changing that up if others agree.  I could
> see something like:
>
> MetadataBuilder.defineSources()
>     .addFile(...)
>     .addAnnotatedClass(...)
>     .addResource(...)
>     .getBuilder();
>
> defineSources (or whatever we call it) needs to be overloaded to be able
> to accept a ServiceRegistry:
>
> MetadataBuilder.defineSources()
>
> versus:
>
> MetadataBuilder.defineSources( new
> StandardServiceRegistryBuilder()...build() )
>

Ok.

>
>> Some more questions/thoughts:
>>
>> * Who is the intended client for the getter methods on MetadataSources?
>> Only ORM, or also user code? In case of the former, should the public MetadataSources
>> contract be an interface with the addXy() methods only, whereas getters are
>> only accessible via an internal implementation class? That would narrow
>> down the exposed API.
>>
>
> Yes, the intended usage is just Hibernate itself.  However, the exposure
> is just a natural follow on of the design that MetadataSources is a class
> that one instantiates directly.  Can't instantiate an interface of course.
> An approach such as above addresses that.
>

Yes, it would be nice to hide all those methods from the API which are not
intended for the user.


> * Are MetadataSources#addAttributeConverter(),
>> addAuxiliaryDatabaseObject() and addSqlFunction() adding a *source* for
>> meta-data really? Somehow it seems they should rather be located on
>> MetadataBuilder?
>>
>
> From one perspective yes.  Not *sources* per-se, but they are things that
> the user supplies that become part of the Metadata; as opposed to simply
> options that are used during the process of building a Metadata
> (MetadataBuilder).  And especially since you want to rename "sources" to
> "building context"; imo that makes the argument that these belong here even
> stronger.
>
>
>
>> * I don't think MetadataSources is intended for concurrent usage from
>> several threads, right? If so, it should not be needed to have a
>> ConcurrentHashMap as a member
>>
>
> True.  Not sure why it stores those in ConcurrentHashMap...
>
>
>
>> * MetadataSources#addInputStream() et al.: What schema have passed
>> streams to adhere to? Are these orm.xml, hbm.xml or both? Would be nice to
>> have this documented
>>
>
> Well same is true of addResources, addFile, add..  I get what you are
> saying, but why do you single out addInputStream here?
>

That was only one example, it applies to others as well.


>   To be honest, I would personally love to get rid of addInputStream.  I
> think addInputStreamAccess(InputStreamAccess) is a MUCH better solution
> there.
>

Not sure, that would require to invoke another method/ctor to obtain the
ISA from whatever type the user wishes to add, right? I think it's easier
on the user if they can pass their input type directly.

Speaking of it, I see there is
MetadataSources#addInputStream(InputStreamAccess) already. ISA lives in
*.spi, though. IMO the API should not leak SPI types in signatures.

Btw. could you also add addPackage(Package), so one can do

    addPackage( MyEntity.class.getPackage() )

?

* MetadataBuilder#setSourceProcessOrdering: May be a bit nicer to use if
>> modelled with var-args:
>>
>>     sourceTypeProcessingOrder(MetadataSourceType first,
>> MetadataSourceType... others) -> used like sourceTypeProcessingOrder(
>> CLASS, HBM );
>>
>
>
> +1
>
>

From gunnar at hibernate.org  Thu Mar 26 04:35:14 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 26 Mar 2015 09:35:14 +0100
Subject: [hibernate-dev] SessionFactory building APIs
In-Reply-To: <CAFdSV9uKJr_kpJLa63r0fL5KQ7D1NZcx2w+7Ci_uPKQbOyizcg@mail.gmail.com>
References: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>
	<CADGJaX_+mPnzP6gThinXNJZJVPmXA41au8HLxrh=O2NV8-umCA@mail.gmail.com>
	<CAFdSV9tPF8smQfUNaKa3Yr6n7YbOKRhG5Da2JNhEWTG-J-LqZw@mail.gmail.com>
	<CAFdSV9uKJr_kpJLa63r0fL5KQ7D1NZcx2w+7Ci_uPKQbOyizcg@mail.gmail.com>
Message-ID: <CADGJaX8r+vy-SUo5gG3v1mDOC72ExC_P0tOWB-Kyd-+jHxBm9w@mail.gmail.com>

2015-03-26 3:56 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> On second thought...
>
> MetadataBuilder is also an interface (unless you are suggesting to change
> that for some reason), so not sure how a call like this would work:
>
> MetadataBuilder.defineSources()
>

Ah, I forgot you cannot rely on Java 8 yet ;)

So a static method somewhere else would be needed indeed, maybe something
like:

    Bootstrap.configureMetadataBuilderSources()
        .addFile(...)
        .getMetadataBuilder();

On Wed, Mar 25, 2015 at 6:21 PM, Steve Ebersole <steve at hibernate.org> wrote:
>
>> On Wed, Mar 25, 2015 at 4:57 PM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> > 1) What do you think of the split in MetadataSources and
>>> MetadataBuilder?
>>> > Does the aplit make sense?  Or does it make more sense to combine them
>>> into
>>> > one contract?
>>>
>>> I think the split makes sense, as I understand that there are two
>>> different "phases" of configuration here:
>>>
>>> * add multiple sources of configuration (XML files, annotated classes)
>>> * apply further configuration (naming strategy etc.)
>>>
>>
>>> Assuming one first needs to configure all the sources before applying
>>> the configuration from the second category, it seems useful to express that
>>> in the API.
>>>
>>
>> MetadataSources is used to collect the sources of mapping information.
>> However, its really not necessary that the split exists in terms of "this
>> needs to be set before that".  Its more a functional split because they
>> each serve different roles.  One collects the sources of metadata
>> information.  One builds that into a Metadata object (based on some config).
>>
>>
>>
>>>
>>> The name "MetadataSources" made me stumble a bit, though. Generally I
>>> find pluralized class names a bit odd, only really useful for either
>>> collection-like classes or static helper classes dealing with a specific
>>> type (e.g. Strings, Collections). What would you think about
>>> MetadataSources not being a top-level class itself, but rather an inner
>>> class of MetadataBuilder (e.g. named MetadataBuilderContext) which is
>>> returned by a static creator method on MetadataBuilder:
>>>
>>> MetadataBuilder builder = MetadataBuilder.configure() // returns
>>> MetadataBuilderContext
>>>     .addFile(...)
>>>     .addAnnotatedClass(...)
>>>     .addResource(...)
>>>     .getBuilder();
>>>
>>> IMO that would help users a bit to find the right entry point.
>>>
>>
>> Not sure about the naming.  I think MetadataSources is much better than MetadataBuilderContext.
>> That's my take.  We can see what others think.
>>
>> As far as the API, I am ok with changing that up if others agree.  I
>> could see something like:
>>
>> MetadataBuilder.defineSources()
>>     .addFile(...)
>>     .addAnnotatedClass(...)
>>     .addResource(...)
>>     .getBuilder();
>>
>> defineSources (or whatever we call it) needs to be overloaded to be able
>> to accept a ServiceRegistry:
>>
>> MetadataBuilder.defineSources()
>>
>> versus:
>>
>> MetadataBuilder.defineSources( new
>> StandardServiceRegistryBuilder()...build() )
>>
>>
>>
>>
>>> Some more questions/thoughts:
>>>
>>> * Who is the intended client for the getter methods on MetadataSources?
>>> Only ORM, or also user code? In case of the former, should the public MetadataSources
>>> contract be an interface with the addXy() methods only, whereas getters are
>>> only accessible via an internal implementation class? That would narrow
>>> down the exposed API.
>>>
>>
>> Yes, the intended usage is just Hibernate itself.  However, the exposure
>> is just a natural follow on of the design that MetadataSources is a class
>> that one instantiates directly.  Can't instantiate an interface of course.
>> An approach such as above addresses that.
>>
>>
>>> * Are MetadataSources#addAttributeConverter(),
>>> addAuxiliaryDatabaseObject() and addSqlFunction() adding a *source* for
>>> meta-data really? Somehow it seems they should rather be located on
>>> MetadataBuilder?
>>>
>>
>> From one perspective yes.  Not *sources* per-se, but they are things that
>> the user supplies that become part of the Metadata; as opposed to simply
>> options that are used during the process of building a Metadata
>> (MetadataBuilder).  And especially since you want to rename "sources" to
>> "building context"; imo that makes the argument that these belong here even
>> stronger.
>>
>>
>>
>>> * I don't think MetadataSources is intended for concurrent usage from
>>> several threads, right? If so, it should not be needed to have a
>>> ConcurrentHashMap as a member
>>>
>>
>> True.  Not sure why it stores those in ConcurrentHashMap...
>>
>>
>>
>>> * MetadataSources#addInputStream() et al.: What schema have passed
>>> streams to adhere to? Are these orm.xml, hbm.xml or both? Would be nice to
>>> have this documented
>>>
>>
>> Well same is true of addResources, addFile, add..  I get what you are
>> saying, but why do you single out addInputStream here?  To be honest, I
>> would personally love to get rid of addInputStream.  I think
>> addInputStreamAccess(InputStreamAccess) is a MUCH better solution there.
>>
>>
>>
>>> * MetadataBuilder#setSourceProcessOrdering: May be a bit nicer to use if
>>> modelled with var-args:
>>>
>>>     sourceTypeProcessingOrder(MetadataSourceType first,
>>> MetadataSourceType... others) -> used like sourceTypeProcessingOrder(
>>> CLASS, HBM );
>>>
>>
>>
>> +1
>>
>>
>

From emmanuel at hibernate.org  Thu Mar 26 05:27:02 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 26 Mar 2015 10:27:02 +0100
Subject: [hibernate-dev] "Unified commit"
Message-ID: <522F66E5-F206-48B7-8AE3-3D3E4150020F@hibernate.org>

Interesting, Neo4J 2.2 now does unified commits like we do in Hibernate Search to get several transactions per disk flush in Lucene.

http://neo4j.com/blog/neo4j-2-2-0-scalability-performance/

From sanne at hibernate.org  Thu Mar 26 08:35:20 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Mar 2015 12:35:20 +0000
Subject: [hibernate-dev] "Unified commit"
In-Reply-To: <522F66E5-F206-48B7-8AE3-3D3E4150020F@hibernate.org>
References: <522F66E5-F206-48B7-8AE3-3D3E4150020F@hibernate.org>
Message-ID: <CAFm4XO0UZPQAbJPD0ZwT0nb4HTYTPpFFtXfiw_XAqHQuwwB3fA@mail.gmail.com>

Interesting, glad we have prior art ;)

They seem to have gone a step further though: a single unified commit
of Neo4J includes both the data and the index changesets. We still
have to figure out how to better integrate the index changes with the
database transaction; although that's only interesting for a minority
use case and I still agree that our current design is better for most
typical use cases, but some have asked for stronger XA like
guarantees.

On 26 March 2015 at 09:27, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Interesting, Neo4J 2.2 now does unified commits like we do in Hibernate Search to get several transactions per disk flush in Lucene.
>
> http://neo4j.com/blog/neo4j-2-2-0-scalability-performance/
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Thu Mar 26 08:44:09 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 26 Mar 2015 13:44:09 +0100
Subject: [hibernate-dev] GSOC15 OGM
In-Reply-To: <CAO9N6GoJov7Ss5+C6ygSrgh7J3TSpW-iBTaqfdaia0_iARwChg@mail.gmail.com>
References: <CAO9N6GoJov7Ss5+C6ygSrgh7J3TSpW-iBTaqfdaia0_iARwChg@mail.gmail.com>
Message-ID: <92037C45-0A93-4DEB-B932-26237ECA6606@hibernate.org>

Hi Adam,

We did discuss it and we don?t feel like we have the bandwidth this year to mentor a Google Summer of Code student. We would do them a disservice. So we will pass this year.

Emmanuel

> On 22 Mar 2015, at 09:28, Adam Stawicki <adamstawicki91 at gmail.com> wrote:
> 
> Do we still have enough time to suggest an additional idea?
> I think about picking, interesting form me, already existing JIRA issues
> like: [1] [2] [3] [4].
> 
> What do you think?
> 
> 
> [1] https://hibernate.atlassian.net/browse/OGM-728
> [2] https://hibernate.atlassian.net/browse/OGM-768
> [3] https://hibernate.atlassian.net/browse/OGM-785
> [4] https://hibernate.atlassian.net/browse/OGM-786
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From steve at hibernate.org  Thu Mar 26 10:56:28 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 26 Mar 2015 09:56:28 -0500
Subject: [hibernate-dev] SessionFactory building APIs
In-Reply-To: <CADGJaX8r+vy-SUo5gG3v1mDOC72ExC_P0tOWB-Kyd-+jHxBm9w@mail.gmail.com>
References: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>
	<CADGJaX_+mPnzP6gThinXNJZJVPmXA41au8HLxrh=O2NV8-umCA@mail.gmail.com>
	<CAFdSV9tPF8smQfUNaKa3Yr6n7YbOKRhG5Da2JNhEWTG-J-LqZw@mail.gmail.com>
	<CAFdSV9uKJr_kpJLa63r0fL5KQ7D1NZcx2w+7Ci_uPKQbOyizcg@mail.gmail.com>
	<CADGJaX8r+vy-SUo5gG3v1mDOC72ExC_P0tOWB-Kyd-+jHxBm9w@mail.gmail.com>
Message-ID: <CAFdSV9scBJ1QNtjv9tF3nGJUXJTOmCHMxf9n-5-eQOv4fm9Y0w@mail.gmail.com>

I'm not so convinced that we need this additional level of instantiation
just to avoid exposing access to the collected sources (getters).

Anyone else have opinions on this?

On Thu, Mar 26, 2015 at 3:35 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> 2015-03-26 3:56 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> On second thought...
>>
>> MetadataBuilder is also an interface (unless you are suggesting to change
>> that for some reason), so not sure how a call like this would work:
>>
>> MetadataBuilder.defineSources()
>>
>
> Ah, I forgot you cannot rely on Java 8 yet ;)
>
> So a static method somewhere else would be needed indeed, maybe something
> like:
>
>     Bootstrap.configureMetadataBuilderSources()
>         .addFile(...)
>         .getMetadataBuilder();
>
> On Wed, Mar 25, 2015 at 6:21 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> On Wed, Mar 25, 2015 at 4:57 PM, Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>
>>>> > 1) What do you think of the split in MetadataSources and
>>>> MetadataBuilder?
>>>> > Does the aplit make sense?  Or does it make more sense to combine
>>>> them into
>>>> > one contract?
>>>>
>>>> I think the split makes sense, as I understand that there are two
>>>> different "phases" of configuration here:
>>>>
>>>> * add multiple sources of configuration (XML files, annotated classes)
>>>> * apply further configuration (naming strategy etc.)
>>>>
>>>
>>>> Assuming one first needs to configure all the sources before applying
>>>> the configuration from the second category, it seems useful to express that
>>>> in the API.
>>>>
>>>
>>> MetadataSources is used to collect the sources of mapping information.
>>> However, its really not necessary that the split exists in terms of "this
>>> needs to be set before that".  Its more a functional split because they
>>> each serve different roles.  One collects the sources of metadata
>>> information.  One builds that into a Metadata object (based on some config).
>>>
>>>
>>>
>>>>
>>>> The name "MetadataSources" made me stumble a bit, though. Generally I
>>>> find pluralized class names a bit odd, only really useful for either
>>>> collection-like classes or static helper classes dealing with a specific
>>>> type (e.g. Strings, Collections). What would you think about
>>>> MetadataSources not being a top-level class itself, but rather an inner
>>>> class of MetadataBuilder (e.g. named MetadataBuilderContext) which is
>>>> returned by a static creator method on MetadataBuilder:
>>>>
>>>> MetadataBuilder builder = MetadataBuilder.configure() // returns
>>>> MetadataBuilderContext
>>>>     .addFile(...)
>>>>     .addAnnotatedClass(...)
>>>>     .addResource(...)
>>>>     .getBuilder();
>>>>
>>>> IMO that would help users a bit to find the right entry point.
>>>>
>>>
>>> Not sure about the naming.  I think MetadataSources is much better than MetadataBuilderContext.
>>> That's my take.  We can see what others think.
>>>
>>> As far as the API, I am ok with changing that up if others agree.  I
>>> could see something like:
>>>
>>> MetadataBuilder.defineSources()
>>>     .addFile(...)
>>>     .addAnnotatedClass(...)
>>>     .addResource(...)
>>>     .getBuilder();
>>>
>>> defineSources (or whatever we call it) needs to be overloaded to be able
>>> to accept a ServiceRegistry:
>>>
>>> MetadataBuilder.defineSources()
>>>
>>> versus:
>>>
>>> MetadataBuilder.defineSources( new
>>> StandardServiceRegistryBuilder()...build() )
>>>
>>>
>>>
>>>
>>>> Some more questions/thoughts:
>>>>
>>>> * Who is the intended client for the getter methods on MetadataSources?
>>>> Only ORM, or also user code? In case of the former, should the public MetadataSources
>>>> contract be an interface with the addXy() methods only, whereas getters are
>>>> only accessible via an internal implementation class? That would narrow
>>>> down the exposed API.
>>>>
>>>
>>> Yes, the intended usage is just Hibernate itself.  However, the exposure
>>> is just a natural follow on of the design that MetadataSources is a class
>>> that one instantiates directly.  Can't instantiate an interface of course.
>>> An approach such as above addresses that.
>>>
>>>
>>>> * Are MetadataSources#addAttributeConverter(),
>>>> addAuxiliaryDatabaseObject() and addSqlFunction() adding a *source* for
>>>> meta-data really? Somehow it seems they should rather be located on
>>>> MetadataBuilder?
>>>>
>>>
>>> From one perspective yes.  Not *sources* per-se, but they are things
>>> that the user supplies that become part of the Metadata; as opposed to
>>> simply options that are used during the process of building a Metadata
>>> (MetadataBuilder).  And especially since you want to rename "sources" to
>>> "building context"; imo that makes the argument that these belong here even
>>> stronger.
>>>
>>>
>>>
>>>> * I don't think MetadataSources is intended for concurrent usage from
>>>> several threads, right? If so, it should not be needed to have a
>>>> ConcurrentHashMap as a member
>>>>
>>>
>>> True.  Not sure why it stores those in ConcurrentHashMap...
>>>
>>>
>>>
>>>> * MetadataSources#addInputStream() et al.: What schema have passed
>>>> streams to adhere to? Are these orm.xml, hbm.xml or both? Would be nice to
>>>> have this documented
>>>>
>>>
>>> Well same is true of addResources, addFile, add..  I get what you are
>>> saying, but why do you single out addInputStream here?  To be honest, I
>>> would personally love to get rid of addInputStream.  I think
>>> addInputStreamAccess(InputStreamAccess) is a MUCH better solution there.
>>>
>>>
>>>
>>>> * MetadataBuilder#setSourceProcessOrdering: May be a bit nicer to use
>>>> if modelled with var-args:
>>>>
>>>>     sourceTypeProcessingOrder(MetadataSourceType first,
>>>> MetadataSourceType... others) -> used like sourceTypeProcessingOrder(
>>>> CLASS, HBM );
>>>>
>>>
>>>
>>> +1
>>>
>>>
>>
>

From sanne at hibernate.org  Thu Mar 26 11:20:02 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Mar 2015 15:20:02 +0000
Subject: [hibernate-dev] Bytecode enhanced,
	Reference Cached immutable Entities
In-Reply-To: <55112E1C.5030004@redhat.com>
References: <55003692.9080906@gmail.com>
	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>
	<5502B18F.4050403@redhat.com> <5507F2D4.8040202@redhat.com>
	<55112E1C.5030004@redhat.com>
Message-ID: <CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>

[adding the mailing list]

Generally speaking, looks like we agree on the direction: EntityEntry
needs to be an interface, and some clever logic to select the
appropriate implementations.
In your draft you're having a single EntityEntryFactory as a global
service; I'm wondering if we shouldn't have the possibiliy to have a
different factory implementation per Entry type.. more on this below.

What is your primary differentiator between 'SharedEntityEntry' and
'StatefulEntityEntry' ?
For our purposes I'd have used different names, but since there's no
javadoc yet I wonder if you had different intentions.

Personally I'd have chosen something like "ImmutableEntityEntry" and
"MutableEntityEntry", there the Mutable one is a rename of the
existing implementation, and the Immutable would be a slimmed down
version which might not need fields such as:
 - loadedState (not needed for readonly)
 - version (what would be the point)
 - ..

A concern I have is to avoid ever needing to "promote" an
ImmutableEntityEntry into a MutableEntityEntry: it's easy to mark an
existing instance of ImmutableEntityEntry as READ_ONLY, but there is
no going back if the entity entry was initially loaded as READ_ONLY.
One could think of swapping the existing entityentry, but that could
get hairy and defeats the point of optimising object allocations.

Is there a strong guarantee which we can rely on, that if an
EntityEntry is marked READ_ONLY at first load, noone will ever need to
re-mark it as mutable?
If not, the current check in DefaultEntityEntryFactory basing the
choice on the current status of the Entity might not be enough, we
might need to be a bit more conservative and only based that on
getPersister().isMutable() ?

The READ_ONLY point which you're leveraging for this specific
optimisation seems to be key for the specific optimisation we have in
mind at this point; but generalizing the concept it seems to me that
the choice of EE implementation to use for a specific Entity type will
be a consistent choice for the lifecycle of the EntityPersister, and
depending on immutable flags on the EntityPersister. Which is why I'm
suggesting that the EntityPersister should have a dedicated
EntityEntryFactory. Making the EntityEntryFactory a global service
would force to go through all the checks of the EE implementation
choice each time, while the choice should always be the same. I
wouldn't argue to save a couple of simple "if" evaluations, but it's
very possible that some more clever EntityEntryFactory implementations
than this current draft might need to do more work, for example
consult more Services to call back into OGM metadata.
Not least, having a per-type EntityEntryFactory would make it possible
to refer to it from some EntityEntry implementations and save some
memory around the common state.

Concurrency
   Since the goal is to share the ImmutableEntityEntry instance among
multiple threads reading it, I'd rather make sure that it is really
immutable. For example it now holds onto potentially lazy initialized
fields, such as getEntityKey().
If it's not possible to make it really immutable (all final fields),
we'll need to make it threadsafe and question the name I'm proposing.

LockMode
  From a logical perspective of users, one might think that an entity
being "immutable" doesn't necessarily imply I can't lock on it..
right? I'm not sure how far it could be a valid use case, but these
patches are implying that one can't lock an immutable entity anymore,
as the lock state would be as immutable as anything else on the
EntityEntry.
Are we good with that? Alternatively one might need to think to
separate the lock state handling from the EntityEntry.

On smaller details:
# org.hibernate.engine.internal.SharedEntityEntry is hosted in an
.internal package, I don't think it's right to refactor all the public
API javadoc which was referring to EntityEntry to now refer to the
internal implementation.
# things like EntityEntryExtraState should probably get moved to
.internal packages as well now - we couldn't do that before without
breaking either encapsulation or APIs.

In terms of git patches, the complexity of the changeset risks to get
a bit our of hand. What about we focus on creating a clean pull
request which focuses exclusively on making EntityEntry an interface,
and move things to the right packages and javadoc?
You'd have a trivial EntitEntryFactory, and we can then build the
evolution on top of that, not least maybe helping out by challenging
some points in parallel work.
These are the things I'd leave for a second iteration:
 - add various implementations of EntityEntry iteratively, as needed
 - the strategy such a Factory would use the pick an implementation
 - ultimately, make it possible for an integrator to override such a Factory

For example with Hibernate OGM we might want to override / re
configure the factories to use custom EntityEntry implementations -
requirements are not fully clear at this point but it seems likely.

The priority being to define the API as that would be a blocker for
5.0, we have then better choices to leave more smarter and advanced
EntityEntry implementations for the future; we'd still need to
implement at least the essential ones to make sure the API of the
EntityEntryFactory has all the context it needs.

Thanks,
Sanne


On 24 March 2015 at 09:27, John O'Hara <johara at redhat.com> wrote:
> Steve,
>
> Have you had chance to look at this? Do you have any comments/observations?
>
> Thanks
>
> John
>
>
> On 17/03/15 09:24, John O'Hara wrote:
>
> Steve,
>
> I have been having a think about the EntityEntry interface, and have forked
> a branch here:
>
> https://github.com/johnaoahra80/hibernate-orm/tree/EntityEntryInterface
>
> I know it is nowhere near complete, but was this the sort of idea you had in
> mind?
>
> Thanks
>
> John
>
>
> On 13/03/15 09:44, John O'Hara wrote:
>
> EntityEntry retains a reference to a persistenceContext internally that
> org.hibernate.engine.spi.EntityEntry#setReadOnly makes calls to, is this
> where the session reference is kept?  As
> org.hibernate.engine.spi.PersistenceConext is an interface could we have a
> different implementation for this use case? e.g. an
> ImmutablePersistenceContext that could be shared across sessions?
>
> For the bytecode enhancement, could we change the enhancer so that it adds
> an EntityEntry interface with javassist.
> ClassPool.javassist.ClassPool.makeInterface()() as opposed to adding a class
> javassist.ClassPool.makeClass()? I need to have a look at javassit to
> confirm what javassist.ClassPool.makeInterface() does.
>
> Thanks
>
> John
>
> On 12/03/15 18:52, Steve Ebersole wrote:
>
> It is possible.  Although some of the changes are particularly painful.
> Most of EntityEntry, if it is an interface, can be made to work with your
> use case.  org.hibernate.engine.spi.EntityEntry#setReadOnly I think is the
> one exception, because:
> 1) your use case needs it
> 2) it expects the Session to be available internally (its not passed)
>
> The bigger thing I am worried about for you is the bytecode stuff, as that
> ties very tightly with EntityEntry.
>

From sanne at hibernate.org  Thu Mar 26 11:44:28 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Mar 2015 15:44:28 +0000
Subject: [hibernate-dev] Date/Time Support and timezones
In-Reply-To: <CADGJaX9keAf=UKreLyoN+MLPhnRqrzRXv0LR6LVu_0zdKu6+ag@mail.gmail.com>
References: <CAFdSV9sbcwkyRJ7oNN8PX=LFUyhrOZVdn7UDoH7ATENRk6h0sQ@mail.gmail.com>
	<20150323210110.GC16871@Nineveh.lan>
	<CAFdSV9u-M0R9Q5oWuUXgGYbnNh2djDk4QA1Uz=EQQ7EPC4JSDw@mail.gmail.com>
	<CADGJaX9keAf=UKreLyoN+MLPhnRqrzRXv0LR6LVu_0zdKu6+ag@mail.gmail.com>
Message-ID: <CAFm4XO2-H8MFPkSRecSqF=AKMC_+BLjnb6CgRHfE8s=xAZ1n7g@mail.gmail.com>

Forcing 3 is correct but rarely desirable, I'm afraid the user should choose.

But most people will not like the additional
space/performance/complexity hit, and will use a single timezone.

If you think we should force people into a correct choice, you'd
require 3# unless they are willing to set a global timezone
configuration property, or maybe even a per-property timezone on the
mapping, in which case you'd go for 2(4) but having them choose the
poison.

On 24 March 2015 at 12:30, Gunnar Morling <gunnar at hibernate.org> wrote:
> 3) seems most desirable to me, too.
>
> What type would your "TZ" column have? Just a numeric offset? Or a VARCHAR,
> also capable of storing textual TZ representations such as "+01:00
> Europe/Paris"? I think the latter would be needed to make it fully
> reflexive for ZonedDateTime.
>
> Another variant of 3) could be to leverage DB-specific types such as
> TIMESTAMP WITH TIME ZONE on Oracle. I could imagine that'd be what users of
> databases supporting such a type might want.
>
> --Gunnar
>
>
> 2015-03-24 3:00 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> Not in the same Type.  But of course "Type swapping" is so easy nowadays...
>>
>> On Mon, Mar 23, 2015 at 4:01 PM, Hardy Ferentschik <hardy at hibernate.org>
>> wrote:
>>
>> > > A few options:
>> > >
>> > > 1) Forego OffsetDateTime, OffsetTime and ZonedDateTime support and just
>> > > stick with LocalDateTime, LocalDate and LocalTime.
>> > > 2) Use the timezone/offset to pass along to the driver (for proper
>> > > conversion); when reading back we'd have to read back based on the
>> > default
>> > > timezone.  This is essentially the old strategy used in CalendarType
>> > which
>> > > I never really liked because its not reflexive.
>> > > 3) Break them into a tuple of the store each piece.  E.g., for
>> > > OffsetDateTime the Tuple is a LocalDateTime (the Timestamp) and a TZ
>> > > offset.  So we'd store each individually in the database and be able to
>> > > rebuild them in a fully reflexive manner.
>> > > 4) Handle them using UTC or GMT at the JDBC level.  This is essentially
>> > the
>> > > same as (2)
>> >
>> > Personally, I think I'd prefer #3. I am not sure whether all users would
>> > be happy
>> > with two columns for a OffsetDateTime. Could we support multiple options,
>> > for example
>> > #3 and #4 and make it configurable?
>> >
>> > --Hardy
>> >
>> _______________________________________________
>> 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

From steve at hibernate.org  Thu Mar 26 11:50:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 26 Mar 2015 10:50:23 -0500
Subject: [hibernate-dev] Bytecode enhanced,
	Reference Cached immutable Entities
In-Reply-To: <CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
References: <55003692.9080906@gmail.com>
	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>
	<5502B18F.4050403@redhat.com> <5507F2D4.8040202@redhat.com>
	<55112E1C.5030004@redhat.com>
	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
Message-ID: <CAFdSV9vVp+BXkTVq8sHhBkUTruX8Y3KRP_8E3UM9p0OtCdFY_w@mail.gmail.com>

Thanks for your thoughts Sanne.  I am going to break my responses down into
digestable chunks to follow...


On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> [adding the mailing list]
>
> Generally speaking, looks like we agree on the direction: EntityEntry
> needs to be an interface, and some clever logic to select the
> appropriate implementations.
> In your draft you're having a single EntityEntryFactory as a global
> service; I'm wondering if we shouldn't have the possibiliy to have a
> different factory implementation per Entry type.. more on this below.
>
> What is your primary differentiator between 'SharedEntityEntry' and
> 'StatefulEntityEntry' ?
> For our purposes I'd have used different names, but since there's no
> javadoc yet I wonder if you had different intentions.
>
> Personally I'd have chosen something like "ImmutableEntityEntry" and
> "MutableEntityEntry", there the Mutable one is a rename of the
> existing implementation, and the Immutable would be a slimmed down
> version which might not need fields such as:
>  - loadedState (not needed for readonly)
>  - version (what would be the point)
>  - ..
>
> A concern I have is to avoid ever needing to "promote" an
> ImmutableEntityEntry into a MutableEntityEntry: it's easy to mark an
> existing instance of ImmutableEntityEntry as READ_ONLY, but there is
> no going back if the entity entry was initially loaded as READ_ONLY.
> One could think of swapping the existing entityentry, but that could
> get hairy and defeats the point of optimising object allocations.
>
> Is there a strong guarantee which we can rely on, that if an
> EntityEntry is marked READ_ONLY at first load, noone will ever need to
> re-mark it as mutable?
> If not, the current check in DefaultEntityEntryFactory basing the
> choice on the current status of the Entity might not be enough, we
> might need to be a bit more conservative and only based that on
> getPersister().isMutable() ?
>
> The READ_ONLY point which you're leveraging for this specific
> optimisation seems to be key for the specific optimisation we have in
> mind at this point; but generalizing the concept it seems to me that
> the choice of EE implementation to use for a specific Entity type will
> be a consistent choice for the lifecycle of the EntityPersister, and
> depending on immutable flags on the EntityPersister. Which is why I'm
> suggesting that the EntityPersister should have a dedicated
> EntityEntryFactory. Making the EntityEntryFactory a global service
> would force to go through all the checks of the EE implementation
> choice each time, while the choice should always be the same. I
> wouldn't argue to save a couple of simple "if" evaluations, but it's
> very possible that some more clever EntityEntryFactory implementations
> than this current draft might need to do more work, for example
> consult more Services to call back into OGM metadata.
> Not least, having a per-type EntityEntryFactory would make it possible
> to refer to it from some EntityEntry implementations and save some
> memory around the common state.
>
> Concurrency
>    Since the goal is to share the ImmutableEntityEntry instance among
> multiple threads reading it, I'd rather make sure that it is really
> immutable. For example it now holds onto potentially lazy initialized
> fields, such as getEntityKey().
> If it's not possible to make it really immutable (all final fields),
> we'll need to make it threadsafe and question the name I'm proposing.
>
> LockMode
>   From a logical perspective of users, one might think that an entity
> being "immutable" doesn't necessarily imply I can't lock on it..
> right? I'm not sure how far it could be a valid use case, but these
> patches are implying that one can't lock an immutable entity anymore,
> as the lock state would be as immutable as anything else on the
> EntityEntry.
> Are we good with that? Alternatively one might need to think to
> separate the lock state handling from the EntityEntry.
>
> On smaller details:
> # org.hibernate.engine.internal.SharedEntityEntry is hosted in an
> .internal package, I don't think it's right to refactor all the public
> API javadoc which was referring to EntityEntry to now refer to the
> internal implementation.
> # things like EntityEntryExtraState should probably get moved to
> .internal packages as well now - we couldn't do that before without
> breaking either encapsulation or APIs.
>
> In terms of git patches, the complexity of the changeset risks to get
> a bit our of hand. What about we focus on creating a clean pull
> request which focuses exclusively on making EntityEntry an interface,
> and move things to the right packages and javadoc?
> You'd have a trivial EntitEntryFactory, and we can then build the
> evolution on top of that, not least maybe helping out by challenging
> some points in parallel work.
> These are the things I'd leave for a second iteration:
>  - add various implementations of EntityEntry iteratively, as needed
>  - the strategy such a Factory would use the pick an implementation
>  - ultimately, make it possible for an integrator to override such a
> Factory
>
> For example with Hibernate OGM we might want to override / re
> configure the factories to use custom EntityEntry implementations -
> requirements are not fully clear at this point but it seems likely.
>
> The priority being to define the API as that would be a blocker for
> 5.0, we have then better choices to leave more smarter and advanced
> EntityEntry implementations for the future; we'd still need to
> implement at least the essential ones to make sure the API of the
> EntityEntryFactory has all the context it needs.
>
> Thanks,
> Sanne
>
>
> On 24 March 2015 at 09:27, John O'Hara <johara at redhat.com> wrote:
> > Steve,
> >
> > Have you had chance to look at this? Do you have any
> comments/observations?
> >
> > Thanks
> >
> > John
> >
> >
> > On 17/03/15 09:24, John O'Hara wrote:
> >
> > Steve,
> >
> > I have been having a think about the EntityEntry interface, and have
> forked
> > a branch here:
> >
> > https://github.com/johnaoahra80/hibernate-orm/tree/EntityEntryInterface
> >
> > I know it is nowhere near complete, but was this the sort of idea you
> had in
> > mind?
> >
> > Thanks
> >
> > John
> >
> >
> > On 13/03/15 09:44, John O'Hara wrote:
> >
> > EntityEntry retains a reference to a persistenceContext internally that
> > org.hibernate.engine.spi.EntityEntry#setReadOnly makes calls to, is this
> > where the session reference is kept?  As
> > org.hibernate.engine.spi.PersistenceConext is an interface could we have
> a
> > different implementation for this use case? e.g. an
> > ImmutablePersistenceContext that could be shared across sessions?
> >
> > For the bytecode enhancement, could we change the enhancer so that it
> adds
> > an EntityEntry interface with javassist.
> > ClassPool.javassist.ClassPool.makeInterface()() as opposed to adding a
> class
> > javassist.ClassPool.makeClass()? I need to have a look at javassit to
> > confirm what javassist.ClassPool.makeInterface() does.
> >
> > Thanks
> >
> > John
> >
> > On 12/03/15 18:52, Steve Ebersole wrote:
> >
> > It is possible.  Although some of the changes are particularly painful.
> > Most of EntityEntry, if it is an interface, can be made to work with your
> > use case.  org.hibernate.engine.spi.EntityEntry#setReadOnly I think is
> the
> > one exception, because:
> > 1) your use case needs it
> > 2) it expects the Session to be available internally (its not passed)
> >
> > The bigger thing I am worried about for you is the bytecode stuff, as
> that
> > ties very tightly with EntityEntry.
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Mar 26 11:58:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 26 Mar 2015 10:58:55 -0500
Subject: [hibernate-dev] Bytecode enhanced,
	Reference Cached immutable Entities
In-Reply-To: <CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
References: <55003692.9080906@gmail.com>
	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>
	<5502B18F.4050403@redhat.com> <5507F2D4.8040202@redhat.com>
	<55112E1C.5030004@redhat.com>
	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
Message-ID: <CAFdSV9sFDr-984gFGGPxnU79u66YPAktonV9wJmfSjfp=Q3F6A@mail.gmail.com>

On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:
>
>
> Concurrency
>    Since the goal is to share the ImmutableEntityEntry instance among
> multiple threads reading it, I'd rather make sure that it is really
> immutable. For example it now holds onto potentially lazy initialized
> fields, such as getEntityKey().
> If it's not possible to make it really immutable (all final fields),
> we'll need to make it threadsafe and question the name I'm proposing.
>

The specific use-case John is interested in does indeed need to be
completely thread-safe and fully concurrent.


> LockMode
>   From a logical perspective of users, one might think that an entity
> being "immutable" doesn't necessarily imply I can't lock on it..
> right? I'm not sure how far it could be a valid use case, but these
> patches are implying that one can't lock an immutable entity anymore,
> as the lock state would be as immutable as anything else on the
> EntityEntry.
> Are we good with that? Alternatively one might need to think to
> separate the lock state handling from the EntityEntry.
>

Conceptually there is nothing wrong with requesting a READ lock on an
immutable entity.  But like you said, what is the logical expectation
there?  IMO there should be none.  But if we decide that it is OK to req

Notice I said immutable here and not READ_ONLY which is a specific
distinction which is important to other parts of your email that I will
address in a second email.



>
> On smaller details:
> # org.hibernate.engine.internal.SharedEntityEntry is hosted in an
> .internal package, I don't think it's right to refactor all the public
> API javadoc which was referring to EntityEntry to now refer to the
> internal implementation.
> # things like EntityEntryExtraState should probably get moved to
> .internal packages as well now - we couldn't do that before without
> breaking either encapsulation or APIs.
>
> In terms of git patches, the complexity of the changeset risks to get
> a bit our of hand. What about we focus on creating a clean pull
> request which focuses exclusively on making EntityEntry an interface,
> and move things to the right packages and javadoc?
> You'd have a trivial EntitEntryFactory, and we can then build the
> evolution on top of that, not least maybe helping out by challenging
> some points in parallel work.
> These are the things I'd leave for a second iteration:
>  - add various implementations of EntityEntry iteratively, as needed
>  - the strategy such a Factory would use the pick an implementation
>  - ultimately, make it possible for an integrator to override such a
> Factory
>
> For example with Hibernate OGM we might want to override / re
> configure the factories to use custom EntityEntry implementations -
> requirements are not fully clear at this point but it seems likely.
>
> The priority being to define the API as that would be a blocker for
> 5.0, we have then better choices to leave more smarter and advanced
> EntityEntry implementations for the future; we'd still need to
> implement at least the essential ones to make sure the API of the
> EntityEntryFactory has all the context it needs.
>
> Thanks,
> Sanne
>
>
> On 24 March 2015 at 09:27, John O'Hara <johara at redhat.com> wrote:
> > Steve,
> >
> > Have you had chance to look at this? Do you have any
> comments/observations?
> >
> > Thanks
> >
> > John
> >
> >
> > On 17/03/15 09:24, John O'Hara wrote:
> >
> > Steve,
> >
> > I have been having a think about the EntityEntry interface, and have
> forked
> > a branch here:
> >
> > https://github.com/johnaoahra80/hibernate-orm/tree/EntityEntryInterface
> >
> > I know it is nowhere near complete, but was this the sort of idea you
> had in
> > mind?
> >
> > Thanks
> >
> > John
> >
> >
> > On 13/03/15 09:44, John O'Hara wrote:
> >
> > EntityEntry retains a reference to a persistenceContext internally that
> > org.hibernate.engine.spi.EntityEntry#setReadOnly makes calls to, is this
> > where the session reference is kept?  As
> > org.hibernate.engine.spi.PersistenceConext is an interface could we have
> a
> > different implementation for this use case? e.g. an
> > ImmutablePersistenceContext that could be shared across sessions?
> >
> > For the bytecode enhancement, could we change the enhancer so that it
> adds
> > an EntityEntry interface with javassist.
> > ClassPool.javassist.ClassPool.makeInterface()() as opposed to adding a
> class
> > javassist.ClassPool.makeClass()? I need to have a look at javassit to
> > confirm what javassist.ClassPool.makeInterface() does.
> >
> > Thanks
> >
> > John
> >
> > On 12/03/15 18:52, Steve Ebersole wrote:
> >
> > It is possible.  Although some of the changes are particularly painful.
> > Most of EntityEntry, if it is an interface, can be made to work with your
> > use case.  org.hibernate.engine.spi.EntityEntry#setReadOnly I think is
> the
> > one exception, because:
> > 1) your use case needs it
> > 2) it expects the Session to be available internally (its not passed)
> >
> > The bigger thing I am worried about for you is the bytecode stuff, as
> that
> > ties very tightly with EntityEntry.
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Mar 26 12:16:36 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 26 Mar 2015 11:16:36 -0500
Subject: [hibernate-dev] Bytecode enhanced,
	Reference Cached immutable Entities
In-Reply-To: <CAFdSV9sFDr-984gFGGPxnU79u66YPAktonV9wJmfSjfp=Q3F6A@mail.gmail.com>
References: <55003692.9080906@gmail.com>
	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>
	<5502B18F.4050403@redhat.com> <5507F2D4.8040202@redhat.com>
	<55112E1C.5030004@redhat.com>
	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
	<CAFdSV9sFDr-984gFGGPxnU79u66YPAktonV9wJmfSjfp=Q3F6A@mail.gmail.com>
Message-ID: <CAFdSV9tWjGTxq67QRJqXcyZWk1jgasWkdfrf0u=grhOg-JDXvQ@mail.gmail.com>

Apparently I hit some key combo that means send :)  To finish up...

On Thu, Mar 26, 2015 at 10:58 AM, Steve Ebersole <steve at hibernate.org>
wrote:

>
> On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>>
>> Concurrency
>>    Since the goal is to share the ImmutableEntityEntry instance among
>> multiple threads reading it, I'd rather make sure that it is really
>> immutable. For example it now holds onto potentially lazy initialized
>> fields, such as getEntityKey().
>> If it's not possible to make it really immutable (all final fields),
>> we'll need to make it threadsafe and question the name I'm proposing.
>>
>
> The specific use-case John is interested in does indeed need to be
> completely thread-safe and fully concurrent.
>
>
>> LockMode
>>   From a logical perspective of users, one might think that an entity
>> being "immutable" doesn't necessarily imply I can't lock on it..
>> right? I'm not sure how far it could be a valid use case, but these
>> patches are implying that one can't lock an immutable entity anymore,
>> as the lock state would be as immutable as anything else on the
>> EntityEntry.
>> Are we good with that? Alternatively one might need to think to
>> separate the lock state handling from the EntityEntry.
>>
>
> Conceptually there is nothing wrong with requesting a READ lock on an
> immutable entity.  But like you said, what is the logical expectation
> there?  IMO there should be none.  But if we decide that it is OK to req
>

But if we decide that it is OK to request a lock on an immutable entity,
that is problematic for the idea of a "SharedEntityEntry" or an
"ImmutableEntityEntry" because a lock is associated with a Session which is
what the EntityEntry is meant to model... an entity's information in
relation to a Session.  Aka, it now needs to hold state.



> Notice I said immutable here and not READ_ONLY which is a specific
> distinction which is important to other parts of your email that I will
> address in a second email.
>
>
>
>>
>> On smaller details:
>> # org.hibernate.engine.internal.SharedEntityEntry is hosted in an
>> .internal package, I don't think it's right to refactor all the public
>> API javadoc which was referring to EntityEntry to now refer to the
>> internal implementation.
>> # things like EntityEntryExtraState should probably get moved to
>> .internal packages as well now - we couldn't do that before without
>> breaking either encapsulation or APIs.
>>
>
+1


>
>> In terms of git patches, the complexity of the changeset risks to get
>> a bit our of hand. What about we focus on creating a clean pull
>> request which focuses exclusively on making EntityEntry an interface,
>> and move things to the right packages and javadoc?
>>
>
Agree 100%


> You'd have a trivial EntitEntryFactory, and we can then build the
>> evolution on top of that, not least maybe helping out by challenging
>> some points in parallel work.
>> These are the things I'd leave for a second iteration:
>>  - add various implementations of EntityEntry iteratively, as needed
>>  - the strategy such a Factory would use the pick an implementation
>>  - ultimately, make it possible for an integrator to override such a
>> Factory
>>
>
 This all seems reasonable.  For 5.0 I think the most important thing is to
nail down the idea of EntityEntry as an interface, introduce a Factory for
building them and agree on the signature for building them.  Granted we may
need iteration to finalize the actual Factory signature, especially as OGM
finally starts to use it, but I think that in general we can get it pretty
close.  Worst case we just pass high-level constructs like the
EntityPersister (which OGM supplies custom impls) and the Session and all
the "EntityEntry state".  For the purpose of starting a discussion:

public interface EntityEntryFactory {
    public EntityEntry createEntityEntry(
            PersistenceContext persistenceContext,
            EntityPersister persister,
            Status status,
            Serializable id,
            Object version,
            Object[] loadedState,
            Object rowId,
            LockMode lockMode,
            boolean existsInDatabase,
            boolean disableVersionIncrement,
            boolean lazyPropertiesAreUnfetched);
}

I would suggest a "creation context" method param object to pass in here,
but seeing as how we are trying to stop instantiations...

I would prefer the definition of the EntityEntryFactory to use be defined
via SessionFactoryBuilder interface.  I already have plans to have a
auto-loaded hook for integrators to be able to adjust the
SessionFactoryBuilder.  But as a Service is fine too.


>> For example with Hibernate OGM we might want to override / re
>> configure the factories to use custom EntityEntry implementations -
>> requirements are not fully clear at this point but it seems likely.
>>
>> The priority being to define the API as that would be a blocker for
>> 5.0, we have then better choices to leave more smarter and advanced
>> EntityEntry implementations for the future; we'd still need to
>> implement at least the essential ones to make sure the API of the
>> EntityEntryFactory has all the context it needs.
>>
>> Thanks,
>> Sanne
>>
>>
>> On 24 March 2015 at 09:27, John O'Hara <johara at redhat.com> wrote:
>> > Steve,
>> >
>> > Have you had chance to look at this? Do you have any
>> comments/observations?
>> >
>> > Thanks
>> >
>> > John
>> >
>> >
>> > On 17/03/15 09:24, John O'Hara wrote:
>> >
>> > Steve,
>> >
>> > I have been having a think about the EntityEntry interface, and have
>> forked
>> > a branch here:
>> >
>> > https://github.com/johnaoahra80/hibernate-orm/tree/EntityEntryInterface
>> >
>> > I know it is nowhere near complete, but was this the sort of idea you
>> had in
>> > mind?
>> >
>> > Thanks
>> >
>> > John
>> >
>> >
>> > On 13/03/15 09:44, John O'Hara wrote:
>> >
>> > EntityEntry retains a reference to a persistenceContext internally that
>> > org.hibernate.engine.spi.EntityEntry#setReadOnly makes calls to, is this
>> > where the session reference is kept?  As
>> > org.hibernate.engine.spi.PersistenceConext is an interface could we
>> have a
>> > different implementation for this use case? e.g. an
>> > ImmutablePersistenceContext that could be shared across sessions?
>> >
>> > For the bytecode enhancement, could we change the enhancer so that it
>> adds
>> > an EntityEntry interface with javassist.
>> > ClassPool.javassist.ClassPool.makeInterface()() as opposed to adding a
>> class
>> > javassist.ClassPool.makeClass()? I need to have a look at javassit to
>> > confirm what javassist.ClassPool.makeInterface() does.
>> >
>> > Thanks
>> >
>> > John
>> >
>> > On 12/03/15 18:52, Steve Ebersole wrote:
>> >
>> > It is possible.  Although some of the changes are particularly painful.
>> > Most of EntityEntry, if it is an interface, can be made to work with
>> your
>> > use case.  org.hibernate.engine.spi.EntityEntry#setReadOnly I think is
>> the
>> > one exception, because:
>> > 1) your use case needs it
>> > 2) it expects the Session to be available internally (its not passed)
>> >
>> > The bigger thing I am worried about for you is the bytecode stuff, as
>> that
>> > ties very tightly with EntityEntry.
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Thu Mar 26 12:22:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 26 Mar 2015 11:22:41 -0500
Subject: [hibernate-dev] Bytecode enhanced,
	Reference Cached immutable Entities
In-Reply-To: <CAFdSV9tWjGTxq67QRJqXcyZWk1jgasWkdfrf0u=grhOg-JDXvQ@mail.gmail.com>
References: <55003692.9080906@gmail.com>
	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>
	<5502B18F.4050403@redhat.com> <5507F2D4.8040202@redhat.com>
	<55112E1C.5030004@redhat.com>
	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
	<CAFdSV9sFDr-984gFGGPxnU79u66YPAktonV9wJmfSjfp=Q3F6A@mail.gmail.com>
	<CAFdSV9tWjGTxq67QRJqXcyZWk1jgasWkdfrf0u=grhOg-JDXvQ@mail.gmail.com>
Message-ID: <CAFdSV9sXO-BY-nK=eF0p4Fd_aKyQq1DgNMBWWtQO3VJ6SGexjQ@mail.gmail.com>

The contract I suggested btw is missing one use case I know we have
discussed in regards to OGM a few times... the ability to store references
to datastore specific locators (I think the use case was to efficiently
load collections through that datastore reference).  But that (obviously)
requires passing extra, specific state into the createEntityEntry method.
Not really sure the best way to handle such things tbh.

On Thu, Mar 26, 2015 at 11:16 AM, Steve Ebersole <steve at hibernate.org>
wrote:

> Apparently I hit some key combo that means send :)  To finish up...
>
> On Thu, Mar 26, 2015 at 10:58 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>>
>> On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>>
>>>
>>> Concurrency
>>>    Since the goal is to share the ImmutableEntityEntry instance among
>>> multiple threads reading it, I'd rather make sure that it is really
>>> immutable. For example it now holds onto potentially lazy initialized
>>> fields, such as getEntityKey().
>>> If it's not possible to make it really immutable (all final fields),
>>> we'll need to make it threadsafe and question the name I'm proposing.
>>>
>>
>> The specific use-case John is interested in does indeed need to be
>> completely thread-safe and fully concurrent.
>>
>>
>>> LockMode
>>>   From a logical perspective of users, one might think that an entity
>>> being "immutable" doesn't necessarily imply I can't lock on it..
>>> right? I'm not sure how far it could be a valid use case, but these
>>> patches are implying that one can't lock an immutable entity anymore,
>>> as the lock state would be as immutable as anything else on the
>>> EntityEntry.
>>> Are we good with that? Alternatively one might need to think to
>>> separate the lock state handling from the EntityEntry.
>>>
>>
>> Conceptually there is nothing wrong with requesting a READ lock on an
>> immutable entity.  But like you said, what is the logical expectation
>> there?  IMO there should be none.  But if we decide that it is OK to req
>>
>
> But if we decide that it is OK to request a lock on an immutable entity,
> that is problematic for the idea of a "SharedEntityEntry" or an
> "ImmutableEntityEntry" because a lock is associated with a Session which is
> what the EntityEntry is meant to model... an entity's information in
> relation to a Session.  Aka, it now needs to hold state.
>
>
>
>> Notice I said immutable here and not READ_ONLY which is a specific
>> distinction which is important to other parts of your email that I will
>> address in a second email.
>>
>>
>>
>>>
>>> On smaller details:
>>> # org.hibernate.engine.internal.SharedEntityEntry is hosted in an
>>> .internal package, I don't think it's right to refactor all the public
>>> API javadoc which was referring to EntityEntry to now refer to the
>>> internal implementation.
>>> # things like EntityEntryExtraState should probably get moved to
>>> .internal packages as well now - we couldn't do that before without
>>> breaking either encapsulation or APIs.
>>>
>>
> +1
>
>
>>
>>> In terms of git patches, the complexity of the changeset risks to get
>>> a bit our of hand. What about we focus on creating a clean pull
>>> request which focuses exclusively on making EntityEntry an interface,
>>> and move things to the right packages and javadoc?
>>>
>>
> Agree 100%
>
>
>> You'd have a trivial EntitEntryFactory, and we can then build the
>>> evolution on top of that, not least maybe helping out by challenging
>>> some points in parallel work.
>>> These are the things I'd leave for a second iteration:
>>>  - add various implementations of EntityEntry iteratively, as needed
>>>  - the strategy such a Factory would use the pick an implementation
>>>  - ultimately, make it possible for an integrator to override such a
>>> Factory
>>>
>>
>  This all seems reasonable.  For 5.0 I think the most important thing is
> to nail down the idea of EntityEntry as an interface, introduce a Factory
> for building them and agree on the signature for building them.  Granted we
> may need iteration to finalize the actual Factory signature, especially as
> OGM finally starts to use it, but I think that in general we can get it
> pretty close.  Worst case we just pass high-level constructs like the
> EntityPersister (which OGM supplies custom impls) and the Session and all
> the "EntityEntry state".  For the purpose of starting a discussion:
>
> public interface EntityEntryFactory {
>     public EntityEntry createEntityEntry(
>             PersistenceContext persistenceContext,
>             EntityPersister persister,
>             Status status,
>             Serializable id,
>             Object version,
>             Object[] loadedState,
>             Object rowId,
>             LockMode lockMode,
>             boolean existsInDatabase,
>             boolean disableVersionIncrement,
>             boolean lazyPropertiesAreUnfetched);
> }
>
> I would suggest a "creation context" method param object to pass in here,
> but seeing as how we are trying to stop instantiations...
>
> I would prefer the definition of the EntityEntryFactory to use be defined
> via SessionFactoryBuilder interface.  I already have plans to have a
> auto-loaded hook for integrators to be able to adjust the
> SessionFactoryBuilder.  But as a Service is fine too.
>
>
>>> For example with Hibernate OGM we might want to override / re
>>> configure the factories to use custom EntityEntry implementations -
>>> requirements are not fully clear at this point but it seems likely.
>>>
>>> The priority being to define the API as that would be a blocker for
>>> 5.0, we have then better choices to leave more smarter and advanced
>>> EntityEntry implementations for the future; we'd still need to
>>> implement at least the essential ones to make sure the API of the
>>> EntityEntryFactory has all the context it needs.
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>> On 24 March 2015 at 09:27, John O'Hara <johara at redhat.com> wrote:
>>> > Steve,
>>> >
>>> > Have you had chance to look at this? Do you have any
>>> comments/observations?
>>> >
>>> > Thanks
>>> >
>>> > John
>>> >
>>> >
>>> > On 17/03/15 09:24, John O'Hara wrote:
>>> >
>>> > Steve,
>>> >
>>> > I have been having a think about the EntityEntry interface, and have
>>> forked
>>> > a branch here:
>>> >
>>> >
>>> https://github.com/johnaoahra80/hibernate-orm/tree/EntityEntryInterface
>>> >
>>> > I know it is nowhere near complete, but was this the sort of idea you
>>> had in
>>> > mind?
>>> >
>>> > Thanks
>>> >
>>> > John
>>> >
>>> >
>>> > On 13/03/15 09:44, John O'Hara wrote:
>>> >
>>> > EntityEntry retains a reference to a persistenceContext internally that
>>> > org.hibernate.engine.spi.EntityEntry#setReadOnly makes calls to, is
>>> this
>>> > where the session reference is kept?  As
>>> > org.hibernate.engine.spi.PersistenceConext is an interface could we
>>> have a
>>> > different implementation for this use case? e.g. an
>>> > ImmutablePersistenceContext that could be shared across sessions?
>>> >
>>> > For the bytecode enhancement, could we change the enhancer so that it
>>> adds
>>> > an EntityEntry interface with javassist.
>>> > ClassPool.javassist.ClassPool.makeInterface()() as opposed to adding a
>>> class
>>> > javassist.ClassPool.makeClass()? I need to have a look at javassit to
>>> > confirm what javassist.ClassPool.makeInterface() does.
>>> >
>>> > Thanks
>>> >
>>> > John
>>> >
>>> > On 12/03/15 18:52, Steve Ebersole wrote:
>>> >
>>> > It is possible.  Although some of the changes are particularly painful.
>>> > Most of EntityEntry, if it is an interface, can be made to work with
>>> your
>>> > use case.  org.hibernate.engine.spi.EntityEntry#setReadOnly I think is
>>> the
>>> > one exception, because:
>>> > 1) your use case needs it
>>> > 2) it expects the Session to be available internally (its not passed)
>>> >
>>> > The bigger thing I am worried about for you is the bytecode stuff, as
>>> that
>>> > ties very tightly with EntityEntry.
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From steve at hibernate.org  Thu Mar 26 12:35:24 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 26 Mar 2015 11:35:24 -0500
Subject: [hibernate-dev] Bytecode enhanced,
	Reference Cached immutable Entities
In-Reply-To: <CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
References: <55003692.9080906@gmail.com>
	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>
	<5502B18F.4050403@redhat.com> <5507F2D4.8040202@redhat.com>
	<55112E1C.5030004@redhat.com>
	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
Message-ID: <CAFdSV9sETemfPvEReWArmx4_=Asb12a-fGotkaAAc1JN8drydQ@mail.gmail.com>

Now the "meat"...

On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:
>
>
> What is your primary differentiator between 'SharedEntityEntry' and
> 'StatefulEntityEntry' ?
> For our purposes I'd have used different names, but since there's no
> javadoc yet I wonder if you had different intentions.
>

> Personally I'd have chosen something like "ImmutableEntityEntry" and
> "MutableEntityEntry", there the Mutable one is a rename of the
> existing implementation, and the Immutable would be a slimmed down
> version which might not need fields such as:
>  - loadedState (not needed for readonly)
>  - version (what would be the point)
>  - ..
>
>
Well I cannot speak for John's reasoning, but knowing his use case I think
that what you describe is exactly his intent with the split.
SharedEntityEntry represents an EntityEntry that is immutable and needs to
be because it is *shared* between Sessions.  I personally prefer the names
mutable and immutable as well.  The docs for ImmutableEntityEntry should
make it clear that it is shared between Sessions and that concurrency is
the reason it is immutable.



> A concern I have is to avoid ever needing to "promote" an
> ImmutableEntityEntry into a MutableEntityEntry: it's easy to mark an
> existing instance of ImmutableEntityEntry as READ_ONLY, but there is
> no going back if the entity entry was initially loaded as READ_ONLY.
> One could think of swapping the existing entityentry, but that could
> get hairy and defeats the point of optimising object allocations.
>
> Is there a strong guarantee which we can rely on, that if an
> EntityEntry is marked READ_ONLY at first load, noone will ever need to
> re-mark it as mutable?
> If not, the current check in DefaultEntityEntryFactory basing the
> choice on the current status of the Entity might not be enough, we
> might need to be a bit more conservative and only based that on
> getPersister().isMutable() ?
>

So there is a distinction here between an immutable entity
(EntityPersister#isMutable == false) and a entity loaded as read-only
specific to a Session.  The first kind can *never* become non-read-only.
The second kind can.  The first kind should be the only case where we use
ImmutableEntityEntry, because in the second case that entity can later
become mutable and as you say we would then need to "promote" its
corresponding ImmutableEntityEntry to a MutableEntityEntry (even more
instantiations!).

From steve at hibernate.org  Thu Mar 26 12:47:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 26 Mar 2015 11:47:20 -0500
Subject: [hibernate-dev] Date/Time Support and timezones
In-Reply-To: <CAFm4XO2-H8MFPkSRecSqF=AKMC_+BLjnb6CgRHfE8s=xAZ1n7g@mail.gmail.com>
References: <CAFdSV9sbcwkyRJ7oNN8PX=LFUyhrOZVdn7UDoH7ATENRk6h0sQ@mail.gmail.com>
	<20150323210110.GC16871@Nineveh.lan>
	<CAFdSV9u-M0R9Q5oWuUXgGYbnNh2djDk4QA1Uz=EQQ7EPC4JSDw@mail.gmail.com>
	<CADGJaX9keAf=UKreLyoN+MLPhnRqrzRXv0LR6LVu_0zdKu6+ag@mail.gmail.com>
	<CAFm4XO2-H8MFPkSRecSqF=AKMC_+BLjnb6CgRHfE8s=xAZ1n7g@mail.gmail.com>
Message-ID: <CAFdSV9t9UxOyqbVMZKotsfFRx4NG4dm7HMJaZi8_4En=H7mtkg@mail.gmail.com>

The real difficulty with (3) is querying.  How do you restrict a query on a
(TIMESTAMP,TZ) tuple for example when the individual values could be in
multiple timezones?  Andrea and I were just discussing the same in regards
to Java 9(?) Money/Currency support.

Personally I think this idea of trying to store and handle dates in
different timezones is silly, and more importantly that it is asking for
trouble.  IMO I think all dates and times should be treat as UTC, stored
and handled as such and only ever converted to a specific TZ when rendering
(UI, etc).

The other difficulty is how to know that the db type is "WITH TIMEZONE" or
not.  Because that effects how we need to pass things and retrieve them to
be consistent.  If you always handle temporals in UTC in the app and tell
the JDBC driver to use UTC for read/write (or set default JVM TZ to UTC)
then things JustWork.  I will say that JSR 310 is much better in terms of
being able to normalize temporals.  So maybe we should leverage that.


On Thu, Mar 26, 2015 at 10:44 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Forcing 3 is correct but rarely desirable, I'm afraid the user should
> choose.
>
> But most people will not like the additional
> space/performance/complexity hit, and will use a single timezone.
>
> If you think we should force people into a correct choice, you'd
> require 3# unless they are willing to set a global timezone
> configuration property, or maybe even a per-property timezone on the
> mapping, in which case you'd go for 2(4) but having them choose the
> poison.
>
> On 24 March 2015 at 12:30, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 3) seems most desirable to me, too.
> >
> > What type would your "TZ" column have? Just a numeric offset? Or a
> VARCHAR,
> > also capable of storing textual TZ representations such as "+01:00
> > Europe/Paris"? I think the latter would be needed to make it fully
> > reflexive for ZonedDateTime.
> >
> > Another variant of 3) could be to leverage DB-specific types such as
> > TIMESTAMP WITH TIME ZONE on Oracle. I could imagine that'd be what users
> of
> > databases supporting such a type might want.
> >
> > --Gunnar
> >
> >
> > 2015-03-24 3:00 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >
> >> Not in the same Type.  But of course "Type swapping" is so easy
> nowadays...
> >>
> >> On Mon, Mar 23, 2015 at 4:01 PM, Hardy Ferentschik <hardy at hibernate.org
> >
> >> wrote:
> >>
> >> > > A few options:
> >> > >
> >> > > 1) Forego OffsetDateTime, OffsetTime and ZonedDateTime support and
> just
> >> > > stick with LocalDateTime, LocalDate and LocalTime.
> >> > > 2) Use the timezone/offset to pass along to the driver (for proper
> >> > > conversion); when reading back we'd have to read back based on the
> >> > default
> >> > > timezone.  This is essentially the old strategy used in CalendarType
> >> > which
> >> > > I never really liked because its not reflexive.
> >> > > 3) Break them into a tuple of the store each piece.  E.g., for
> >> > > OffsetDateTime the Tuple is a LocalDateTime (the Timestamp) and a TZ
> >> > > offset.  So we'd store each individually in the database and be
> able to
> >> > > rebuild them in a fully reflexive manner.
> >> > > 4) Handle them using UTC or GMT at the JDBC level.  This is
> essentially
> >> > the
> >> > > same as (2)
> >> >
> >> > Personally, I think I'd prefer #3. I am not sure whether all users
> would
> >> > be happy
> >> > with two columns for a OffsetDateTime. Could we support multiple
> options,
> >> > for example
> >> > #3 and #4 and make it configurable?
> >> >
> >> > --Hardy
> >> >
> >> _______________________________________________
> >> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Thu Mar 26 14:10:00 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 26 Mar 2015 19:10:00 +0100
Subject: [hibernate-dev] SessionFactory building APIs
In-Reply-To: <CAFdSV9scBJ1QNtjv9tF3nGJUXJTOmCHMxf9n-5-eQOv4fm9Y0w@mail.gmail.com>
References: <CAFdSV9sybc8=k+-S7SiQsC0RMaxCFtAsHfGbFfNJbb=GtScFuw@mail.gmail.com>
	<CADGJaX_+mPnzP6gThinXNJZJVPmXA41au8HLxrh=O2NV8-umCA@mail.gmail.com>
	<CAFdSV9tPF8smQfUNaKa3Yr6n7YbOKRhG5Da2JNhEWTG-J-LqZw@mail.gmail.com>
	<CAFdSV9uKJr_kpJLa63r0fL5KQ7D1NZcx2w+7Ci_uPKQbOyizcg@mail.gmail.com>
	<CADGJaX8r+vy-SUo5gG3v1mDOC72ExC_P0tOWB-Kyd-+jHxBm9w@mail.gmail.com>
	<CAFdSV9scBJ1QNtjv9tF3nGJUXJTOmCHMxf9n-5-eQOv4fm9Y0w@mail.gmail.com>
Message-ID: <CADGJaX8ar8KW6=_RR-0hGBzyQ=4xVXNh=z3gJydFKVKckwr30Q@mail.gmail.com>

2015-03-26 15:56 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> I'm not so convinced that we need this additional level of instantiation
> just to avoid exposing access to the collected sources (getters).
>

Few things are strictly needed in the end :)

IMO limiting the exposed API as much as possible is a good thing, as it a)
reduces complexity on the user (the lesser methods there are, the quicker
they find the ones to deal with) and b) gives you more freedom to alter
things down the road if needed.


> Anyone else have opinions on this?
>

+1 Would like to know that as well :)

On Thu, Mar 26, 2015 at 3:35 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> 2015-03-26 3:56 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> On second thought...
>>>
>>> MetadataBuilder is also an interface (unless you are suggesting to
>>> change that for some reason), so not sure how a call like this would work:
>>>
>>> MetadataBuilder.defineSources()
>>>
>>
>> Ah, I forgot you cannot rely on Java 8 yet ;)
>>
>> So a static method somewhere else would be needed indeed, maybe something
>> like:
>>
>>     Bootstrap.configureMetadataBuilderSources()
>>         .addFile(...)
>>         .getMetadataBuilder();
>>
>> On Wed, Mar 25, 2015 at 6:21 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> On Wed, Mar 25, 2015 at 4:57 PM, Gunnar Morling <gunnar at hibernate.org>
>>>> wrote:
>>>>
>>>>> > 1) What do you think of the split in MetadataSources and
>>>>> MetadataBuilder?
>>>>> > Does the aplit make sense?  Or does it make more sense to combine
>>>>> them into
>>>>> > one contract?
>>>>>
>>>>> I think the split makes sense, as I understand that there are two
>>>>> different "phases" of configuration here:
>>>>>
>>>>> * add multiple sources of configuration (XML files, annotated classes)
>>>>> * apply further configuration (naming strategy etc.)
>>>>>
>>>>
>>>>> Assuming one first needs to configure all the sources before applying
>>>>> the configuration from the second category, it seems useful to express that
>>>>> in the API.
>>>>>
>>>>
>>>> MetadataSources is used to collect the sources of mapping
>>>> information.  However, its really not necessary that the split exists in
>>>> terms of "this needs to be set before that".  Its more a functional split
>>>> because they each serve different roles.  One collects the sources of
>>>> metadata information.  One builds that into a Metadata object (based on
>>>> some config).
>>>>
>>>>
>>>>
>>>>>
>>>>> The name "MetadataSources" made me stumble a bit, though. Generally I
>>>>> find pluralized class names a bit odd, only really useful for either
>>>>> collection-like classes or static helper classes dealing with a specific
>>>>> type (e.g. Strings, Collections). What would you think about
>>>>> MetadataSources not being a top-level class itself, but rather an inner
>>>>> class of MetadataBuilder (e.g. named MetadataBuilderContext) which is
>>>>> returned by a static creator method on MetadataBuilder:
>>>>>
>>>>> MetadataBuilder builder = MetadataBuilder.configure() // returns
>>>>> MetadataBuilderContext
>>>>>     .addFile(...)
>>>>>     .addAnnotatedClass(...)
>>>>>     .addResource(...)
>>>>>     .getBuilder();
>>>>>
>>>>> IMO that would help users a bit to find the right entry point.
>>>>>
>>>>
>>>> Not sure about the naming.  I think MetadataSources is much better than MetadataBuilderContext.
>>>> That's my take.  We can see what others think.
>>>>
>>>> As far as the API, I am ok with changing that up if others agree.  I
>>>> could see something like:
>>>>
>>>> MetadataBuilder.defineSources()
>>>>     .addFile(...)
>>>>     .addAnnotatedClass(...)
>>>>     .addResource(...)
>>>>     .getBuilder();
>>>>
>>>> defineSources (or whatever we call it) needs to be overloaded to be
>>>> able to accept a ServiceRegistry:
>>>>
>>>> MetadataBuilder.defineSources()
>>>>
>>>> versus:
>>>>
>>>> MetadataBuilder.defineSources( new
>>>> StandardServiceRegistryBuilder()...build() )
>>>>
>>>>
>>>>
>>>>
>>>>> Some more questions/thoughts:
>>>>>
>>>>> * Who is the intended client for the getter methods on MetadataSources?
>>>>> Only ORM, or also user code? In case of the former, should the public MetadataSources
>>>>> contract be an interface with the addXy() methods only, whereas getters are
>>>>> only accessible via an internal implementation class? That would narrow
>>>>> down the exposed API.
>>>>>
>>>>
>>>> Yes, the intended usage is just Hibernate itself.  However, the
>>>> exposure is just a natural follow on of the design that MetadataSources is
>>>> a class that one instantiates directly.  Can't instantiate an interface of
>>>> course.  An approach such as above addresses that.
>>>>
>>>>
>>>>> * Are MetadataSources#addAttributeConverter(),
>>>>> addAuxiliaryDatabaseObject() and addSqlFunction() adding a *source* for
>>>>> meta-data really? Somehow it seems they should rather be located on
>>>>> MetadataBuilder?
>>>>>
>>>>
>>>> From one perspective yes.  Not *sources* per-se, but they are things
>>>> that the user supplies that become part of the Metadata; as opposed to
>>>> simply options that are used during the process of building a Metadata
>>>> (MetadataBuilder).  And especially since you want to rename "sources" to
>>>> "building context"; imo that makes the argument that these belong here even
>>>> stronger.
>>>>
>>>>
>>>>
>>>>> * I don't think MetadataSources is intended for concurrent usage from
>>>>> several threads, right? If so, it should not be needed to have a
>>>>> ConcurrentHashMap as a member
>>>>>
>>>>
>>>> True.  Not sure why it stores those in ConcurrentHashMap...
>>>>
>>>>
>>>>
>>>>> * MetadataSources#addInputStream() et al.: What schema have passed
>>>>> streams to adhere to? Are these orm.xml, hbm.xml or both? Would be nice to
>>>>> have this documented
>>>>>
>>>>
>>>> Well same is true of addResources, addFile, add..  I get what you are
>>>> saying, but why do you single out addInputStream here?  To be honest, I
>>>> would personally love to get rid of addInputStream.  I think
>>>> addInputStreamAccess(InputStreamAccess) is a MUCH better solution there.
>>>>
>>>>
>>>>
>>>>> * MetadataBuilder#setSourceProcessOrdering: May be a bit nicer to use
>>>>> if modelled with var-args:
>>>>>
>>>>>     sourceTypeProcessingOrder(MetadataSourceType first,
>>>>> MetadataSourceType... others) -> used like sourceTypeProcessingOrder(
>>>>> CLASS, HBM );
>>>>>
>>>>
>>>>
>>>> +1
>>>>
>>>>
>>>
>>
>

From johara at redhat.com  Fri Mar 27 06:32:17 2015
From: johara at redhat.com (John O'Hara)
Date: Fri, 27 Mar 2015 10:32:17 +0000
Subject: [hibernate-dev] Bytecode enhanced,
	Reference Cached immutable Entities
In-Reply-To: <CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
References: <55003692.9080906@gmail.com>
	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>
	<5502B18F.4050403@redhat.com> <5507F2D4.8040202@redhat.com>
	<55112E1C.5030004@redhat.com>
	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
Message-ID: <551531B1.40806@redhat.com>

On 26/03/15 15:20, Sanne Grinovero wrote:
> [adding the mailing list]
>
> Generally speaking, looks like we agree on the direction: EntityEntry
> needs to be an interface, and some clever logic to select the
> appropriate implementations.
> In your draft you're having a single EntityEntryFactory as a global
> service; I'm wondering if we shouldn't have the possibiliy to have a
> different factory implementation per Entry type.. more on this below.
The thought process behind having a central factory was to have a single 
place to make the determination which EntityEntry implementation to 
instantiate.

I can see your point below, it would mean that we would have to make the 
determination as to which factory to use somewhere else in the code base.
>
> What is your primary differentiator between 'SharedEntityEntry' and
> 'StatefulEntityEntry' ?
> For our purposes I'd have used different names, but since there's no
> javadoc yet I wonder if you had different intentions.
>
> Personally I'd have chosen something like "" and
> "MutableEntityEntry", there the Mutable one is a rename of the
> existing implementation, and the Immutable would be a slimmed down
> version which might not need fields such as:
>   - loadedState (not needed for readonly)
>   - version (what would be the point)
>   - ..
Initially, I was thinking shared between sessions, and a EntityEntry 
that contained a mutable state, but I agree that "ImmutableEntityEntry" 
and "MutableEntityEntry" make more logical sense. Had not considered 
what properties could be removed in the ImmutableEntityEntry 
implementation, but will take a detailed look at what could be removed 
for that use case.
>
> A concern I have is to avoid ever needing to "promote" an
> ImmutableEntityEntry into a MutableEntityEntry: it's easy to mark an
> existing instance of ImmutableEntityEntry as READ_ONLY, but there is
> no going back if the entity entry was initially loaded as READ_ONLY.
> One could think of swapping the existing entityentry, but that could
> get hairy and defeats the point of optimising object allocations.
AFAIK there shouldn't be any need to promote an ImmutableEntityEntry to 
a MutableEntityEntry, we should know when the Entity is loaded that it 
is Immutable and I can not think why that would change during the 
lifetime of a session.
>
> Is there a strong guarantee which we can rely on, that if an
> EntityEntry is marked READ_ONLY at first load, noone will ever need to
> re-mark it as mutable?
> If not, the current check in DefaultEntityEntryFactory basing the
> choice on the current status of the Entity might not be enough, we
> might need to be a bit more conservative and only based that on
> getPersister().isMutable() ?
This was an area that I was unsure as to what the best property(s) to 
test were for mutability. I can see now that checking if the Entity was 
loaded READ_ONLY might not be appropriate as the Entity might be mutable.
>
> The READ_ONLY point which you're leveraging for this specific
> optimisation seems to be key for the specific optimisation we have in
> mind at this point; but generalizing the concept it seems to me that
> the choice of EE implementation to use for a specific Entity type will
> be a consistent choice for the lifecycle of the EntityPersister, and
> depending on immutable flags on the EntityPersister. Which is why I'm
> suggesting that the EntityPersister should have a dedicated
> EntityEntryFactory.
I am unsure of the relationship between EntityPersister, EntityEntry and 
a Session. Are you proposing that you determine the implementation of 
EntityEntry and cache a reference in EntityPersister so that we can 
re-use across sessions?
Would we need some type checking to ensure that the EntryEntity 
implementation is correct for each creation of EntityEntry, and throw 
something like a InvalidEntityEntryException if the EntityEntry we are 
creating is not appropriate? As I said, I am not sure of the 
relationships so do not know what assumptions can be made around this.
> Making the EntityEntryFactory a global service
> would force to go through all the checks of the EE implementation
> choice each time, while the choice should always be the same. I
> wouldn't argue to save a couple of simple "if" evaluations, but it's
> very possible that some more clever EntityEntryFactory implementations
> than this current draft might need to do more work, for example
> consult more Services to call back into OGM metadata.
> Not least, having a per-type EntityEntryFactory would make it possible
> to refer to it from some EntityEntry implementations and save some
> memory around the common state.
>
> Concurrency
>     Since the goal is to share the ImmutableEntityEntry instance among
> multiple threads reading it, I'd rather make sure that it is really
> immutable. For example it now holds onto potentially lazy initialized
> fields, such as getEntityKey().
> If it's not possible to make it really immutable (all final fields),
> we'll need to make it threadsafe and question the name I'm proposing.
+1 had not considered this in my draft. will ensure that the 
ImmutableEntityEntry is threadsafe.
>
> LockMode
>    From a logical perspective of users, one might think that an entity
> being "immutable" doesn't necessarily imply I can't lock on it..
> right? I'm not sure how far it could be a valid use case, but these
> patches are implying that one can't lock an immutable entity anymore,
> as the lock state would be as immutable as anything else on the
> EntityEntry.
> Are we good with that? Alternatively one might need to think to
> separate the lock state handling from the EntityEntry.
I have not considered LockMode, not sure of the implications of LockMode 
and what impact it might have. Any guidance here would be greatly 
appreciated.
>
> On smaller details:
> # org.hibernate.engine.internal.SharedEntityEntry is hosted in an
> .internal package, I don't think it's right to refactor all the public
> API javadoc which was referring to EntityEntry to now refer to the
> internal implementation.
> # things like EntityEntryExtraState should probably get moved to
> .internal packages as well now - we couldn't do that before without
> breaking either encapsulation or APIs.
An oversight on my part, will move the javadoc back to the public api, I 
will move EntityEntryExtraState to different package
> In terms of git patches, the complexity of the changeset risks to get
> a bit our of hand. What about we focus on creating a clean pull
> request which focuses exclusively on making EntityEntry an interface,
> and move things to the right packages and javadoc?
+1
> You'd have a trivial EntitEntryFactory, and we can then build the
> evolution on top of that, not least maybe helping out by challenging
> some points in parallel work.
> These are the things I'd leave for a second iteration:
>   - add various implementations of EntityEntry iteratively, as needed
>   - the strategy such a Factory would use the pick an implementation
>   - ultimately, make it possible for an integrator to override such a Factory
>
> For example with Hibernate OGM we might want to override / re
> configure the factories to use custom EntityEntry implementations -
> requirements are not fully clear at this point but it seems likely.
>
> The priority being to define the API as that would be a blocker for
> 5.0, we have then better choices to leave more smarter and advanced
> EntityEntry implementations for the future; we'd still need to
> implement at least the essential ones to make sure the API of the
> EntityEntryFactory has all the context it needs.
Do we need to think about the different use cases (default, immutable 
reference cached, ORM) to define a generic API that fits all?
>
> Thanks,
> Sanne
>
>
> On 24 March 2015 at 09:27, John O'Hara <johara at redhat.com> wrote:
>> Steve,
>>
>> Have you had chance to look at this? Do you have any comments/observations?
>>
>> Thanks
>>
>> John
>>
>>
>> On 17/03/15 09:24, John O'Hara wrote:
>>
>> Steve,
>>
>> I have been having a think about the EntityEntry interface, and have forked
>> a branch here:
>>
>> https://github.com/johnaoahra80/hibernate-orm/tree/EntityEntryInterface
>>
>> I know it is nowhere near complete, but was this the sort of idea you had in
>> mind?
>>
>> Thanks
>>
>> John
>>
>>
>> On 13/03/15 09:44, John O'Hara wrote:
>>
>> EntityEntry retains a reference to a persistenceContext internally that
>> org.hibernate.engine.spi.EntityEntry#setReadOnly makes calls to, is this
>> where the session reference is kept?  As
>> org.hibernate.engine.spi.PersistenceConext is an interface could we have a
>> different implementation for this use case? e.g. an
>> ImmutablePersistenceContext that could be shared across sessions?
>>
>> For the bytecode enhancement, could we change the enhancer so that it adds
>> an EntityEntry interface with javassist.
>> ClassPool.javassist.ClassPool.makeInterface()() as opposed to adding a class
>> javassist.ClassPool.makeClass()? I need to have a look at javassit to
>> confirm what javassist.ClassPool.makeInterface() does.
>>
>> Thanks
>>
>> John
>>
>> On 12/03/15 18:52, Steve Ebersole wrote:
>>
>> It is possible.  Although some of the changes are particularly painful.
>> Most of EntityEntry, if it is an interface, can be made to work with your
>> use case.  org.hibernate.engine.spi.EntityEntry#setReadOnly I think is the
>> one exception, because:
>> 1) your use case needs it
>> 2) it expects the Session to be available internally (its not passed)
>>
>> The bigger thing I am worried about for you is the bytecode stuff, as that
>> ties very tightly with EntityEntry.
>>


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).


From johara at redhat.com  Fri Mar 27 06:58:59 2015
From: johara at redhat.com (John O'Hara)
Date: Fri, 27 Mar 2015 10:58:59 +0000
Subject: [hibernate-dev] Bytecode enhanced,
 Reference Cached immutable Entities
In-Reply-To: <CAFdSV9sETemfPvEReWArmx4_=Asb12a-fGotkaAAc1JN8drydQ@mail.gmail.com>
References: <55003692.9080906@gmail.com>	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>	<5502B18F.4050403@redhat.com>	<5507F2D4.8040202@redhat.com>	<55112E1C.5030004@redhat.com>	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
	<CAFdSV9sETemfPvEReWArmx4_=Asb12a-fGotkaAAc1JN8drydQ@mail.gmail.com>
Message-ID: <551537F3.80902@redhat.com>

On 26/03/15 16:35, Steve Ebersole wrote:
> Now the "meat"...
>
> On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <sanne at hibernate.org 
> <mailto:sanne at hibernate.org>> wrote:
>
>
>     What is your primary differentiator between 'SharedEntityEntry' and
>     'StatefulEntityEntry' ?
>     For our purposes I'd have used different names, but since there's no
>     javadoc yet I wonder if you had different intentions.
>
>
>     Personally I'd have chosen something like "ImmutableEntityEntry" and
>     "MutableEntityEntry", there the Mutable one is a rename of the
>     existing implementation, and the Immutable would be a slimmed down
>     version which might not need fields such as:
>      - loadedState (not needed for readonly)
>      - version (what would be the point)
>      - ..
>
>
> Well I cannot speak for John's reasoning, but knowing his use case I 
> think that what you describe is exactly his intent with the split.  
> SharedEntityEntry represents an EntityEntry that is immutable and 
> needs to be because it is *shared* between Sessions.  I personally 
> prefer the names mutable and immutable as well.  The docs for 
> ImmutableEntityEntry should make it clear that it is shared between 
> Sessions and that concurrency is the reason it is immutable.
>
That was my reasoning, but on retrospect, I agree with the 
ImmutableEntityEntry and MutableEntityEntry names
>
>     A concern I have is to avoid ever needing to "promote" an
>     ImmutableEntityEntry into a MutableEntityEntry: it's easy to mark an
>     existing instance of ImmutableEntityEntry as READ_ONLY, but there is
>     no going back if the entity entry was initially loaded as READ_ONLY.
>     One could think of swapping the existing entityentry, but that could
>     get hairy and defeats the point of optimising object allocations.
>
>     Is there a strong guarantee which we can rely on, that if an
>     EntityEntry is marked READ_ONLY at first load, noone will ever need to
>     re-mark it as mutable?
>     If not, the current check in DefaultEntityEntryFactory basing the
>     choice on the current status of the Entity might not be enough, we
>     might need to be a bit more conservative and only based that on
>     getPersister().isMutable() ?
>
>
> So there is a distinction here between an immutable entity 
> (EntityPersister#isMutable == false) and a entity loaded as read-only 
> specific to a Session.  The first kind can *never* become 
> non-read-only.  The second kind can. The first kind should be the only 
> case where we use ImmutableEntityEntry, because in the second case 
> that entity can later become mutable and as you say we would then need 
> to "promote" its corresponding ImmutableEntityEntry to a 
> MutableEntityEntry (even more instantiations!).
I was unsure what the best property to test was, I will change to test 
on getPersister().isMutable()

Thanks

john


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).


From johara at redhat.com  Fri Mar 27 07:04:16 2015
From: johara at redhat.com (John O'Hara)
Date: Fri, 27 Mar 2015 11:04:16 +0000
Subject: [hibernate-dev] Bytecode enhanced,
 Reference Cached immutable Entities
In-Reply-To: <CAFdSV9sXO-BY-nK=eF0p4Fd_aKyQq1DgNMBWWtQO3VJ6SGexjQ@mail.gmail.com>
References: <55003692.9080906@gmail.com>	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>	<5502B18F.4050403@redhat.com>	<5507F2D4.8040202@redhat.com>	<55112E1C.5030004@redhat.com>	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>	<CAFdSV9sFDr-984gFGGPxnU79u66YPAktonV9wJmfSjfp=Q3F6A@mail.gmail.com>	<CAFdSV9tWjGTxq67QRJqXcyZWk1jgasWkdfrf0u=grhOg-JDXvQ@mail.gmail.com>
	<CAFdSV9sXO-BY-nK=eF0p4Fd_aKyQq1DgNMBWWtQO3VJ6SGexjQ@mail.gmail.com>
Message-ID: <55153930.9070200@redhat.com>

On 26/03/15 16:22, Steve Ebersole wrote:
> The contract I suggested btw is missing one use case I know we have 
> discussed in regards to OGM a few times... the ability to store 
> references to datastore specific locators (I think the use case was to 
> efficiently load collections through that datastore reference).  But 
> that (obviously) requires passing extra, specific state into 
> the createEntityEntry method.  Not really sure the best way to handle 
> such things tbh.
>
If we did have a "creation Context" parameter passed to the 
createEntityEntry, we would be instantiating more objects, however if we 
went with Sanne' suggestion if caching the EnityEntryFactory with the 
EntityPersister, how many objects would be actually created?  I am not 
sure about the relationship between Entity, EntityEntry and Session but 
could this a possibility if there is a 1-1 relationship between 
EntityPersister and no. of different Entities definitions?

> On Thu, Mar 26, 2015 at 11:16 AM, Steve Ebersole <steve at hibernate.org 
> <mailto:steve at hibernate.org>> wrote:
>
>     Apparently I hit some key combo that means send :)  To finish up...
>
>     On Thu, Mar 26, 2015 at 10:58 AM, Steve Ebersole
>     <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>
>
>         On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero
>         <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
>
>
>             Concurrency
>                Since the goal is to share the ImmutableEntityEntry
>             instance among
>             multiple threads reading it, I'd rather make sure that it
>             is really
>             immutable. For example it now holds onto potentially lazy
>             initialized
>             fields, such as getEntityKey().
>             If it's not possible to make it really immutable (all
>             final fields),
>             we'll need to make it threadsafe and question the name I'm
>             proposing.
>
>
>         The specific use-case John is interested in does indeed need
>         to be completely thread-safe and fully concurrent.
>
>
>             LockMode
>               From a logical perspective of users, one might think
>             that an entity
>             being "immutable" doesn't necessarily imply I can't lock
>             on it..
>             right? I'm not sure how far it could be a valid use case,
>             but these
>             patches are implying that one can't lock an immutable
>             entity anymore,
>             as the lock state would be as immutable as anything else
>             on the
>             EntityEntry.
>             Are we good with that? Alternatively one might need to
>             think to
>             separate the lock state handling from the EntityEntry.
>
>
>         Conceptually there is nothing wrong with requesting a READ
>         lock on an immutable entity.  But like you said, what is the
>         logical expectation there?  IMO there should be none.  But if
>         we decide that it is OK to req
>
>     But if we decide that it is OK to request a lock on an immutable
>     entity, that is problematic for the idea of a "SharedEntityEntry"
>     or an "ImmutableEntityEntry" because a lock is associated with a
>     Session which is what the EntityEntry is meant to model... an
>     entity's information in relation to a Session.  Aka, it now needs
>     to hold state.
>
>
>
>         Notice I said immutable here and not READ_ONLY which is a
>         specific distinction which is important to other parts of your
>         email that I will address in a second email.
>
>
>             On smaller details:
>             # org.hibernate.engine.internal.SharedEntityEntry is
>             hosted in an
>             .internal package, I don't think it's right to refactor
>             all the public
>             API javadoc which was referring to EntityEntry to now
>             refer to the
>             internal implementation.
>             # things like EntityEntryExtraState should probably get
>             moved to
>             .internal packages as well now - we couldn't do that
>             before without
>             breaking either encapsulation or APIs.
>
>
>     +1
>
>
>             In terms of git patches, the complexity of the changeset
>             risks to get
>             a bit our of hand. What about we focus on creating a clean
>             pull
>             request which focuses exclusively on making EntityEntry an
>             interface,
>             and move things to the right packages and javadoc?
>
>
>     Agree 100%
>
>             You'd have a trivial EntitEntryFactory, and we can then
>             build the
>             evolution on top of that, not least maybe helping out by
>             challenging
>             some points in parallel work.
>             These are the things I'd leave for a second iteration:
>              - add various implementations of EntityEntry iteratively,
>             as needed
>              - the strategy such a Factory would use the pick an
>             implementation
>              - ultimately, make it possible for an integrator to
>             override such a Factory
>
>
>      This all seems reasonable.  For 5.0 I think the most important
>     thing is to nail down the idea of EntityEntry as an interface,
>     introduce a Factory for building them and agree on the signature
>     for building them.  Granted we may need iteration to finalize the
>     actual Factory signature, especially as OGM finally starts to use
>     it, but I think that in general we can get it pretty close.  Worst
>     case we just pass high-level constructs like the EntityPersister
>     (which OGM supplies custom impls) and the Session and all the
>     "EntityEntry state". For the purpose of starting a discussion:
>
>     public interface EntityEntryFactory {
>         public EntityEntry createEntityEntry(
>               PersistenceContext persistenceContext,
>         EntityPersister persister,
>         Status status,
>         Serializable id,
>         Object version,
>                 Object[] loadedState,
>                 Object rowId,
>                 LockMode lockMode,
>                 boolean existsInDatabase,
>                 boolean disableVersionIncrement,
>                 boolean lazyPropertiesAreUnfetched);
>     }
>
>     I would suggest a "creation context" method param object to pass
>     in here, but seeing as how we are trying to stop instantiations...
>
>     I would prefer the definition of the EntityEntryFactory to use be
>     defined via SessionFactoryBuilder interface.  I already have plans
>     to have a auto-loaded hook for integrators to be able to adjust
>     the SessionFactoryBuilder.  But as a Service is fine too.
>
>
>             For example with Hibernate OGM we might want to override / re
>             configure the factories to use custom EntityEntry
>             implementations -
>             requirements are not fully clear at this point but it
>             seems likely.
>
>             The priority being to define the API as that would be a
>             blocker for
>             5.0, we have then better choices to leave more smarter and
>             advanced
>             EntityEntry implementations for the future; we'd still need to
>             implement at least the essential ones to make sure the API
>             of the
>             EntityEntryFactory has all the context it needs.
>
>             Thanks,
>             Sanne
>
>
>             On 24 March 2015 at 09:27, John O'Hara <johara at redhat.com
>             <mailto:johara at redhat.com>> wrote:
>             > Steve,
>             >
>             > Have you had chance to look at this? Do you have any
>             comments/observations?
>             >
>             > Thanks
>             >
>             > John
>             >
>             >
>             > On 17/03/15 09:24, John O'Hara wrote:
>             >
>             > Steve,
>             >
>             > I have been having a think about the EntityEntry
>             interface, and have forked
>             > a branch here:
>             >
>             >
>             https://github.com/johnaoahra80/hibernate-orm/tree/EntityEntryInterface
>             >
>             > I know it is nowhere near complete, but was this the
>             sort of idea you had in
>             > mind?
>             >
>             > Thanks
>             >
>             > John
>             >
>             >
>             > On 13/03/15 09:44, John O'Hara wrote:
>             >
>             > EntityEntry retains a reference to a persistenceContext
>             internally that
>             > org.hibernate.engine.spi.EntityEntry#setReadOnly makes
>             calls to, is this
>             > where the session reference is kept?  As
>             > org.hibernate.engine.spi.PersistenceConext is an
>             interface could we have a
>             > different implementation for this use case? e.g. an
>             > ImmutablePersistenceContext that could be shared across
>             sessions?
>             >
>             > For the bytecode enhancement, could we change the
>             enhancer so that it adds
>             > an EntityEntry interface with javassist.
>             > ClassPool.javassist.ClassPool.makeInterface()() as
>             opposed to adding a class
>             > javassist.ClassPool.makeClass()? I need to have a look
>             at javassit to
>             > confirm what javassist.ClassPool.makeInterface() does.
>             >
>             > Thanks
>             >
>             > John
>             >
>             > On 12/03/15 18:52, Steve Ebersole wrote:
>             >
>             > It is possible.  Although some of the changes are
>             particularly painful.
>             > Most of EntityEntry, if it is an interface, can be made
>             to work with your
>             > use case.
>             org.hibernate.engine.spi.EntityEntry#setReadOnly I think
>             is the
>             > one exception, because:
>             > 1) your use case needs it
>             > 2) it expects the Session to be available internally
>             (its not passed)
>             >
>             > The bigger thing I am worried about for you is the
>             bytecode stuff, as that
>             > ties very tightly with EntityEntry.
>             >
>             _______________________________________________
>             hibernate-dev mailing list
>             hibernate-dev at lists.jboss.org
>             <mailto:hibernate-dev at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
>


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).


From steve at hibernate.org  Fri Mar 27 07:35:16 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 27 Mar 2015 06:35:16 -0500
Subject: [hibernate-dev] Bytecode enhanced,
	Reference Cached immutable Entities
In-Reply-To: <55153930.9070200@redhat.com>
References: <55003692.9080906@gmail.com>
	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>
	<5502B18F.4050403@redhat.com> <5507F2D4.8040202@redhat.com>
	<55112E1C.5030004@redhat.com>
	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
	<CAFdSV9sFDr-984gFGGPxnU79u66YPAktonV9wJmfSjfp=Q3F6A@mail.gmail.com>
	<CAFdSV9tWjGTxq67QRJqXcyZWk1jgasWkdfrf0u=grhOg-JDXvQ@mail.gmail.com>
	<CAFdSV9sXO-BY-nK=eF0p4Fd_aKyQq1DgNMBWWtQO3VJ6SGexjQ@mail.gmail.com>
	<55153930.9070200@redhat.com>
Message-ID: <CAFdSV9v-ZWa70n7sOiWt=3tAzy8j+VmWXG2c8YBnWo+Yr-05qA@mail.gmail.com>

An EntityPersister describes each entity you defined in your model.  Its
one-to-one between @Entity and EntityPersister.  And really, it is totally
reasonable to have the EntityPersister determine the "EntityEntry builder"
to use.  That also eliminates needing to develop
yet-another-extension-point because if we expose it from EntityPersister
OGM already swaps EntityPersister impls so this would JustWork.

On Fri, Mar 27, 2015 at 6:04 AM, John O'Hara <johara at redhat.com> wrote:

>  On 26/03/15 16:22, Steve Ebersole wrote:
>
> The contract I suggested btw is missing one use case I know we have
> discussed in regards to OGM a few times... the ability to store references
> to datastore specific locators (I think the use case was to efficiently
> load collections through that datastore reference).  But that (obviously)
> requires passing extra, specific state into the createEntityEntry method.
> Not really sure the best way to handle such things tbh.
>
>  If we did have a "creation Context" parameter passed to the
> createEntityEntry, we would be instantiating more objects, however if we
> went with Sanne' suggestion if caching the EnityEntryFactory with the
> EntityPersister, how many objects would be actually created?  I am not sure
> about the relationship between Entity, EntityEntry and Session but could
> this a possibility if there is a 1-1 relationship between EntityPersister
> and no. of different Entities definitions?
>
>
>  On Thu, Mar 26, 2015 at 11:16 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Apparently I hit some key combo that means send :)  To finish up...
>>
>> On Thu, Mar 26, 2015 at 10:58 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>>
>>> On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>>>
>>>>
>>>> Concurrency
>>>>    Since the goal is to share the ImmutableEntityEntry instance among
>>>> multiple threads reading it, I'd rather make sure that it is really
>>>> immutable. For example it now holds onto potentially lazy initialized
>>>> fields, such as getEntityKey().
>>>> If it's not possible to make it really immutable (all final fields),
>>>> we'll need to make it threadsafe and question the name I'm proposing.
>>>>
>>>
>>>  The specific use-case John is interested in does indeed need to be
>>> completely thread-safe and fully concurrent.
>>>
>>>
>>>> LockMode
>>>>   From a logical perspective of users, one might think that an entity
>>>> being "immutable" doesn't necessarily imply I can't lock on it..
>>>> right? I'm not sure how far it could be a valid use case, but these
>>>> patches are implying that one can't lock an immutable entity anymore,
>>>> as the lock state would be as immutable as anything else on the
>>>> EntityEntry.
>>>> Are we good with that? Alternatively one might need to think to
>>>> separate the lock state handling from the EntityEntry.
>>>>
>>>
>>>  Conceptually there is nothing wrong with requesting a READ lock on an
>>> immutable entity.  But like you said, what is the logical expectation
>>> there?  IMO there should be none.  But if we decide that it is OK to req
>>>
>>
>>  But if we decide that it is OK to request a lock on an immutable
>> entity, that is problematic for the idea of a "SharedEntityEntry" or an
>> "ImmutableEntityEntry" because a lock is associated with a Session which is
>> what the EntityEntry is meant to model... an entity's information in
>> relation to a Session.  Aka, it now needs to hold state.
>>
>>
>>
>>>  Notice I said immutable here and not READ_ONLY which is a specific
>>> distinction which is important to other parts of your email that I will
>>> address in a second email.
>>>
>>>
>>>
>>>>
>>>> On smaller details:
>>>> # org.hibernate.engine.internal.SharedEntityEntry is hosted in an
>>>> .internal package, I don't think it's right to refactor all the public
>>>> API javadoc which was referring to EntityEntry to now refer to the
>>>> internal implementation.
>>>> # things like EntityEntryExtraState should probably get moved to
>>>> .internal packages as well now - we couldn't do that before without
>>>> breaking either encapsulation or APIs.
>>>>
>>>
>>  +1
>>
>>
>>>
>>>> In terms of git patches, the complexity of the changeset risks to get
>>>> a bit our of hand. What about we focus on creating a clean pull
>>>> request which focuses exclusively on making EntityEntry an interface,
>>>> and move things to the right packages and javadoc?
>>>>
>>>
>>  Agree 100%
>>
>>
>>>    You'd have a trivial EntitEntryFactory, and we can then build the
>>>> evolution on top of that, not least maybe helping out by challenging
>>>> some points in parallel work.
>>>> These are the things I'd leave for a second iteration:
>>>>  - add various implementations of EntityEntry iteratively, as needed
>>>>  - the strategy such a Factory would use the pick an implementation
>>>>  - ultimately, make it possible for an integrator to override such a
>>>> Factory
>>>>
>>>
>>   This all seems reasonable.  For 5.0 I think the most important thing
>> is to nail down the idea of EntityEntry as an interface, introduce a
>> Factory for building them and agree on the signature for building them.
>> Granted we may need iteration to finalize the actual Factory signature,
>> especially as OGM finally starts to use it, but I think that in general we
>> can get it pretty close.  Worst case we just pass high-level constructs
>> like the EntityPersister (which OGM supplies custom impls) and the Session
>> and all the "EntityEntry state".  For the purpose of starting a discussion:
>>
>>  public interface EntityEntryFactory {
>>      public EntityEntry createEntityEntry(
>>              PersistenceContext persistenceContext,
>>              EntityPersister persister,
>>             Status status,
>>              Serializable id,
>>             Object version,
>>              Object[] loadedState,
>>             Object rowId,
>>             LockMode lockMode,
>>              boolean existsInDatabase,
>>             boolean disableVersionIncrement,
>>              boolean lazyPropertiesAreUnfetched);
>>  }
>>
>>  I would suggest a "creation context" method param object to pass in
>> here, but seeing as how we are trying to stop instantiations...
>>
>>  I would prefer the definition of the EntityEntryFactory to use be
>> defined via SessionFactoryBuilder interface.  I already have plans to have
>> a auto-loaded hook for integrators to be able to adjust the
>> SessionFactoryBuilder.  But as a Service is fine too.
>>
>>
>>>> For example with Hibernate OGM we might want to override / re
>>>> configure the factories to use custom EntityEntry implementations -
>>>> requirements are not fully clear at this point but it seems likely.
>>>>
>>>> The priority being to define the API as that would be a blocker for
>>>> 5.0, we have then better choices to leave more smarter and advanced
>>>> EntityEntry implementations for the future; we'd still need to
>>>> implement at least the essential ones to make sure the API of the
>>>> EntityEntryFactory has all the context it needs.
>>>>
>>>> Thanks,
>>>> Sanne
>>>>
>>>>
>>>> On 24 March 2015 at 09:27, John O'Hara <johara at redhat.com> wrote:
>>>> > Steve,
>>>> >
>>>> > Have you had chance to look at this? Do you have any
>>>> comments/observations?
>>>> >
>>>> > Thanks
>>>> >
>>>> > John
>>>> >
>>>> >
>>>> > On 17/03/15 09:24, John O'Hara wrote:
>>>> >
>>>> > Steve,
>>>> >
>>>> > I have been having a think about the EntityEntry interface, and have
>>>> forked
>>>> > a branch here:
>>>> >
>>>> >
>>>> https://github.com/johnaoahra80/hibernate-orm/tree/EntityEntryInterface
>>>> >
>>>> > I know it is nowhere near complete, but was this the sort of idea you
>>>> had in
>>>> > mind?
>>>> >
>>>> > Thanks
>>>> >
>>>> > John
>>>> >
>>>> >
>>>> > On 13/03/15 09:44, John O'Hara wrote:
>>>> >
>>>> > EntityEntry retains a reference to a persistenceContext internally
>>>> that
>>>> > org.hibernate.engine.spi.EntityEntry#setReadOnly makes calls to, is
>>>> this
>>>> > where the session reference is kept?  As
>>>> > org.hibernate.engine.spi.PersistenceConext is an interface could we
>>>> have a
>>>> > different implementation for this use case? e.g. an
>>>> > ImmutablePersistenceContext that could be shared across sessions?
>>>> >
>>>> > For the bytecode enhancement, could we change the enhancer so that it
>>>> adds
>>>> > an EntityEntry interface with javassist.
>>>> > ClassPool.javassist.ClassPool.makeInterface()() as opposed to adding
>>>> a class
>>>> > javassist.ClassPool.makeClass()? I need to have a look at javassit to
>>>> > confirm what javassist.ClassPool.makeInterface() does.
>>>> >
>>>> > Thanks
>>>> >
>>>> > John
>>>> >
>>>> > On 12/03/15 18:52, Steve Ebersole wrote:
>>>> >
>>>> > It is possible.  Although some of the changes are particularly
>>>> painful.
>>>> > Most of EntityEntry, if it is an interface, can be made to work with
>>>> your
>>>> > use case.  org.hibernate.engine.spi.EntityEntry#setReadOnly I think
>>>> is the
>>>> > one exception, because:
>>>> > 1) your use case needs it
>>>> > 2) it expects the Session to be available internally (its not passed)
>>>> >
>>>> > The bigger thing I am worried about for you is the bytecode stuff, as
>>>> that
>>>> > ties very tightly with EntityEntry.
>>>> >
>>>>  _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>
>
>
> --
> John O'Harajohara at redhat.com
>
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>
>
>

From steve at hibernate.org  Fri Mar 27 07:36:24 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 27 Mar 2015 06:36:24 -0500
Subject: [hibernate-dev] Bytecode enhanced,
	Reference Cached immutable Entities
In-Reply-To: <CAFdSV9v-ZWa70n7sOiWt=3tAzy8j+VmWXG2c8YBnWo+Yr-05qA@mail.gmail.com>
References: <55003692.9080906@gmail.com>
	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>
	<5502B18F.4050403@redhat.com> <5507F2D4.8040202@redhat.com>
	<55112E1C.5030004@redhat.com>
	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
	<CAFdSV9sFDr-984gFGGPxnU79u66YPAktonV9wJmfSjfp=Q3F6A@mail.gmail.com>
	<CAFdSV9tWjGTxq67QRJqXcyZWk1jgasWkdfrf0u=grhOg-JDXvQ@mail.gmail.com>
	<CAFdSV9sXO-BY-nK=eF0p4Fd_aKyQq1DgNMBWWtQO3VJ6SGexjQ@mail.gmail.com>
	<55153930.9070200@redhat.com>
	<CAFdSV9v-ZWa70n7sOiWt=3tAzy8j+VmWXG2c8YBnWo+Yr-05qA@mail.gmail.com>
Message-ID: <CAFdSV9unqcZ0RyL+zkQhauQ9oauw99XuGV3O3Gg64u0Mq9Do1w@mail.gmail.com>

BTW, if we go this route this *cannot* be backported because we do allow
users to override EntityPersister; its an extension point.  Adding a new
method to extension points in bugfixes is a no-no.

On Fri, Mar 27, 2015 at 6:35 AM, Steve Ebersole <steve at hibernate.org> wrote:

> An EntityPersister describes each entity you defined in your model.  Its
> one-to-one between @Entity and EntityPersister.  And really, it is totally
> reasonable to have the EntityPersister determine the "EntityEntry builder"
> to use.  That also eliminates needing to develop
> yet-another-extension-point because if we expose it from EntityPersister
> OGM already swaps EntityPersister impls so this would JustWork.
>
> On Fri, Mar 27, 2015 at 6:04 AM, John O'Hara <johara at redhat.com> wrote:
>
>>  On 26/03/15 16:22, Steve Ebersole wrote:
>>
>> The contract I suggested btw is missing one use case I know we have
>> discussed in regards to OGM a few times... the ability to store references
>> to datastore specific locators (I think the use case was to efficiently
>> load collections through that datastore reference).  But that (obviously)
>> requires passing extra, specific state into the createEntityEntry method.
>> Not really sure the best way to handle such things tbh.
>>
>>  If we did have a "creation Context" parameter passed to the
>> createEntityEntry, we would be instantiating more objects, however if we
>> went with Sanne' suggestion if caching the EnityEntryFactory with the
>> EntityPersister, how many objects would be actually created?  I am not sure
>> about the relationship between Entity, EntityEntry and Session but could
>> this a possibility if there is a 1-1 relationship between EntityPersister
>> and no. of different Entities definitions?
>>
>>
>>  On Thu, Mar 26, 2015 at 11:16 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Apparently I hit some key combo that means send :)  To finish up...
>>>
>>> On Thu, Mar 26, 2015 at 10:58 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>>
>>>> On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <sanne at hibernate.org>
>>>> wrote:
>>>>>
>>>>>
>>>>> Concurrency
>>>>>    Since the goal is to share the ImmutableEntityEntry instance among
>>>>> multiple threads reading it, I'd rather make sure that it is really
>>>>> immutable. For example it now holds onto potentially lazy initialized
>>>>> fields, such as getEntityKey().
>>>>> If it's not possible to make it really immutable (all final fields),
>>>>> we'll need to make it threadsafe and question the name I'm proposing.
>>>>>
>>>>
>>>>  The specific use-case John is interested in does indeed need to be
>>>> completely thread-safe and fully concurrent.
>>>>
>>>>
>>>>> LockMode
>>>>>   From a logical perspective of users, one might think that an entity
>>>>> being "immutable" doesn't necessarily imply I can't lock on it..
>>>>> right? I'm not sure how far it could be a valid use case, but these
>>>>> patches are implying that one can't lock an immutable entity anymore,
>>>>> as the lock state would be as immutable as anything else on the
>>>>> EntityEntry.
>>>>> Are we good with that? Alternatively one might need to think to
>>>>> separate the lock state handling from the EntityEntry.
>>>>>
>>>>
>>>>  Conceptually there is nothing wrong with requesting a READ lock on an
>>>> immutable entity.  But like you said, what is the logical expectation
>>>> there?  IMO there should be none.  But if we decide that it is OK to req
>>>>
>>>
>>>  But if we decide that it is OK to request a lock on an immutable
>>> entity, that is problematic for the idea of a "SharedEntityEntry" or an
>>> "ImmutableEntityEntry" because a lock is associated with a Session which is
>>> what the EntityEntry is meant to model... an entity's information in
>>> relation to a Session.  Aka, it now needs to hold state.
>>>
>>>
>>>
>>>>  Notice I said immutable here and not READ_ONLY which is a specific
>>>> distinction which is important to other parts of your email that I will
>>>> address in a second email.
>>>>
>>>>
>>>>
>>>>>
>>>>> On smaller details:
>>>>> # org.hibernate.engine.internal.SharedEntityEntry is hosted in an
>>>>> .internal package, I don't think it's right to refactor all the public
>>>>> API javadoc which was referring to EntityEntry to now refer to the
>>>>> internal implementation.
>>>>> # things like EntityEntryExtraState should probably get moved to
>>>>> .internal packages as well now - we couldn't do that before without
>>>>> breaking either encapsulation or APIs.
>>>>>
>>>>
>>>  +1
>>>
>>>
>>>>
>>>>> In terms of git patches, the complexity of the changeset risks to get
>>>>> a bit our of hand. What about we focus on creating a clean pull
>>>>> request which focuses exclusively on making EntityEntry an interface,
>>>>> and move things to the right packages and javadoc?
>>>>>
>>>>
>>>  Agree 100%
>>>
>>>
>>>>    You'd have a trivial EntitEntryFactory, and we can then build the
>>>>> evolution on top of that, not least maybe helping out by challenging
>>>>> some points in parallel work.
>>>>> These are the things I'd leave for a second iteration:
>>>>>  - add various implementations of EntityEntry iteratively, as needed
>>>>>  - the strategy such a Factory would use the pick an implementation
>>>>>  - ultimately, make it possible for an integrator to override such a
>>>>> Factory
>>>>>
>>>>
>>>   This all seems reasonable.  For 5.0 I think the most important thing
>>> is to nail down the idea of EntityEntry as an interface, introduce a
>>> Factory for building them and agree on the signature for building them.
>>> Granted we may need iteration to finalize the actual Factory signature,
>>> especially as OGM finally starts to use it, but I think that in general we
>>> can get it pretty close.  Worst case we just pass high-level constructs
>>> like the EntityPersister (which OGM supplies custom impls) and the Session
>>> and all the "EntityEntry state".  For the purpose of starting a discussion:
>>>
>>>  public interface EntityEntryFactory {
>>>      public EntityEntry createEntityEntry(
>>>              PersistenceContext persistenceContext,
>>>              EntityPersister persister,
>>>             Status status,
>>>              Serializable id,
>>>             Object version,
>>>              Object[] loadedState,
>>>             Object rowId,
>>>             LockMode lockMode,
>>>              boolean existsInDatabase,
>>>             boolean disableVersionIncrement,
>>>              boolean lazyPropertiesAreUnfetched);
>>>  }
>>>
>>>  I would suggest a "creation context" method param object to pass in
>>> here, but seeing as how we are trying to stop instantiations...
>>>
>>>  I would prefer the definition of the EntityEntryFactory to use be
>>> defined via SessionFactoryBuilder interface.  I already have plans to have
>>> a auto-loaded hook for integrators to be able to adjust the
>>> SessionFactoryBuilder.  But as a Service is fine too.
>>>
>>>
>>>>> For example with Hibernate OGM we might want to override / re
>>>>> configure the factories to use custom EntityEntry implementations -
>>>>> requirements are not fully clear at this point but it seems likely.
>>>>>
>>>>> The priority being to define the API as that would be a blocker for
>>>>> 5.0, we have then better choices to leave more smarter and advanced
>>>>> EntityEntry implementations for the future; we'd still need to
>>>>> implement at least the essential ones to make sure the API of the
>>>>> EntityEntryFactory has all the context it needs.
>>>>>
>>>>> Thanks,
>>>>> Sanne
>>>>>
>>>>>
>>>>> On 24 March 2015 at 09:27, John O'Hara <johara at redhat.com> wrote:
>>>>> > Steve,
>>>>> >
>>>>> > Have you had chance to look at this? Do you have any
>>>>> comments/observations?
>>>>> >
>>>>> > Thanks
>>>>> >
>>>>> > John
>>>>> >
>>>>> >
>>>>> > On 17/03/15 09:24, John O'Hara wrote:
>>>>> >
>>>>> > Steve,
>>>>> >
>>>>> > I have been having a think about the EntityEntry interface, and have
>>>>> forked
>>>>> > a branch here:
>>>>> >
>>>>> >
>>>>> https://github.com/johnaoahra80/hibernate-orm/tree/EntityEntryInterface
>>>>> >
>>>>> > I know it is nowhere near complete, but was this the sort of idea
>>>>> you had in
>>>>> > mind?
>>>>> >
>>>>> > Thanks
>>>>> >
>>>>> > John
>>>>> >
>>>>> >
>>>>> > On 13/03/15 09:44, John O'Hara wrote:
>>>>> >
>>>>> > EntityEntry retains a reference to a persistenceContext internally
>>>>> that
>>>>> > org.hibernate.engine.spi.EntityEntry#setReadOnly makes calls to, is
>>>>> this
>>>>> > where the session reference is kept?  As
>>>>> > org.hibernate.engine.spi.PersistenceConext is an interface could we
>>>>> have a
>>>>> > different implementation for this use case? e.g. an
>>>>> > ImmutablePersistenceContext that could be shared across sessions?
>>>>> >
>>>>> > For the bytecode enhancement, could we change the enhancer so that
>>>>> it adds
>>>>> > an EntityEntry interface with javassist.
>>>>> > ClassPool.javassist.ClassPool.makeInterface()() as opposed to adding
>>>>> a class
>>>>> > javassist.ClassPool.makeClass()? I need to have a look at javassit to
>>>>> > confirm what javassist.ClassPool.makeInterface() does.
>>>>> >
>>>>> > Thanks
>>>>> >
>>>>> > John
>>>>> >
>>>>> > On 12/03/15 18:52, Steve Ebersole wrote:
>>>>> >
>>>>> > It is possible.  Although some of the changes are particularly
>>>>> painful.
>>>>> > Most of EntityEntry, if it is an interface, can be made to work with
>>>>> your
>>>>> > use case.  org.hibernate.engine.spi.EntityEntry#setReadOnly I think
>>>>> is the
>>>>> > one exception, because:
>>>>> > 1) your use case needs it
>>>>> > 2) it expects the Session to be available internally (its not passed)
>>>>> >
>>>>> > The bigger thing I am worried about for you is the bytecode stuff,
>>>>> as that
>>>>> > ties very tightly with EntityEntry.
>>>>> >
>>>>>  _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> John O'Harajohara at redhat.com
>>
>> JBoss, by Red Hat
>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>>
>>
>>
>

From johara at redhat.com  Fri Mar 27 07:42:24 2015
From: johara at redhat.com (John O'Hara)
Date: Fri, 27 Mar 2015 11:42:24 +0000
Subject: [hibernate-dev] Bytecode enhanced,
 Reference Cached immutable Entities
In-Reply-To: <CAFdSV9unqcZ0RyL+zkQhauQ9oauw99XuGV3O3Gg64u0Mq9Do1w@mail.gmail.com>
References: <55003692.9080906@gmail.com>	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>	<5502B18F.4050403@redhat.com>	<5507F2D4.8040202@redhat.com>	<55112E1C.5030004@redhat.com>	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>	<CAFdSV9sFDr-984gFGGPxnU79u66YPAktonV9wJmfSjfp=Q3F6A@mail.gmail.com>	<CAFdSV9tWjGTxq67QRJqXcyZWk1jgasWkdfrf0u=grhOg-JDXvQ@mail.gmail.com>	<CAFdSV9sXO-BY-nK=eF0p4Fd_aKyQq1DgNMBWWtQO3VJ6SGexjQ@mail.gmail.com>	<55153930.9070200@redhat.com>	<CAFdSV9v-ZWa70n7sOiWt=3tAzy8j+VmWXG2c8YBnWo+Yr-05qA@mail.gmail.com>
	<CAFdSV9unqcZ0RyL+zkQhauQ9oauw99XuGV3O3Gg64u0Mq9Do1w@mail.gmail.com>
Message-ID: <55154220.4010700@redhat.com>

Steve,

 From our point of view, we would not be looking to backport any 
features introduced to any of the ORM4 releases. Our focus has shifted 
to the next major release of EAP as we have a number of issues we need 
to overcome. Getting this feature into ORM5 sooner rather than later is 
essential for our use case in the future.

Thanks

John

On 27/03/15 11:36, Steve Ebersole wrote:
> BTW, if we go this route this *cannot* be backported because we do 
> allow users to override EntityPersister; its an extension point.  
> Adding a new method to extension points in bugfixes is a no-no.
>
> On Fri, Mar 27, 2015 at 6:35 AM, Steve Ebersole <steve at hibernate.org 
> <mailto:steve at hibernate.org>> wrote:
>
>     An EntityPersister describes each entity you defined in your
>     model.  Its one-to-one between @Entity and EntityPersister.  And
>     really, it is totally reasonable to have the EntityPersister
>     determine the "EntityEntry builder" to use.  That also eliminates
>     needing to develop yet-another-extension-point because if we
>     expose it from EntityPersister OGM already swaps EntityPersister
>     impls so this would JustWork.
>
>     On Fri, Mar 27, 2015 at 6:04 AM, John O'Hara <johara at redhat.com
>     <mailto:johara at redhat.com>> wrote:
>
>         On 26/03/15 16:22, Steve Ebersole wrote:
>>         The contract I suggested btw is missing one use case I know
>>         we have discussed in regards to OGM a few times... the
>>         ability to store references to datastore specific locators (I
>>         think the use case was to efficiently load collections
>>         through that datastore reference).  But that (obviously)
>>         requires passing extra, specific state into
>>         the createEntityEntry method.  Not really sure the best way
>>         to handle such things tbh.
>>
>         If we did have a "creation Context" parameter passed to the
>         createEntityEntry, we would be instantiating more objects,
>         however if we went with Sanne' suggestion if caching the
>         EnityEntryFactory with the EntityPersister, how many objects
>         would be actually created?  I am not sure about the
>         relationship between Entity, EntityEntry and Session but could
>         this a possibility if there is a 1-1 relationship between
>         EntityPersister and no. of different Entities definitions?
>
>
>>         On Thu, Mar 26, 2015 at 11:16 AM, Steve Ebersole
>>         <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>>
>>             Apparently I hit some key combo that means send :)  To
>>             finish up...
>>
>>             On Thu, Mar 26, 2015 at 10:58 AM, Steve Ebersole
>>             <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>>
>>
>>                 On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero
>>                 <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
>>
>>
>>                     Concurrency
>>                        Since the goal is to share the
>>                     ImmutableEntityEntry instance among
>>                     multiple threads reading it, I'd rather make sure
>>                     that it is really
>>                     immutable. For example it now holds onto
>>                     potentially lazy initialized
>>                     fields, such as getEntityKey().
>>                     If it's not possible to make it really immutable
>>                     (all final fields),
>>                     we'll need to make it threadsafe and question the
>>                     name I'm proposing.
>>
>>
>>                 The specific use-case John is interested in does
>>                 indeed need to be completely thread-safe and fully
>>                 concurrent.
>>
>>
>>                     LockMode
>>                       From a logical perspective of users, one might
>>                     think that an entity
>>                     being "immutable" doesn't necessarily imply I
>>                     can't lock on it..
>>                     right? I'm not sure how far it could be a valid
>>                     use case, but these
>>                     patches are implying that one can't lock an
>>                     immutable entity anymore,
>>                     as the lock state would be as immutable as
>>                     anything else on the
>>                     EntityEntry.
>>                     Are we good with that? Alternatively one might
>>                     need to think to
>>                     separate the lock state handling from the
>>                     EntityEntry.
>>
>>
>>                 Conceptually there is nothing wrong with requesting a
>>                 READ lock on an immutable entity. But like you said,
>>                 what is the logical expectation there?  IMO there
>>                 should be none. But if we decide that it is OK to req
>>
>>             But if we decide that it is OK to request a lock on an
>>             immutable entity, that is problematic for the idea of a
>>             "SharedEntityEntry" or an "ImmutableEntityEntry" because
>>             a lock is associated with a Session which is what the
>>             EntityEntry is meant to model... an entity's information
>>             in relation to a Session.  Aka, it now needs to hold state.
>>
>>
>>
>>                 Notice I said immutable here and not READ_ONLY which
>>                 is a specific distinction which is important to other
>>                 parts of your email that I will address in a second
>>                 email.
>>
>>
>>                     On smaller details:
>>                     # org.hibernate.engine.internal.SharedEntityEntry
>>                     is hosted in an
>>                     .internal package, I don't think it's right to
>>                     refactor all the public
>>                     API javadoc which was referring to EntityEntry to
>>                     now refer to the
>>                     internal implementation.
>>                     # things like EntityEntryExtraState should
>>                     probably get moved to
>>                     .internal packages as well now - we couldn't do
>>                     that before without
>>                     breaking either encapsulation or APIs.
>>
>>
>>             +1
>>
>>
>>                     In terms of git patches, the complexity of the
>>                     changeset risks to get
>>                     a bit our of hand. What about we focus on
>>                     creating a clean pull
>>                     request which focuses exclusively on making
>>                     EntityEntry an interface,
>>                     and move things to the right packages and javadoc?
>>
>>
>>             Agree 100%
>>
>>                     You'd have a trivial EntitEntryFactory, and we
>>                     can then build the
>>                     evolution on top of that, not least maybe helping
>>                     out by challenging
>>                     some points in parallel work.
>>                     These are the things I'd leave for a second
>>                     iteration:
>>                      - add various implementations of EntityEntry
>>                     iteratively, as needed
>>                      - the strategy such a Factory would use the pick
>>                     an implementation
>>                      - ultimately, make it possible for an integrator
>>                     to override such a Factory
>>
>>
>>              This all seems reasonable.  For 5.0 I think the most
>>             important thing is to nail down the idea of EntityEntry
>>             as an interface, introduce a Factory for building them
>>             and agree on the signature for building them.  Granted we
>>             may need iteration to finalize the actual Factory
>>             signature, especially as OGM finally starts to use it,
>>             but I think that in general we can get it pretty close. 
>>             Worst case we just pass high-level constructs like the
>>             EntityPersister (which OGM supplies custom impls) and the
>>             Session and all the "EntityEntry state".  For the purpose
>>             of starting a discussion:
>>
>>             public interface EntityEntryFactory {
>>                 public EntityEntry createEntityEntry(
>>             PersistenceContext persistenceContext,
>>                       EntityPersister persister,
>>                       Status status,
>>                       Serializable id,
>>                       Object version,
>>                         Object[] loadedState,
>>                         Object rowId,
>>                         LockMode lockMode,
>>                         boolean existsInDatabase,
>>                         boolean disableVersionIncrement,
>>                         boolean lazyPropertiesAreUnfetched);
>>             }
>>
>>             I would suggest a "creation context" method param object
>>             to pass in here, but seeing as how we are trying to stop
>>             instantiations...
>>
>>             I would prefer the definition of the EntityEntryFactory
>>             to use be defined via SessionFactoryBuilder interface.  I
>>             already have plans to have a auto-loaded hook for
>>             integrators to be able to adjust the
>>             SessionFactoryBuilder.  But as a Service is fine too.
>>
>>
>>                     For example with Hibernate OGM we might want to
>>                     override / re
>>                     configure the factories to use custom EntityEntry
>>                     implementations -
>>                     requirements are not fully clear at this point
>>                     but it seems likely.
>>
>>                     The priority being to define the API as that
>>                     would be a blocker for
>>                     5.0, we have then better choices to leave more
>>                     smarter and advanced
>>                     EntityEntry implementations for the future; we'd
>>                     still need to
>>                     implement at least the essential ones to make
>>                     sure the API of the
>>                     EntityEntryFactory has all the context it needs.
>>
>>                     Thanks,
>>                     Sanne
>>
>>
>>                     On 24 March 2015 at 09:27, John O'Hara
>>                     <johara at redhat.com <mailto:johara at redhat.com>> wrote:
>>                     > Steve,
>>                     >
>>                     > Have you had chance to look at this? Do you
>>                     have any comments/observations?
>>                     >
>>                     > Thanks
>>                     >
>>                     > John
>>                     >
>>                     >
>>                     > On 17/03/15 09:24, John O'Hara wrote:
>>                     >
>>                     > Steve,
>>                     >
>>                     > I have been having a think about the
>>                     EntityEntry interface, and have forked
>>                     > a branch here:
>>                     >
>>                     >
>>                     https://github.com/johnaoahra80/hibernate-orm/tree/EntityEntryInterface
>>                     >
>>                     > I know it is nowhere near complete, but was
>>                     this the sort of idea you had in
>>                     > mind?
>>                     >
>>                     > Thanks
>>                     >
>>                     > John
>>                     >
>>                     >
>>                     > On 13/03/15 09:44, John O'Hara wrote:
>>                     >
>>                     > EntityEntry retains a reference to a
>>                     persistenceContext internally that
>>                     >
>>                     org.hibernate.engine.spi.EntityEntry#setReadOnly
>>                     makes calls to, is this
>>                     > where the session reference is kept?  As
>>                     > org.hibernate.engine.spi.PersistenceConext is
>>                     an interface could we have a
>>                     > different implementation for this use case? e.g. an
>>                     > ImmutablePersistenceContext that could be
>>                     shared across sessions?
>>                     >
>>                     > For the bytecode enhancement, could we change
>>                     the enhancer so that it adds
>>                     > an EntityEntry interface with javassist.
>>                     > ClassPool.javassist.ClassPool.makeInterface()()
>>                     as opposed to adding a class
>>                     > javassist.ClassPool.makeClass()? I need to have
>>                     a look at javassit to
>>                     > confirm what
>>                     javassist.ClassPool.makeInterface() does.
>>                     >
>>                     > Thanks
>>                     >
>>                     > John
>>                     >
>>                     > On 12/03/15 18:52, Steve Ebersole wrote:
>>                     >
>>                     > It is possible. Although some of the changes
>>                     are particularly painful.
>>                     > Most of EntityEntry, if it is an interface, can
>>                     be made to work with your
>>                     > use case.
>>                     org.hibernate.engine.spi.EntityEntry#setReadOnly
>>                     I think is the
>>                     > one exception, because:
>>                     > 1) your use case needs it
>>                     > 2) it expects the Session to be available
>>                     internally (its not passed)
>>                     >
>>                     > The bigger thing I am worried about for you is
>>                     the bytecode stuff, as that
>>                     > ties very tightly with EntityEntry.
>>                     >
>>                     _______________________________________________
>>                     hibernate-dev mailing list
>>                     hibernate-dev at lists.jboss.org
>>                     <mailto:hibernate-dev at lists.jboss.org>
>>                     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>>
>>
>
>
>         -- 
>         John O'Hara
>         johara at redhat.com  <mailto:johara at redhat.com>
>
>         JBoss, by Red Hat
>         Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>         Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>
>
>


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).


From sanne at hibernate.org  Fri Mar 27 08:14:15 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 27 Mar 2015 12:14:15 +0000
Subject: [hibernate-dev] Bytecode enhanced,
	Reference Cached immutable Entities
In-Reply-To: <55154220.4010700@redhat.com>
References: <55003692.9080906@gmail.com>
	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>
	<5502B18F.4050403@redhat.com> <5507F2D4.8040202@redhat.com>
	<55112E1C.5030004@redhat.com>
	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
	<CAFdSV9sFDr-984gFGGPxnU79u66YPAktonV9wJmfSjfp=Q3F6A@mail.gmail.com>
	<CAFdSV9tWjGTxq67QRJqXcyZWk1jgasWkdfrf0u=grhOg-JDXvQ@mail.gmail.com>
	<CAFdSV9sXO-BY-nK=eF0p4Fd_aKyQq1DgNMBWWtQO3VJ6SGexjQ@mail.gmail.com>
	<55153930.9070200@redhat.com>
	<CAFdSV9v-ZWa70n7sOiWt=3tAzy8j+VmWXG2c8YBnWo+Yr-05qA@mail.gmail.com>
	<CAFdSV9unqcZ0RyL+zkQhauQ9oauw99XuGV3O3Gg64u0Mq9Do1w@mail.gmail.com>
	<55154220.4010700@redhat.com>
Message-ID: <CAFm4XO3OmLs2Xsgfmyn_BOoL8-9PB6+Kav-vJD0Vw8h-CYnr0A@mail.gmail.com>

Also from OGM and Search perspective, we're not expecting any of this
to be backported.
It's not a functional blocker, "just" significant performance improvements.

How do we move further? John, I'm not familiar with the requirements
for the bytecode instrumentation, but can help a bit on the other
aspects. I could either work on extracting the patch of converting the
EntityEntry into an interface from your draft, or if you have time to
polish that I could review that PR. After that change is integrated,
it should be easier for us to work in parallel on different areas and
draft some ideas with the factory context idea.

+1 to an EntityPersister:EntityEntryFactory 1:1 relation, glad to see
it makes sense in your minds as well.

To make a decision on the Immutable entities vs Read Only entities..
are we good in applying the optimisation only to Immutable entities or
do we need to find a way for entities which happen to be loaded
read-only too? I might have an idea to play with for that, but it
obviously gets a bit more complex.

@Steve, I guess we're looking at you for advice on what needs to be
done for the Lock state. I'm understanding that needs to be addressed
right?

Thanks,
Sanne




On 27 March 2015 at 11:42, John O'Hara <johara at redhat.com> wrote:
> Steve,
>
> From our point of view, we would not be looking to backport any features
> introduced to any of the ORM4 releases. Our focus has shifted to the next
> major release of EAP as we have a number of issues we need to overcome.
> Getting this feature into ORM5 sooner rather than later is essential for our
> use case in the future.
>
> Thanks
>
> John
>
>
> On 27/03/15 11:36, Steve Ebersole wrote:
>
> BTW, if we go this route this *cannot* be backported because we do allow
> users to override EntityPersister; its an extension point.  Adding a new
> method to extension points in bugfixes is a no-no.
>
> On Fri, Mar 27, 2015 at 6:35 AM, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> An EntityPersister describes each entity you defined in your model.  Its
>> one-to-one between @Entity and EntityPersister.  And really, it is totally
>> reasonable to have the EntityPersister determine the "EntityEntry builder"
>> to use.  That also eliminates needing to develop yet-another-extension-point
>> because if we expose it from EntityPersister OGM already swaps
>> EntityPersister impls so this would JustWork.
>>
>> On Fri, Mar 27, 2015 at 6:04 AM, John O'Hara <johara at redhat.com> wrote:
>>>
>>> On 26/03/15 16:22, Steve Ebersole wrote:
>>>
>>> The contract I suggested btw is missing one use case I know we have
>>> discussed in regards to OGM a few times... the ability to store references
>>> to datastore specific locators (I think the use case was to efficiently load
>>> collections through that datastore reference).  But that (obviously)
>>> requires passing extra, specific state into the createEntityEntry method.
>>> Not really sure the best way to handle such things tbh.
>>>
>>> If we did have a "creation Context" parameter passed to the
>>> createEntityEntry, we would be instantiating more objects, however if we
>>> went with Sanne' suggestion if caching the EnityEntryFactory with the
>>> EntityPersister, how many objects would be actually created?  I am not sure
>>> about the relationship between Entity, EntityEntry and Session but could
>>> this a possibility if there is a 1-1 relationship between EntityPersister
>>> and no. of different Entities definitions?
>>>
>>>
>>> On Thu, Mar 26, 2015 at 11:16 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>>
>>>> Apparently I hit some key combo that means send :)  To finish up...
>>>>
>>>> On Thu, Mar 26, 2015 at 10:58 AM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>>
>>>>>
>>>>> On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <sanne at hibernate.org>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Concurrency
>>>>>>    Since the goal is to share the ImmutableEntityEntry instance among
>>>>>> multiple threads reading it, I'd rather make sure that it is really
>>>>>> immutable. For example it now holds onto potentially lazy initialized
>>>>>> fields, such as getEntityKey().
>>>>>> If it's not possible to make it really immutable (all final fields),
>>>>>> we'll need to make it threadsafe and question the name I'm proposing.
>>>>>
>>>>>
>>>>> The specific use-case John is interested in does indeed need to be
>>>>> completely thread-safe and fully concurrent.
>>>>>
>>>>>>
>>>>>> LockMode
>>>>>>   From a logical perspective of users, one might think that an entity
>>>>>> being "immutable" doesn't necessarily imply I can't lock on it..
>>>>>> right? I'm not sure how far it could be a valid use case, but these
>>>>>> patches are implying that one can't lock an immutable entity anymore,
>>>>>> as the lock state would be as immutable as anything else on the
>>>>>> EntityEntry.
>>>>>> Are we good with that? Alternatively one might need to think to
>>>>>> separate the lock state handling from the EntityEntry.
>>>>>
>>>>>
>>>>> Conceptually there is nothing wrong with requesting a READ lock on an
>>>>> immutable entity.  But like you said, what is the logical expectation there?
>>>>> IMO there should be none.  But if we decide that it is OK to req
>>>>
>>>>
>>>> But if we decide that it is OK to request a lock on an immutable entity,
>>>> that is problematic for the idea of a "SharedEntityEntry" or an
>>>> "ImmutableEntityEntry" because a lock is associated with a Session which is
>>>> what the EntityEntry is meant to model... an entity's information in
>>>> relation to a Session.  Aka, it now needs to hold state.
>>>>
>>>>
>>>>>
>>>>> Notice I said immutable here and not READ_ONLY which is a specific
>>>>> distinction which is important to other parts of your email that I will
>>>>> address in a second email.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On smaller details:
>>>>>> # org.hibernate.engine.internal.SharedEntityEntry is hosted in an
>>>>>> .internal package, I don't think it's right to refactor all the public
>>>>>> API javadoc which was referring to EntityEntry to now refer to the
>>>>>> internal implementation.
>>>>>> # things like EntityEntryExtraState should probably get moved to
>>>>>> .internal packages as well now - we couldn't do that before without
>>>>>> breaking either encapsulation or APIs.
>>>>
>>>>
>>>> +1
>>>>
>>>>>>
>>>>>>
>>>>>> In terms of git patches, the complexity of the changeset risks to get
>>>>>> a bit our of hand. What about we focus on creating a clean pull
>>>>>> request which focuses exclusively on making EntityEntry an interface,
>>>>>> and move things to the right packages and javadoc?
>>>>
>>>>
>>>> Agree 100%
>>>>
>>>>>>
>>>>>> You'd have a trivial EntitEntryFactory, and we can then build the
>>>>>> evolution on top of that, not least maybe helping out by challenging
>>>>>> some points in parallel work.
>>>>>> These are the things I'd leave for a second iteration:
>>>>>>  - add various implementations of EntityEntry iteratively, as needed
>>>>>>  - the strategy such a Factory would use the pick an implementation
>>>>>>  - ultimately, make it possible for an integrator to override such a
>>>>>> Factory
>>>>
>>>>
>>>>  This all seems reasonable.  For 5.0 I think the most important thing is
>>>> to nail down the idea of EntityEntry as an interface, introduce a Factory
>>>> for building them and agree on the signature for building them.  Granted we
>>>> may need iteration to finalize the actual Factory signature, especially as
>>>> OGM finally starts to use it, but I think that in general we can get it
>>>> pretty close.  Worst case we just pass high-level constructs like the
>>>> EntityPersister (which OGM supplies custom impls) and the Session and all
>>>> the "EntityEntry state".  For the purpose of starting a discussion:
>>>>
>>>> public interface EntityEntryFactory {
>>>>     public EntityEntry createEntityEntry(
>>>>             PersistenceContext persistenceContext,
>>>>             EntityPersister persister,
>>>>             Status status,
>>>>             Serializable id,
>>>>             Object version,
>>>>             Object[] loadedState,
>>>>             Object rowId,
>>>>             LockMode lockMode,
>>>>             boolean existsInDatabase,
>>>>             boolean disableVersionIncrement,
>>>>             boolean lazyPropertiesAreUnfetched);
>>>> }
>>>>
>>>> I would suggest a "creation context" method param object to pass in
>>>> here, but seeing as how we are trying to stop instantiations...
>>>>
>>>> I would prefer the definition of the EntityEntryFactory to use be
>>>> defined via SessionFactoryBuilder interface.  I already have plans to have a
>>>> auto-loaded hook for integrators to be able to adjust the
>>>> SessionFactoryBuilder.  But as a Service is fine too.
>>>>
>>>>>>
>>>>>> For example with Hibernate OGM we might want to override / re
>>>>>> configure the factories to use custom EntityEntry implementations -
>>>>>> requirements are not fully clear at this point but it seems likely.
>>>>>>
>>>>>> The priority being to define the API as that would be a blocker for
>>>>>> 5.0, we have then better choices to leave more smarter and advanced
>>>>>> EntityEntry implementations for the future; we'd still need to
>>>>>> implement at least the essential ones to make sure the API of the
>>>>>> EntityEntryFactory has all the context it needs.
>>>>>>
>>>>>> Thanks,
>>>>>> Sanne
>>>>>>
>>>>>>
>>>>>> On 24 March 2015 at 09:27, John O'Hara <johara at redhat.com> wrote:
>>>>>> > Steve,
>>>>>> >
>>>>>> > Have you had chance to look at this? Do you have any
>>>>>> > comments/observations?
>>>>>> >
>>>>>> > Thanks
>>>>>> >
>>>>>> > John
>>>>>> >
>>>>>> >
>>>>>> > On 17/03/15 09:24, John O'Hara wrote:
>>>>>> >
>>>>>> > Steve,
>>>>>> >
>>>>>> > I have been having a think about the EntityEntry interface, and have
>>>>>> > forked
>>>>>> > a branch here:
>>>>>> >
>>>>>> >
>>>>>> > https://github.com/johnaoahra80/hibernate-orm/tree/EntityEntryInterface
>>>>>> >
>>>>>> > I know it is nowhere near complete, but was this the sort of idea
>>>>>> > you had in
>>>>>> > mind?
>>>>>> >
>>>>>> > Thanks
>>>>>> >
>>>>>> > John
>>>>>> >
>>>>>> >
>>>>>> > On 13/03/15 09:44, John O'Hara wrote:
>>>>>> >
>>>>>> > EntityEntry retains a reference to a persistenceContext internally
>>>>>> > that
>>>>>> > org.hibernate.engine.spi.EntityEntry#setReadOnly makes calls to, is
>>>>>> > this
>>>>>> > where the session reference is kept?  As
>>>>>> > org.hibernate.engine.spi.PersistenceConext is an interface could we
>>>>>> > have a
>>>>>> > different implementation for this use case? e.g. an
>>>>>> > ImmutablePersistenceContext that could be shared across sessions?
>>>>>> >
>>>>>> > For the bytecode enhancement, could we change the enhancer so that
>>>>>> > it adds
>>>>>> > an EntityEntry interface with javassist.
>>>>>> > ClassPool.javassist.ClassPool.makeInterface()() as opposed to adding
>>>>>> > a class
>>>>>> > javassist.ClassPool.makeClass()? I need to have a look at javassit
>>>>>> > to
>>>>>> > confirm what javassist.ClassPool.makeInterface() does.
>>>>>> >
>>>>>> > Thanks
>>>>>> >
>>>>>> > John
>>>>>> >
>>>>>> > On 12/03/15 18:52, Steve Ebersole wrote:
>>>>>> >
>>>>>> > It is possible.  Although some of the changes are particularly
>>>>>> > painful.
>>>>>> > Most of EntityEntry, if it is an interface, can be made to work with
>>>>>> > your
>>>>>> > use case.  org.hibernate.engine.spi.EntityEntry#setReadOnly I think
>>>>>> > is the
>>>>>> > one exception, because:
>>>>>> > 1) your use case needs it
>>>>>> > 2) it expects the Session to be available internally (its not
>>>>>> > passed)
>>>>>> >
>>>>>> > The bigger thing I am worried about for you is the bytecode stuff,
>>>>>> > as that
>>>>>> > ties very tightly with EntityEntry.
>>>>>> >
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> John O'Hara
>>> johara at redhat.com
>>>
>>> JBoss, by Red Hat
>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
>>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>>> Registered in UK and Wales under Company Registration No. 3798903
>>> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
>>> (USA) and Michael O'Neill (Ireland).
>>>
>>
>
>
>
> --
> John O'Hara
> johara at redhat.com
>
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street,
> Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903 Directors:
> Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and
> Michael O'Neill (Ireland).
>

From johara at redhat.com  Fri Mar 27 09:11:38 2015
From: johara at redhat.com (John O'Hara)
Date: Fri, 27 Mar 2015 13:11:38 +0000
Subject: [hibernate-dev] Bytecode enhanced,
 Reference Cached immutable Entities
In-Reply-To: <CAFm4XO3OmLs2Xsgfmyn_BOoL8-9PB6+Kav-vJD0Vw8h-CYnr0A@mail.gmail.com>
References: <55003692.9080906@gmail.com>
	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>
	<5502B18F.4050403@redhat.com> <5507F2D4.8040202@redhat.com>
	<55112E1C.5030004@redhat.com>
	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
	<CAFdSV9sFDr-984gFGGPxnU79u66YPAktonV9wJmfSjfp=Q3F6A@mail.gmail.com>
	<CAFdSV9tWjGTxq67QRJqXcyZWk1jgasWkdfrf0u=grhOg-JDXvQ@mail.gmail.com>
	<CAFdSV9sXO-BY-nK=eF0p4Fd_aKyQq1DgNMBWWtQO3VJ6SGexjQ@mail.gmail.com>
	<55153930.9070200@redhat.com>
	<CAFdSV9v-ZWa70n7sOiWt=3tAzy8j+VmWXG2c8YBnWo+Yr-05qA@mail.gmail.com>
	<CAFdSV9unqcZ0RyL+zkQhauQ9oauw99XuGV3O3Gg64u0Mq9Do1w@mail.gmail.com>
	<55154220.4010700@redhat.com>
	<CAFm4XO3OmLs2Xsgfmyn_BOoL8-9PB6+Kav-vJD0Vw8h-CYnr0A@mail.gmail.com>
Message-ID: <5515570A.2090607@redhat.com>



On 27/03/15 12:14, Sanne Grinovero wrote:
> Also from OGM and Search perspective, we're not expecting any of this
> to be backported.
> It's not a functional blocker, "just" significant performance improvements.
>
> How do we move further? John, I'm not familiar with the requirements
> for the bytecode instrumentation, but can help a bit on the other
> aspects. I could either work on extracting the patch of converting the
> EntityEntry into an interface from your draft, or if you have time to
> polish that I could review that PR. After that change is integrated,
> it should be easier for us to work in parallel on different areas and
> draft some ideas with the factory context idea.
I had started to work on extracting just the EntityEntryInterface and 
factory, so can continue on that. Which issue do we want to log this 
under. There is already HHH-9265?
> +1 to an EntityPersister:EntityEntryFactory 1:1 relation, glad to see
> it makes sense in your minds as well.
>
> To make a decision on the Immutable entities vs Read Only entities..
> are we good in applying the optimisation only to Immutable entities or
> do we need to find a way for entities which happen to be loaded
> read-only too? I might have an idea to play with for that, but it
> obviously gets a bit more complex.
I think for our case that we only need Immutable entities, not sure of 
any other scenarios where you would need to optimise Read Only entities
>
> @Steve, I guess we're looking at you for advice on what needs to be
> done for the Lock state. I'm understanding that needs to be addressed
> right?
>
> Thanks,
> Sanne
>
>
>
>
> On 27 March 2015 at 11:42, John O'Hara <johara at redhat.com> wrote:
>> Steve,
>>
>>  From our point of view, we would not be looking to backport any features
>> introduced to any of the ORM4 releases. Our focus has shifted to the next
>> major release of EAP as we have a number of issues we need to overcome.
>> Getting this feature into ORM5 sooner rather than later is essential for our
>> use case in the future.
>>
>> Thanks
>>
>> John
>>
>>
>> On 27/03/15 11:36, Steve Ebersole wrote:
>>
>> BTW, if we go this route this *cannot* be backported because we do allow
>> users to override EntityPersister; its an extension point.  Adding a new
>> method to extension points in bugfixes is a no-no.
>>
>> On Fri, Mar 27, 2015 at 6:35 AM, Steve Ebersole <steve at hibernate.org> wrote:
>>> An EntityPersister describes each entity you defined in your model.  Its
>>> one-to-one between @Entity and EntityPersister.  And really, it is totally
>>> reasonable to have the EntityPersister determine the "EntityEntry builder"
>>> to use.  That also eliminates needing to develop yet-another-extension-point
>>> because if we expose it from EntityPersister OGM already swaps
>>> EntityPersister impls so this would JustWork.
>>>
>>> On Fri, Mar 27, 2015 at 6:04 AM, John O'Hara <johara at redhat.com> wrote:
>>>> On 26/03/15 16:22, Steve Ebersole wrote:
>>>>
>>>> The contract I suggested btw is missing one use case I know we have
>>>> discussed in regards to OGM a few times... the ability to store references
>>>> to datastore specific locators (I think the use case was to efficiently load
>>>> collections through that datastore reference).  But that (obviously)
>>>> requires passing extra, specific state into the createEntityEntry method.
>>>> Not really sure the best way to handle such things tbh.
>>>>
>>>> If we did have a "creation Context" parameter passed to the
>>>> createEntityEntry, we would be instantiating more objects, however if we
>>>> went with Sanne' suggestion if caching the EnityEntryFactory with the
>>>> EntityPersister, how many objects would be actually created?  I am not sure
>>>> about the relationship between Entity, EntityEntry and Session but could
>>>> this a possibility if there is a 1-1 relationship between EntityPersister
>>>> and no. of different Entities definitions?
>>>>
>>>>
>>>> On Thu, Mar 26, 2015 at 11:16 AM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>> Apparently I hit some key combo that means send :)  To finish up...
>>>>>
>>>>> On Thu, Mar 26, 2015 at 10:58 AM, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>>
>>>>>> On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <sanne at hibernate.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> Concurrency
>>>>>>>     Since the goal is to share the ImmutableEntityEntry instance among
>>>>>>> multiple threads reading it, I'd rather make sure that it is really
>>>>>>> immutable. For example it now holds onto potentially lazy initialized
>>>>>>> fields, such as getEntityKey().
>>>>>>> If it's not possible to make it really immutable (all final fields),
>>>>>>> we'll need to make it threadsafe and question the name I'm proposing.
>>>>>>
>>>>>> The specific use-case John is interested in does indeed need to be
>>>>>> completely thread-safe and fully concurrent.
>>>>>>
>>>>>>> LockMode
>>>>>>>    From a logical perspective of users, one might think that an entity
>>>>>>> being "immutable" doesn't necessarily imply I can't lock on it..
>>>>>>> right? I'm not sure how far it could be a valid use case, but these
>>>>>>> patches are implying that one can't lock an immutable entity anymore,
>>>>>>> as the lock state would be as immutable as anything else on the
>>>>>>> EntityEntry.
>>>>>>> Are we good with that? Alternatively one might need to think to
>>>>>>> separate the lock state handling from the EntityEntry.
>>>>>>
>>>>>> Conceptually there is nothing wrong with requesting a READ lock on an
>>>>>> immutable entity.  But like you said, what is the logical expectation there?
>>>>>> IMO there should be none.  But if we decide that it is OK to req
>>>>>
>>>>> But if we decide that it is OK to request a lock on an immutable entity,
>>>>> that is problematic for the idea of a "SharedEntityEntry" or an
>>>>> "ImmutableEntityEntry" because a lock is associated with a Session which is
>>>>> what the EntityEntry is meant to model... an entity's information in
>>>>> relation to a Session.  Aka, it now needs to hold state.
>>>>>
>>>>>
>>>>>> Notice I said immutable here and not READ_ONLY which is a specific
>>>>>> distinction which is important to other parts of your email that I will
>>>>>> address in a second email.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On smaller details:
>>>>>>> # org.hibernate.engine.internal.SharedEntityEntry is hosted in an
>>>>>>> .internal package, I don't think it's right to refactor all the public
>>>>>>> API javadoc which was referring to EntityEntry to now refer to the
>>>>>>> internal implementation.
>>>>>>> # things like EntityEntryExtraState should probably get moved to
>>>>>>> .internal packages as well now - we couldn't do that before without
>>>>>>> breaking either encapsulation or APIs.
>>>>>
>>>>> +1
>>>>>
>>>>>>>
>>>>>>> In terms of git patches, the complexity of the changeset risks to get
>>>>>>> a bit our of hand. What about we focus on creating a clean pull
>>>>>>> request which focuses exclusively on making EntityEntry an interface,
>>>>>>> and move things to the right packages and javadoc?
>>>>>
>>>>> Agree 100%
>>>>>
>>>>>>> You'd have a trivial EntitEntryFactory, and we can then build the
>>>>>>> evolution on top of that, not least maybe helping out by challenging
>>>>>>> some points in parallel work.
>>>>>>> These are the things I'd leave for a second iteration:
>>>>>>>   - add various implementations of EntityEntry iteratively, as needed
>>>>>>>   - the strategy such a Factory would use the pick an implementation
>>>>>>>   - ultimately, make it possible for an integrator to override such a
>>>>>>> Factory
>>>>>
>>>>>   This all seems reasonable.  For 5.0 I think the most important thing is
>>>>> to nail down the idea of EntityEntry as an interface, introduce a Factory
>>>>> for building them and agree on the signature for building them.  Granted we
>>>>> may need iteration to finalize the actual Factory signature, especially as
>>>>> OGM finally starts to use it, but I think that in general we can get it
>>>>> pretty close.  Worst case we just pass high-level constructs like the
>>>>> EntityPersister (which OGM supplies custom impls) and the Session and all
>>>>> the "EntityEntry state".  For the purpose of starting a discussion:
>>>>>
>>>>> public interface EntityEntryFactory {
>>>>>      public EntityEntry createEntityEntry(
>>>>>              PersistenceContext persistenceContext,
>>>>>              EntityPersister persister,
>>>>>              Status status,
>>>>>              Serializable id,
>>>>>              Object version,
>>>>>              Object[] loadedState,
>>>>>              Object rowId,
>>>>>              LockMode lockMode,
>>>>>              boolean existsInDatabase,
>>>>>              boolean disableVersionIncrement,
>>>>>              boolean lazyPropertiesAreUnfetched);
>>>>> }
>>>>>
>>>>> I would suggest a "creation context" method param object to pass in
>>>>> here, but seeing as how we are trying to stop instantiations...
>>>>>
>>>>> I would prefer the definition of the EntityEntryFactory to use be
>>>>> defined via SessionFactoryBuilder interface.  I already have plans to have a
>>>>> auto-loaded hook for integrators to be able to adjust the
>>>>> SessionFactoryBuilder.  But as a Service is fine too.
>>>>>
>>>>>>> For example with Hibernate OGM we might want to override / re
>>>>>>> configure the factories to use custom EntityEntry implementations -
>>>>>>> requirements are not fully clear at this point but it seems likely.
>>>>>>>
>>>>>>> The priority being to define the API as that would be a blocker for
>>>>>>> 5.0, we have then better choices to leave more smarter and advanced
>>>>>>> EntityEntry implementations for the future; we'd still need to
>>>>>>> implement at least the essential ones to make sure the API of the
>>>>>>> EntityEntryFactory has all the context it needs.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sanne
>>>>>>>
>>>>>>>
>>>>>>> On 24 March 2015 at 09:27, John O'Hara <johara at redhat.com> wrote:
>>>>>>>> Steve,
>>>>>>>>
>>>>>>>> Have you had chance to look at this? Do you have any
>>>>>>>> comments/observations?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>>
>>>>>>>> On 17/03/15 09:24, John O'Hara wrote:
>>>>>>>>
>>>>>>>> Steve,
>>>>>>>>
>>>>>>>> I have been having a think about the EntityEntry interface, and have
>>>>>>>> forked
>>>>>>>> a branch here:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/johnaoahra80/hibernate-orm/tree/EntityEntryInterface
>>>>>>>>
>>>>>>>> I know it is nowhere near complete, but was this the sort of idea
>>>>>>>> you had in
>>>>>>>> mind?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>>
>>>>>>>> On 13/03/15 09:44, John O'Hara wrote:
>>>>>>>>
>>>>>>>> EntityEntry retains a reference to a persistenceContext internally
>>>>>>>> that
>>>>>>>> org.hibernate.engine.spi.EntityEntry#setReadOnly makes calls to, is
>>>>>>>> this
>>>>>>>> where the session reference is kept?  As
>>>>>>>> org.hibernate.engine.spi.PersistenceConext is an interface could we
>>>>>>>> have a
>>>>>>>> different implementation for this use case? e.g. an
>>>>>>>> ImmutablePersistenceContext that could be shared across sessions?
>>>>>>>>
>>>>>>>> For the bytecode enhancement, could we change the enhancer so that
>>>>>>>> it adds
>>>>>>>> an EntityEntry interface with javassist.
>>>>>>>> ClassPool.javassist.ClassPool.makeInterface()() as opposed to adding
>>>>>>>> a class
>>>>>>>> javassist.ClassPool.makeClass()? I need to have a look at javassit
>>>>>>>> to
>>>>>>>> confirm what javassist.ClassPool.makeInterface() does.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>> On 12/03/15 18:52, Steve Ebersole wrote:
>>>>>>>>
>>>>>>>> It is possible.  Although some of the changes are particularly
>>>>>>>> painful.
>>>>>>>> Most of EntityEntry, if it is an interface, can be made to work with
>>>>>>>> your
>>>>>>>> use case.  org.hibernate.engine.spi.EntityEntry#setReadOnly I think
>>>>>>>> is the
>>>>>>>> one exception, because:
>>>>>>>> 1) your use case needs it
>>>>>>>> 2) it expects the Session to be available internally (its not
>>>>>>>> passed)
>>>>>>>>
>>>>>>>> The bigger thing I am worried about for you is the bytecode stuff,
>>>>>>>> as that
>>>>>>>> ties very tightly with EntityEntry.
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>
>>>>
>>>> --
>>>> John O'Hara
>>>> johara at redhat.com
>>>>
>>>> JBoss, by Red Hat
>>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
>>>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>>>> Registered in UK and Wales under Company Registration No. 3798903
>>>> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
>>>> (USA) and Michael O'Neill (Ireland).
>>>>
>>
>>
>> --
>> John O'Hara
>> johara at redhat.com
>>
>> JBoss, by Red Hat
>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street,
>> Windsor, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No. 3798903 Directors:
>> Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and
>> Michael O'Neill (Ireland).
>>


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).


From steve at hibernate.org  Fri Mar 27 09:43:06 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 27 Mar 2015 08:43:06 -0500
Subject: [hibernate-dev] Bytecode enhanced,
	Reference Cached immutable Entities
In-Reply-To: <5515570A.2090607@redhat.com>
References: <55003692.9080906@gmail.com>
	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>
	<5502B18F.4050403@redhat.com> <5507F2D4.8040202@redhat.com>
	<55112E1C.5030004@redhat.com>
	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>
	<CAFdSV9sFDr-984gFGGPxnU79u66YPAktonV9wJmfSjfp=Q3F6A@mail.gmail.com>
	<CAFdSV9tWjGTxq67QRJqXcyZWk1jgasWkdfrf0u=grhOg-JDXvQ@mail.gmail.com>
	<CAFdSV9sXO-BY-nK=eF0p4Fd_aKyQq1DgNMBWWtQO3VJ6SGexjQ@mail.gmail.com>
	<55153930.9070200@redhat.com>
	<CAFdSV9v-ZWa70n7sOiWt=3tAzy8j+VmWXG2c8YBnWo+Yr-05qA@mail.gmail.com>
	<CAFdSV9unqcZ0RyL+zkQhauQ9oauw99XuGV3O3Gg64u0Mq9Do1w@mail.gmail.com>
	<55154220.4010700@redhat.com>
	<CAFm4XO3OmLs2Xsgfmyn_BOoL8-9PB6+Kav-vJD0Vw8h-CYnr0A@mail.gmail.com>
	<5515570A.2090607@redhat.com>
Message-ID: <CAFdSV9s4L1Vaaj2uqTm+Q+_iHgvVsOif3KNLVKn2TvCNOvZUYg@mail.gmail.com>

The only distinction we care about is EntityPetsister#isMutable.  The
read-only case should be handled by the normal MutableEntityEntry.  In
other words there is nothing to pass to EntityPersister to make a decision
based on; just getEntityEntryBuilder ().

As far as LockMode, I think it makes the most sense to not do locking for
immutable entities.  Not sure if no-op or exception is the best way to
handle.  But regardless either way means we do not account for locking for
the immutable - entity EntityEntry.

Which brings up another point.  We should decide whether the
mutable/immutable in these names refers to the fact that the entity is
mutable/immutable or refers to the state of the EntityEntry itself.  I
think it is best to agree on that semantic now before we potentially start
using these in situations they were not designed for.
On Mar 27, 2015 8:11 AM, "John O'Hara" <johara at redhat.com> wrote:

>
>
> On 27/03/15 12:14, Sanne Grinovero wrote:
>
>> Also from OGM and Search perspective, we're not expecting any of this
>> to be backported.
>> It's not a functional blocker, "just" significant performance
>> improvements.
>>
>> How do we move further? John, I'm not familiar with the requirements
>> for the bytecode instrumentation, but can help a bit on the other
>> aspects. I could either work on extracting the patch of converting the
>> EntityEntry into an interface from your draft, or if you have time to
>> polish that I could review that PR. After that change is integrated,
>> it should be easier for us to work in parallel on different areas and
>> draft some ideas with the factory context idea.
>>
> I had started to work on extracting just the EntityEntryInterface and
> factory, so can continue on that. Which issue do we want to log this under.
> There is already HHH-9265?
>
>> +1 to an EntityPersister:EntityEntryFactory 1:1 relation, glad to see
>> it makes sense in your minds as well.
>>
>> To make a decision on the Immutable entities vs Read Only entities..
>> are we good in applying the optimisation only to Immutable entities or
>> do we need to find a way for entities which happen to be loaded
>> read-only too? I might have an idea to play with for that, but it
>> obviously gets a bit more complex.
>>
> I think for our case that we only need Immutable entities, not sure of any
> other scenarios where you would need to optimise Read Only entities
>
>>
>> @Steve, I guess we're looking at you for advice on what needs to be
>> done for the Lock state. I'm understanding that needs to be addressed
>> right?
>>
>> Thanks,
>> Sanne
>>
>>
>>
>>
>> On 27 March 2015 at 11:42, John O'Hara <johara at redhat.com> wrote:
>>
>>> Steve,
>>>
>>>  From our point of view, we would not be looking to backport any features
>>> introduced to any of the ORM4 releases. Our focus has shifted to the next
>>> major release of EAP as we have a number of issues we need to overcome.
>>> Getting this feature into ORM5 sooner rather than later is essential for
>>> our
>>> use case in the future.
>>>
>>> Thanks
>>>
>>> John
>>>
>>>
>>> On 27/03/15 11:36, Steve Ebersole wrote:
>>>
>>> BTW, if we go this route this *cannot* be backported because we do allow
>>> users to override EntityPersister; its an extension point.  Adding a new
>>> method to extension points in bugfixes is a no-no.
>>>
>>> On Fri, Mar 27, 2015 at 6:35 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> An EntityPersister describes each entity you defined in your model.  Its
>>>> one-to-one between @Entity and EntityPersister.  And really, it is
>>>> totally
>>>> reasonable to have the EntityPersister determine the "EntityEntry
>>>> builder"
>>>> to use.  That also eliminates needing to develop
>>>> yet-another-extension-point
>>>> because if we expose it from EntityPersister OGM already swaps
>>>> EntityPersister impls so this would JustWork.
>>>>
>>>> On Fri, Mar 27, 2015 at 6:04 AM, John O'Hara <johara at redhat.com> wrote:
>>>>
>>>>> On 26/03/15 16:22, Steve Ebersole wrote:
>>>>>
>>>>> The contract I suggested btw is missing one use case I know we have
>>>>> discussed in regards to OGM a few times... the ability to store
>>>>> references
>>>>> to datastore specific locators (I think the use case was to
>>>>> efficiently load
>>>>> collections through that datastore reference).  But that (obviously)
>>>>> requires passing extra, specific state into the createEntityEntry
>>>>> method.
>>>>> Not really sure the best way to handle such things tbh.
>>>>>
>>>>> If we did have a "creation Context" parameter passed to the
>>>>> createEntityEntry, we would be instantiating more objects, however if
>>>>> we
>>>>> went with Sanne' suggestion if caching the EnityEntryFactory with the
>>>>> EntityPersister, how many objects would be actually created?  I am not
>>>>> sure
>>>>> about the relationship between Entity, EntityEntry and Session but
>>>>> could
>>>>> this a possibility if there is a 1-1 relationship between
>>>>> EntityPersister
>>>>> and no. of different Entities definitions?
>>>>>
>>>>>
>>>>> On Thu, Mar 26, 2015 at 11:16 AM, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> Apparently I hit some key combo that means send :)  To finish up...
>>>>>>
>>>>>> On Thu, Mar 26, 2015 at 10:58 AM, Steve Ebersole <steve at hibernate.org
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <
>>>>>>> sanne at hibernate.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Concurrency
>>>>>>>>     Since the goal is to share the ImmutableEntityEntry instance
>>>>>>>> among
>>>>>>>> multiple threads reading it, I'd rather make sure that it is really
>>>>>>>> immutable. For example it now holds onto potentially lazy
>>>>>>>> initialized
>>>>>>>> fields, such as getEntityKey().
>>>>>>>> If it's not possible to make it really immutable (all final fields),
>>>>>>>> we'll need to make it threadsafe and question the name I'm
>>>>>>>> proposing.
>>>>>>>>
>>>>>>>
>>>>>>> The specific use-case John is interested in does indeed need to be
>>>>>>> completely thread-safe and fully concurrent.
>>>>>>>
>>>>>>>  LockMode
>>>>>>>>    From a logical perspective of users, one might think that an
>>>>>>>> entity
>>>>>>>> being "immutable" doesn't necessarily imply I can't lock on it..
>>>>>>>> right? I'm not sure how far it could be a valid use case, but these
>>>>>>>> patches are implying that one can't lock an immutable entity
>>>>>>>> anymore,
>>>>>>>> as the lock state would be as immutable as anything else on the
>>>>>>>> EntityEntry.
>>>>>>>> Are we good with that? Alternatively one might need to think to
>>>>>>>> separate the lock state handling from the EntityEntry.
>>>>>>>>
>>>>>>>
>>>>>>> Conceptually there is nothing wrong with requesting a READ lock on an
>>>>>>> immutable entity.  But like you said, what is the logical
>>>>>>> expectation there?
>>>>>>> IMO there should be none.  But if we decide that it is OK to req
>>>>>>>
>>>>>>
>>>>>> But if we decide that it is OK to request a lock on an immutable
>>>>>> entity,
>>>>>> that is problematic for the idea of a "SharedEntityEntry" or an
>>>>>> "ImmutableEntityEntry" because a lock is associated with a Session
>>>>>> which is
>>>>>> what the EntityEntry is meant to model... an entity's information in
>>>>>> relation to a Session.  Aka, it now needs to hold state.
>>>>>>
>>>>>>
>>>>>>  Notice I said immutable here and not READ_ONLY which is a specific
>>>>>>> distinction which is important to other parts of your email that I
>>>>>>> will
>>>>>>> address in a second email.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On smaller details:
>>>>>>>> # org.hibernate.engine.internal.SharedEntityEntry is hosted in an
>>>>>>>> .internal package, I don't think it's right to refactor all the
>>>>>>>> public
>>>>>>>> API javadoc which was referring to EntityEntry to now refer to the
>>>>>>>> internal implementation.
>>>>>>>> # things like EntityEntryExtraState should probably get moved to
>>>>>>>> .internal packages as well now - we couldn't do that before without
>>>>>>>> breaking either encapsulation or APIs.
>>>>>>>>
>>>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>>>> In terms of git patches, the complexity of the changeset risks to
>>>>>>>> get
>>>>>>>> a bit our of hand. What about we focus on creating a clean pull
>>>>>>>> request which focuses exclusively on making EntityEntry an
>>>>>>>> interface,
>>>>>>>> and move things to the right packages and javadoc?
>>>>>>>>
>>>>>>>
>>>>>> Agree 100%
>>>>>>
>>>>>>  You'd have a trivial EntitEntryFactory, and we can then build the
>>>>>>>> evolution on top of that, not least maybe helping out by challenging
>>>>>>>> some points in parallel work.
>>>>>>>> These are the things I'd leave for a second iteration:
>>>>>>>>   - add various implementations of EntityEntry iteratively, as
>>>>>>>> needed
>>>>>>>>   - the strategy such a Factory would use the pick an implementation
>>>>>>>>   - ultimately, make it possible for an integrator to override such
>>>>>>>> a
>>>>>>>> Factory
>>>>>>>>
>>>>>>>
>>>>>>   This all seems reasonable.  For 5.0 I think the most important
>>>>>> thing is
>>>>>> to nail down the idea of EntityEntry as an interface, introduce a
>>>>>> Factory
>>>>>> for building them and agree on the signature for building them.
>>>>>> Granted we
>>>>>> may need iteration to finalize the actual Factory signature,
>>>>>> especially as
>>>>>> OGM finally starts to use it, but I think that in general we can get
>>>>>> it
>>>>>> pretty close.  Worst case we just pass high-level constructs like the
>>>>>> EntityPersister (which OGM supplies custom impls) and the Session and
>>>>>> all
>>>>>> the "EntityEntry state".  For the purpose of starting a discussion:
>>>>>>
>>>>>> public interface EntityEntryFactory {
>>>>>>      public EntityEntry createEntityEntry(
>>>>>>              PersistenceContext persistenceContext,
>>>>>>              EntityPersister persister,
>>>>>>              Status status,
>>>>>>              Serializable id,
>>>>>>              Object version,
>>>>>>              Object[] loadedState,
>>>>>>              Object rowId,
>>>>>>              LockMode lockMode,
>>>>>>              boolean existsInDatabase,
>>>>>>              boolean disableVersionIncrement,
>>>>>>              boolean lazyPropertiesAreUnfetched);
>>>>>> }
>>>>>>
>>>>>> I would suggest a "creation context" method param object to pass in
>>>>>> here, but seeing as how we are trying to stop instantiations...
>>>>>>
>>>>>> I would prefer the definition of the EntityEntryFactory to use be
>>>>>> defined via SessionFactoryBuilder interface.  I already have plans to
>>>>>> have a
>>>>>> auto-loaded hook for integrators to be able to adjust the
>>>>>> SessionFactoryBuilder.  But as a Service is fine too.
>>>>>>
>>>>>>  For example with Hibernate OGM we might want to override / re
>>>>>>>> configure the factories to use custom EntityEntry implementations -
>>>>>>>> requirements are not fully clear at this point but it seems likely.
>>>>>>>>
>>>>>>>> The priority being to define the API as that would be a blocker for
>>>>>>>> 5.0, we have then better choices to leave more smarter and advanced
>>>>>>>> EntityEntry implementations for the future; we'd still need to
>>>>>>>> implement at least the essential ones to make sure the API of the
>>>>>>>> EntityEntryFactory has all the context it needs.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Sanne
>>>>>>>>
>>>>>>>>
>>>>>>>> On 24 March 2015 at 09:27, John O'Hara <johara at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Steve,
>>>>>>>>>
>>>>>>>>> Have you had chance to look at this? Do you have any
>>>>>>>>> comments/observations?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 17/03/15 09:24, John O'Hara wrote:
>>>>>>>>>
>>>>>>>>> Steve,
>>>>>>>>>
>>>>>>>>> I have been having a think about the EntityEntry interface, and
>>>>>>>>> have
>>>>>>>>> forked
>>>>>>>>> a branch here:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/johnaoahra80/hibernate-orm/
>>>>>>>>> tree/EntityEntryInterface
>>>>>>>>>
>>>>>>>>> I know it is nowhere near complete, but was this the sort of idea
>>>>>>>>> you had in
>>>>>>>>> mind?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 13/03/15 09:44, John O'Hara wrote:
>>>>>>>>>
>>>>>>>>> EntityEntry retains a reference to a persistenceContext internally
>>>>>>>>> that
>>>>>>>>> org.hibernate.engine.spi.EntityEntry#setReadOnly makes calls to,
>>>>>>>>> is
>>>>>>>>> this
>>>>>>>>> where the session reference is kept?  As
>>>>>>>>> org.hibernate.engine.spi.PersistenceConext is an interface could
>>>>>>>>> we
>>>>>>>>> have a
>>>>>>>>> different implementation for this use case? e.g. an
>>>>>>>>> ImmutablePersistenceContext that could be shared across sessions?
>>>>>>>>>
>>>>>>>>> For the bytecode enhancement, could we change the enhancer so that
>>>>>>>>> it adds
>>>>>>>>> an EntityEntry interface with javassist.
>>>>>>>>> ClassPool.javassist.ClassPool.makeInterface()() as opposed to
>>>>>>>>> adding
>>>>>>>>> a class
>>>>>>>>> javassist.ClassPool.makeClass()? I need to have a look at javassit
>>>>>>>>> to
>>>>>>>>> confirm what javassist.ClassPool.makeInterface() does.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>> On 12/03/15 18:52, Steve Ebersole wrote:
>>>>>>>>>
>>>>>>>>> It is possible.  Although some of the changes are particularly
>>>>>>>>> painful.
>>>>>>>>> Most of EntityEntry, if it is an interface, can be made to work
>>>>>>>>> with
>>>>>>>>> your
>>>>>>>>> use case.  org.hibernate.engine.spi.EntityEntry#setReadOnly I
>>>>>>>>> think
>>>>>>>>> is the
>>>>>>>>> one exception, because:
>>>>>>>>> 1) your use case needs it
>>>>>>>>> 2) it expects the Session to be available internally (its not
>>>>>>>>> passed)
>>>>>>>>>
>>>>>>>>> The bigger thing I am worried about for you is the bytecode stuff,
>>>>>>>>> as that
>>>>>>>>> ties very tightly with EntityEntry.
>>>>>>>>>
>>>>>>>>>  _______________________________________________
>>>>>>>> hibernate-dev mailing list
>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> John O'Hara
>>>>> johara at redhat.com
>>>>>
>>>>> JBoss, by Red Hat
>>>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
>>>>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>>>>> Registered in UK and Wales under Company Registration No. 3798903
>>>>> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
>>>>> (USA) and Michael O'Neill (Ireland).
>>>>>
>>>>>
>>>
>>> --
>>> John O'Hara
>>> johara at redhat.com
>>>
>>> JBoss, by Red Hat
>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
>>> Street,
>>> Windsor, Berkshire, SI4 1TE, United Kingdom.
>>> Registered in UK and Wales under Company Registration No. 3798903
>>> Directors:
>>> Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and
>>> Michael O'Neill (Ireland).
>>>
>>>
>
> --
> John O'Hara
> johara at redhat.com
>
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
> (USA) and Michael O'Neill (Ireland).
>
>

From johara at redhat.com  Fri Mar 27 10:22:20 2015
From: johara at redhat.com (John O'Hara)
Date: Fri, 27 Mar 2015 14:22:20 +0000
Subject: [hibernate-dev] Bytecode enhanced,
 Reference Cached immutable Entities
In-Reply-To: <CAFdSV9s4L1Vaaj2uqTm+Q+_iHgvVsOif3KNLVKn2TvCNOvZUYg@mail.gmail.com>
References: <55003692.9080906@gmail.com>	<CAFdSV9vWnV3M8TynMpqwnYiBa+j9_kQ0Lfmv1TXue4+sacmZ=A@mail.gmail.com>	<5502B18F.4050403@redhat.com>	<5507F2D4.8040202@redhat.com>	<55112E1C.5030004@redhat.com>	<CAFm4XO2xWt7MRD9dS3XtWksvLpHZDygA4pmAGhEu_GXV=X8HcQ@mail.gmail.com>	<CAFdSV9sFDr-984gFGGPxnU79u66YPAktonV9wJmfSjfp=Q3F6A@mail.gmail.com>	<CAFdSV9tWjGTxq67QRJqXcyZWk1jgasWkdfrf0u=grhOg-JDXvQ@mail.gmail.com>	<CAFdSV9sXO-BY-nK=eF0p4Fd_aKyQq1DgNMBWWtQO3VJ6SGexjQ@mail.gmail.com>	<55153930.9070200@redhat.com>	<CAFdSV9v-ZWa70n7sOiWt=3tAzy8j+VmWXG2c8YBnWo+Yr-05qA@mail.gmail.com>	<CAFdSV9unqcZ0RyL+zkQhauQ9oauw99XuGV3O3Gg64u0Mq9Do1w@mail.gmail.com>	<55154220.4010700@redhat.com>	<CAFm4XO3OmLs2Xsgfmyn_BOoL8-9PB6+Kav-vJD0Vw8h-CYnr0A@mail.gmail.com>	<5515570A.2090607@redhat.com>
	<CAFdSV9s4L1Vaaj2uqTm+Q+_iHgvVsOif3KNLVKn2TvCNOvZUYg@mail.gmail.com>
Message-ID: <5515679C.2000502@redhat.com>

I had been working on the assumption that the entity is mutable/immutable.

Is it possible for EntityEntry to be immutable? e.g. is it valid for 
states such as BooleanState.IS_BEING_REPLICATED or 
BooleanState.LOADED_WITH_LAZY_PROPERTIES_UNFETCHED to change during the 
lifetime of the EntityEntry object?


On 27/03/15 13:43, Steve Ebersole wrote:
>
> The only distinction we care about is EntityPetsister#isMutable.  The 
> read-only case should be handled by the normal MutableEntityEntry.  In 
> other words there is nothing to pass to EntityPersister to make a 
> decision based on; just getEntityEntryBuilder ().
>
> As far as LockMode, I think it makes the most sense to not do locking 
> for immutable entities.  Not sure if no-op or exception is the best 
> way to handle.  But regardless either way means we do not account for 
> locking for the immutable - entity EntityEntry.
>
> Which brings up another point.  We should decide whether the 
> mutable/immutable in these names refers to the fact that the entity is 
> mutable/immutable or refers to the state of the EntityEntry itself.  I 
> think it is best to agree on that semantic now before we potentially 
> start using these in situations they were not designed for.
>


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).


From steve at hibernate.org  Fri Mar 27 17:01:57 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 27 Mar 2015 16:01:57 -0500
Subject: [hibernate-dev] ORM Jenkins Builds
Message-ID: <CAFdSV9tby1xjSQCVD7nWp+y8hV7K+JLy-8P156QmKQ4-32mOzw@mail.gmail.com>

I was curious why it took so long to run the master ORM jobs on the CI
machine compared to running the job locally.  Locally I run `clean test` at
the root prject quite often and it takes roughly 9-10 minutes.  The master
CI jobs generally take 45-50 minutes to complete.

So I enabled "Gradle build profiling" in our job.  The results were
surprising in terms of ratios.

I figured findBugs, checkStyle etc probably added significant times to the
build.  But I was shocked how much it added.

BTW, you can view these profile reports in {root}/build/reports/profile...

So hibernate-core, overall took 17m22.19s to run for one job.  Of that,
12.5 was findBugs!  checkStyle as actually "reasonable" at just under 30s.
The ratios were similar across all modules.

The aggregatedJavadoc task took a shade over 2m.

Considering that these jobs are run on ever check-in (and eventually it
would be great to auto-run them against PRs too), plus the fact that we
aren't even failing the build for the majority of findBug/checkStyle hits I
think we should define these jobs a little differently.  Its not just the
time it takes.  Yes we all hate to wait.  But it's also the CI resources
taken up.

I'm going to put some thought into this after the 5.0 Beta release, but I
wanted to get some thoughts and feedback in the meantime.  Things to
consider.

From sanne at hibernate.org  Fri Mar 27 17:38:55 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 27 Mar 2015 21:38:55 +0000
Subject: [hibernate-dev] ORM Jenkins Builds
In-Reply-To: <CAFdSV9tby1xjSQCVD7nWp+y8hV7K+JLy-8P156QmKQ4-32mOzw@mail.gmail.com>
References: <CAFdSV9tby1xjSQCVD7nWp+y8hV7K+JLy-8P156QmKQ4-32mOzw@mail.gmail.com>
Message-ID: <CAFm4XO29_ECFBV5mzZFttOt==F2xpBywp79VpxggtenvV7x3Ng@mail.gmail.com>

Hi Steve,
don't worry for the resources they consume. Each build job which we
run is fully isolated and running on independent hardware, so it's not
going to slow down any other build.

Since we now have a set of small servers, one each dedicated for a job
at a time, I've opted for low spec machines as an experiment. This
performance is however disappointing, we can try different types of
CPU/Memory/Disk categories.

The current specs of each build node are:
 2 CPUs
 3 GB of RAM
 18GB of root disk (of which 9GB available for our builds)
 50GB available to run various docker images and temporary databases
(allocated per job need)

They run Fedora 21, Cloud Edition.

As you can see, resources on a single build node are very limited -
especially space and memory.
But since there is no swap space configured (!) I expect that in case
the memory is not enough, it will crash (and therefore let us know)
rather than slow down.
It's possible though that since the ORM builds allocate 2GB of heap,
we're preventing the operating system from doing proper filesystem
caching.

currently we have:
GRADLE_OPTS="-Xmx2G -Xms2G -XX:MaxPermSize=512m"

I'm going to try to lower that, bear with me if there are failures. If
that doesn't work we can definitely replace these with larger
instances, it should take us just some minutes as it's all automated:
the only reason for me to be conservative is to make fair use of these
(free) resource, and also I'd like us to actually test for not needing
much ram - we can get there in smaller steps as needed of course.

Sanne

On 27 March 2015 at 21:01, Steve Ebersole <steve at hibernate.org> wrote:
> I was curious why it took so long to run the master ORM jobs on the CI
> machine compared to running the job locally.  Locally I run `clean test` at
> the root prject quite often and it takes roughly 9-10 minutes.  The master
> CI jobs generally take 45-50 minutes to complete.
>
> So I enabled "Gradle build profiling" in our job.  The results were
> surprising in terms of ratios.
>
> I figured findBugs, checkStyle etc probably added significant times to the
> build.  But I was shocked how much it added.
>
> BTW, you can view these profile reports in {root}/build/reports/profile...
>
> So hibernate-core, overall took 17m22.19s to run for one job.  Of that,
> 12.5 was findBugs!  checkStyle as actually "reasonable" at just under 30s.
> The ratios were similar across all modules.
>
> The aggregatedJavadoc task took a shade over 2m.
>
> Considering that these jobs are run on ever check-in (and eventually it
> would be great to auto-run them against PRs too), plus the fact that we
> aren't even failing the build for the majority of findBug/checkStyle hits I
> think we should define these jobs a little differently.  Its not just the
> time it takes.  Yes we all hate to wait.  But it's also the CI resources
> taken up.
>
> I'm going to put some thought into this after the 5.0 Beta release, but I
> wanted to get some thoughts and feedback in the meantime.  Things to
> consider.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Fri Mar 27 18:25:32 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 27 Mar 2015 17:25:32 -0500
Subject: [hibernate-dev] ORM Jenkins Builds
In-Reply-To: <CAFm4XO29_ECFBV5mzZFttOt==F2xpBywp79VpxggtenvV7x3Ng@mail.gmail.com>
References: <CAFdSV9tby1xjSQCVD7nWp+y8hV7K+JLy-8P156QmKQ4-32mOzw@mail.gmail.com>
	<CAFm4XO29_ECFBV5mzZFttOt==F2xpBywp79VpxggtenvV7x3Ng@mail.gmail.com>
Message-ID: <CAFdSV9t3k_0PkoHWE43qOJ9=OsxszFPcMFZQ=YzhO9n-Rm1+wQ@mail.gmail.com>

We should remove that -XX:MaxPermSize=512m setting as we discussed before.

I understand all of that.  I still think its probably worthwhile to look at
minimizing the amount of time and resources.  For a couple of reasons.
First I am doing a lot of dev right now.  In the 40-50 minutes it takes to
run the CI job after a push I often have other pushes queued up.  Then when
that first jobs fails, I need to go back and shift gears back into that
first issue again.  And spending roughly 75-80% of that time in a task that
we don't even fail the build for seems excessive.

My preliminary thinking here is to define a more than one job.  Setting
aside the idea of db-jobs for the moment...

1) Per-push job - triggered by push
a) runs tests
b) simplified checks (findbugs, checkstyle) that we actually fail the build
for
c) publish

2) Nightly build - triggered nightly (only with change in source?)
a) full checks (both failures and warnings)
b) aggregated javadocs

* I'd actually like the nightly build to trigger once a day when a push
actually occured.  Not sure that is possible.

The "per-push" job really is a "main" one meant to run against H2.  We
still need to set up the db specific jobs:

3) DB job - triggered on successful execution of (1)?
a) run tests

And ultimately I'd love to setup some jobs for JDK testing that pull the
artifacts built by (1) and tests them in a different JDK.  Currently we
need the Java 8 JDK to do a full build of ORM (JSR 310 support).  For the
modules other than hibernate-java8 we set source and target compatibility
to Java 6.  We could simply set up some jobs that use Java 6 JDK for the
build, but that's not quite the same as pulling the artifacts built using
Java 8 and targetting Java 6 and trying to run those in Java 6 or 7
environment.  I don't know if Gradle has any existing support for this or
whether this is another plugin I will have to develop to make that happen.


On Fri, Mar 27, 2015 at 4:38 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hi Steve,
> don't worry for the resources they consume. Each build job which we
> run is fully isolated and running on independent hardware, so it's not
> going to slow down any other build.
>
> Since we now have a set of small servers, one each dedicated for a job
> at a time, I've opted for low spec machines as an experiment. This
> performance is however disappointing, we can try different types of
> CPU/Memory/Disk categories.
>
> The current specs of each build node are:
>  2 CPUs
>  3 GB of RAM
>  18GB of root disk (of which 9GB available for our builds)
>  50GB available to run various docker images and temporary databases
> (allocated per job need)
>
> They run Fedora 21, Cloud Edition.
>
> As you can see, resources on a single build node are very limited -
> especially space and memory.
> But since there is no swap space configured (!) I expect that in case
> the memory is not enough, it will crash (and therefore let us know)
> rather than slow down.
> It's possible though that since the ORM builds allocate 2GB of heap,
> we're preventing the operating system from doing proper filesystem
> caching.
>
> currently we have:
> GRADLE_OPTS="-Xmx2G -Xms2G -XX:MaxPermSize=512m"
>
> I'm going to try to lower that, bear with me if there are failures. If
> that doesn't work we can definitely replace these with larger
> instances, it should take us just some minutes as it's all automated:
> the only reason for me to be conservative is to make fair use of these
> (free) resource, and also I'd like us to actually test for not needing
> much ram - we can get there in smaller steps as needed of course.
>
> Sanne
>
> On 27 March 2015 at 21:01, Steve Ebersole <steve at hibernate.org> wrote:
> > I was curious why it took so long to run the master ORM jobs on the CI
> > machine compared to running the job locally.  Locally I run `clean test`
> at
> > the root prject quite often and it takes roughly 9-10 minutes.  The
> master
> > CI jobs generally take 45-50 minutes to complete.
> >
> > So I enabled "Gradle build profiling" in our job.  The results were
> > surprising in terms of ratios.
> >
> > I figured findBugs, checkStyle etc probably added significant times to
> the
> > build.  But I was shocked how much it added.
> >
> > BTW, you can view these profile reports in
> {root}/build/reports/profile...
> >
> > So hibernate-core, overall took 17m22.19s to run for one job.  Of that,
> > 12.5 was findBugs!  checkStyle as actually "reasonable" at just under
> 30s.
> > The ratios were similar across all modules.
> >
> > The aggregatedJavadoc task took a shade over 2m.
> >
> > Considering that these jobs are run on ever check-in (and eventually it
> > would be great to auto-run them against PRs too), plus the fact that we
> > aren't even failing the build for the majority of findBug/checkStyle
> hits I
> > think we should define these jobs a little differently.  Its not just the
> > time it takes.  Yes we all hate to wait.  But it's also the CI resources
> > taken up.
> >
> > I'm going to put some thought into this after the 5.0 Beta release, but I
> > wanted to get some thoughts and feedback in the meantime.  Things to
> > consider.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Sat Mar 28 12:26:42 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 28 Mar 2015 16:26:42 +0000
Subject: [hibernate-dev] ORM Jenkins Builds
In-Reply-To: <CAFdSV9t3k_0PkoHWE43qOJ9=OsxszFPcMFZQ=YzhO9n-Rm1+wQ@mail.gmail.com>
References: <CAFdSV9tby1xjSQCVD7nWp+y8hV7K+JLy-8P156QmKQ4-32mOzw@mail.gmail.com>
	<CAFm4XO29_ECFBV5mzZFttOt==F2xpBywp79VpxggtenvV7x3Ng@mail.gmail.com>
	<CAFdSV9t3k_0PkoHWE43qOJ9=OsxszFPcMFZQ=YzhO9n-Rm1+wQ@mail.gmail.com>
Message-ID: <CAFm4XO27HoCwbo9w2t-dqFjxmnRR-J-XvQ4J8JRk01L2UMSsew@mail.gmail.com>

On 27 March 2015 at 22:25, Steve Ebersole <steve at hibernate.org> wrote:
> We should remove that -XX:MaxPermSize=512m setting as we discussed before.

I've changed this to:
-server -Xmx2G -Xms800M  -Djava.net.preferIPv4Stack=true
-Djgroups.bind_addr=127.0.0.1 -XX:+PrintTenuringDistribution
-XX:+PrintGCDetails -Xloggc:/home/jenkins/gradle-gcdetails.log
-XX:+PrintFlagsFinal -XX:NewRatio=1 -XX:+UseG1GC

The logging option should not slow down significantly, but let us know
if there ever are issues with heap memory.


> I understand all of that.  I still think its probably worthwhile to look at
> minimizing the amount of time and resources.  For a couple of reasons.
> First I am doing a lot of dev right now.  In the 40-50 minutes it takes to
> run the CI job after a push I often have other pushes queued up.  Then when
> that first jobs fails, I need to go back and shift gears back into that
> first issue again.  And spending roughly 75-80% of that time in a task that
> we don't even fail the build for seems excessive.
>
> My preliminary thinking here is to define a more than one job.  Setting
> aside the idea of db-jobs for the moment...
>
> 1) Per-push job - triggered by push
> a) runs tests
> b) simplified checks (findbugs, checkstyle) that we actually fail the build
> for
> c) publish
>
> 2) Nightly build - triggered nightly (only with change in source?)
> a) full checks (both failures and warnings)
> b) aggregated javadocs
>
> * I'd actually like the nightly build to trigger once a day when a push
> actually occured.  Not sure that is possible.

+1, feel free to create as many jobs as needed. There is a "clone job"
option which I've found handy.

> The "per-push" job really is a "main" one meant to run against H2.  We still
> need to set up the db specific jobs:

Right, I even suspect that using the locally installed MySQL or
PostgreSQL instances could result in faster builds than with H2

>
> 3) DB job - triggered on successful execution of (1)?
> a) run tests
>
> And ultimately I'd love to setup some jobs for JDK testing that pull the
> artifacts built by (1) and tests them in a different JDK.  Currently we need
> the Java 8 JDK to do a full build of ORM (JSR 310 support).  For the modules
> other than hibernate-java8 we set source and target compatibility to Java 6.
> We could simply set up some jobs that use Java 6 JDK for the build, but
> that's not quite the same as pulling the artifacts built using Java 8 and
> targetting Java 6 and trying to run those in Java 6 or 7 environment.  I
> don't know if Gradle has any existing support for this or whether this is
> another plugin I will have to develop to make that happen.

Consider also that since we now have N slaves, there is no guarantee
that a second job will run on the same build slave.
So if the JDK8 build produces artifacts but only deployes them in the
local repository, the second node might not find the same as it has an
independent repository cache.
One way would be to actually upload the snapshots to the jboss Nexus,
but it could be easier / more efficient to have a single job which
does the compilation & packaging only with JDK8 but then runs the
tests with JDK6 ?
The JDK paths are well defined, so that should be scriptable with a
couple of sequential invocations to Gradle?

Sanne

>
>
> On Fri, Mar 27, 2015 at 4:38 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Hi Steve,
>> don't worry for the resources they consume. Each build job which we
>> run is fully isolated and running on independent hardware, so it's not
>> going to slow down any other build.
>>
>> Since we now have a set of small servers, one each dedicated for a job
>> at a time, I've opted for low spec machines as an experiment. This
>> performance is however disappointing, we can try different types of
>> CPU/Memory/Disk categories.
>>
>> The current specs of each build node are:
>>  2 CPUs
>>  3 GB of RAM
>>  18GB of root disk (of which 9GB available for our builds)
>>  50GB available to run various docker images and temporary databases
>> (allocated per job need)
>>
>> They run Fedora 21, Cloud Edition.
>>
>> As you can see, resources on a single build node are very limited -
>> especially space and memory.
>> But since there is no swap space configured (!) I expect that in case
>> the memory is not enough, it will crash (and therefore let us know)
>> rather than slow down.
>> It's possible though that since the ORM builds allocate 2GB of heap,
>> we're preventing the operating system from doing proper filesystem
>> caching.
>>
>> currently we have:
>> GRADLE_OPTS="-Xmx2G -Xms2G -XX:MaxPermSize=512m"
>>
>> I'm going to try to lower that, bear with me if there are failures. If
>> that doesn't work we can definitely replace these with larger
>> instances, it should take us just some minutes as it's all automated:
>> the only reason for me to be conservative is to make fair use of these
>> (free) resource, and also I'd like us to actually test for not needing
>> much ram - we can get there in smaller steps as needed of course.
>>
>> Sanne
>>
>> On 27 March 2015 at 21:01, Steve Ebersole <steve at hibernate.org> wrote:
>> > I was curious why it took so long to run the master ORM jobs on the CI
>> > machine compared to running the job locally.  Locally I run `clean test`
>> > at
>> > the root prject quite often and it takes roughly 9-10 minutes.  The
>> > master
>> > CI jobs generally take 45-50 minutes to complete.
>> >
>> > So I enabled "Gradle build profiling" in our job.  The results were
>> > surprising in terms of ratios.
>> >
>> > I figured findBugs, checkStyle etc probably added significant times to
>> > the
>> > build.  But I was shocked how much it added.
>> >
>> > BTW, you can view these profile reports in
>> > {root}/build/reports/profile...
>> >
>> > So hibernate-core, overall took 17m22.19s to run for one job.  Of that,
>> > 12.5 was findBugs!  checkStyle as actually "reasonable" at just under
>> > 30s.
>> > The ratios were similar across all modules.
>> >
>> > The aggregatedJavadoc task took a shade over 2m.
>> >
>> > Considering that these jobs are run on ever check-in (and eventually it
>> > would be great to auto-run them against PRs too), plus the fact that we
>> > aren't even failing the build for the majority of findBug/checkStyle
>> > hits I
>> > think we should define these jobs a little differently.  Its not just
>> > the
>> > time it takes.  Yes we all hate to wait.  But it's also the CI resources
>> > taken up.
>> >
>> > I'm going to put some thought into this after the 5.0 Beta release, but
>> > I
>> > wanted to get some thoughts and feedback in the meantime.  Things to
>> > consider.
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Sat Mar 28 12:46:36 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 28 Mar 2015 11:46:36 -0500
Subject: [hibernate-dev] ORM Jenkins Builds
In-Reply-To: <CAFm4XO27HoCwbo9w2t-dqFjxmnRR-J-XvQ4J8JRk01L2UMSsew@mail.gmail.com>
References: <CAFdSV9tby1xjSQCVD7nWp+y8hV7K+JLy-8P156QmKQ4-32mOzw@mail.gmail.com>
	<CAFm4XO29_ECFBV5mzZFttOt==F2xpBywp79VpxggtenvV7x3Ng@mail.gmail.com>
	<CAFdSV9t3k_0PkoHWE43qOJ9=OsxszFPcMFZQ=YzhO9n-Rm1+wQ@mail.gmail.com>
	<CAFm4XO27HoCwbo9w2t-dqFjxmnRR-J-XvQ4J8JRk01L2UMSsew@mail.gmail.com>
Message-ID: <CAFdSV9vgESmEn-u5AGfJFP3Dax+idzF3qQ87HeD1YnwCxAofwQ@mail.gmail.com>

On Sat, Mar 28, 2015 at 11:26 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:
>
> Consider also that since we now have N slaves, there is no guarantee
> that a second job will run on the same build slave.
> So if the JDK8 build produces artifacts but only deployes them in the
> local repository, the second node might not find the same as it has an
> independent repository cache.
>

This is one of the major differences between Gradle and Maven.  Gradle has
no idea about a "local repository" in terms of publishing.  These jobs, if
they publish, always publish to Nexus.

We added the ability to read artifacts from "Maven local" mainly to deal
with cases where we have local Maven-built projects that we want to have
ORM pick up a local snapshot of.  HCANN was the main thing here.  But the
"Gradle way" is to have the "other" local project (e.g., HCANN) publish its
SNAPSHOT to Nexus and for the ORM build to pick it up from there.

More repeatable builds that way.  You pointed out one such scenario.  Of
course locally, Gradle (with some help usually) also lets you aggregate
these disparate projects together into one cohesive build.

And given that IIRC I converted HCANN to use Gradle for building as well,
maybe its time to pull that ability.


One way would be to actually upload the snapshots to the jboss Nexus,
> but it could be easier / more efficient to have a single job which
> does the compilation & packaging only with JDK8 but then runs the
> tests with JDK6 ?
> The JDK paths are well defined, so that should be scriptable with a
> couple of sequential invocations to Gradle?


That is another option for sure.  And actually it does not even have to be
separate invocations.  We could script the creation of a new Test task
based on the configured JDK6 path and just have both run in the same Gradle
build.

From steve at hibernate.org  Sat Mar 28 15:10:44 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 28 Mar 2015 14:10:44 -0500
Subject: [hibernate-dev] ORM Jenkins Builds
In-Reply-To: <CAFdSV9vgESmEn-u5AGfJFP3Dax+idzF3qQ87HeD1YnwCxAofwQ@mail.gmail.com>
References: <CAFdSV9tby1xjSQCVD7nWp+y8hV7K+JLy-8P156QmKQ4-32mOzw@mail.gmail.com>
	<CAFm4XO29_ECFBV5mzZFttOt==F2xpBywp79VpxggtenvV7x3Ng@mail.gmail.com>
	<CAFdSV9t3k_0PkoHWE43qOJ9=OsxszFPcMFZQ=YzhO9n-Rm1+wQ@mail.gmail.com>
	<CAFm4XO27HoCwbo9w2t-dqFjxmnRR-J-XvQ4J8JRk01L2UMSsew@mail.gmail.com>
	<CAFdSV9vgESmEn-u5AGfJFP3Dax+idzF3qQ87HeD1YnwCxAofwQ@mail.gmail.com>
Message-ID: <CAFdSV9t7ESOa_kCyThU4+R4HYiXkuLv2eFUdz+F0HiYHdo7ymg@mail.gmail.com>

Gradle really is quite elegant in most cases:

if ( project.name != 'hibernate-java8' && rootProject.hasProperty(
"JDK6_HOME" ) ) {
final File java6Home = new File( rootProject.property( "JDK6_HOME" ) as
String );
final org.gradle.internal.jvm.Jvm java6Jdk =
org.gradle.internal.jvm.Jvm.forHome( java6Home ) as
org.gradle.internal.jvm.Jvm;
if ( !java6Jdk.javaVersion.java6 ) {
throw new GradleException( "JDK6_HOME (if set) must point to a Java 1.6
home, found ${java6Jdk.javaVersion}" );
}
final Test mainTestTask = subProject.tasks.test as Test;
task testWithJdk6(type:Test) {
inputs = mainTestTask.inputs
outputs = mainTestTask.outputs

if ( java6Jdk.toolsJar ) {
bootstrapClasspath java6Jdk.toolsJar
}

classpath = java6Jdk.runtimeJar + mainTestTask.classpath
executable = java6Jdk.javaExecutable

// should we recompile the tests using JDK6?  If so, set a different
classes dir
// here and clone new JavaCompile task for tests.  But just running with
the Java 6
// JRE should be enough
testClassesDir = mainTestTask.testClassesDir
testSrcDirs = mainTestTask.testSrcDirs

enableAssertions = mainTestTask.enableAssertions
environment = mainTestTask.environment
systemProperties = mainTestTask.systemProperties
scanForTestClasses = mainTestTask.scanForTestClasses
includes = mainTestTask.includes
excludes = mainTestTask.excludes
jvmArgs = mainTestTask.jvmArgs
maxHeapSize = mainTestTask.maxHeapSize
minHeapSize = mainTestTask.minHeapSize
}
}

On Sat, Mar 28, 2015 at 11:46 AM, Steve Ebersole <steve at hibernate.org>
wrote:

> On Sat, Mar 28, 2015 at 11:26 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Consider also that since we now have N slaves, there is no guarantee
>> that a second job will run on the same build slave.
>> So if the JDK8 build produces artifacts but only deployes them in the
>> local repository, the second node might not find the same as it has an
>> independent repository cache.
>>
>
> This is one of the major differences between Gradle and Maven.  Gradle has
> no idea about a "local repository" in terms of publishing.  These jobs, if
> they publish, always publish to Nexus.
>
> We added the ability to read artifacts from "Maven local" mainly to deal
> with cases where we have local Maven-built projects that we want to have
> ORM pick up a local snapshot of.  HCANN was the main thing here.  But the
> "Gradle way" is to have the "other" local project (e.g., HCANN) publish its
> SNAPSHOT to Nexus and for the ORM build to pick it up from there.
>
> More repeatable builds that way.  You pointed out one such scenario.  Of
> course locally, Gradle (with some help usually) also lets you aggregate
> these disparate projects together into one cohesive build.
>
> And given that IIRC I converted HCANN to use Gradle for building as well,
> maybe its time to pull that ability.
>
>
> One way would be to actually upload the snapshots to the jboss Nexus,
>> but it could be easier / more efficient to have a single job which
>> does the compilation & packaging only with JDK8 but then runs the
>> tests with JDK6 ?
>> The JDK paths are well defined, so that should be scriptable with a
>> couple of sequential invocations to Gradle?
>
>
> That is another option for sure.  And actually it does not even have to be
> separate invocations.  We could script the creation of a new Test task
> based on the configured JDK6 path and just have both run in the same Gradle
> build.
>
>

From steve at hibernate.org  Mon Mar 30 07:53:19 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 30 Mar 2015 06:53:19 -0500
Subject: [hibernate-dev] ORM Jenkins Builds
In-Reply-To: <CAFdSV9t7ESOa_kCyThU4+R4HYiXkuLv2eFUdz+F0HiYHdo7ymg@mail.gmail.com>
References: <CAFdSV9tby1xjSQCVD7nWp+y8hV7K+JLy-8P156QmKQ4-32mOzw@mail.gmail.com>
	<CAFm4XO29_ECFBV5mzZFttOt==F2xpBywp79VpxggtenvV7x3Ng@mail.gmail.com>
	<CAFdSV9t3k_0PkoHWE43qOJ9=OsxszFPcMFZQ=YzhO9n-Rm1+wQ@mail.gmail.com>
	<CAFm4XO27HoCwbo9w2t-dqFjxmnRR-J-XvQ4J8JRk01L2UMSsew@mail.gmail.com>
	<CAFdSV9vgESmEn-u5AGfJFP3Dax+idzF3qQ87HeD1YnwCxAofwQ@mail.gmail.com>
	<CAFdSV9t7ESOa_kCyThU4+R4HYiXkuLv2eFUdz+F0HiYHdo7ymg@mail.gmail.com>
Message-ID: <CAFdSV9tE4t54mbnL-WJLA1PVyTz9HZBwo-aLwSPaCF3xpc69FQ@mail.gmail.com>

Does Eclipse have the ability, like IntelliJ does, to define a different
JDK for each module in a multi-module project?

On Sat, Mar 28, 2015 at 2:10 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Gradle really is quite elegant in most cases:
>
> if ( project.name != 'hibernate-java8' && rootProject.hasProperty(
> "JDK6_HOME" ) ) {
> final File java6Home = new File( rootProject.property( "JDK6_HOME" ) as
> String );
> final org.gradle.internal.jvm.Jvm java6Jdk =
> org.gradle.internal.jvm.Jvm.forHome( java6Home ) as
> org.gradle.internal.jvm.Jvm;
> if ( !java6Jdk.javaVersion.java6 ) {
> throw new GradleException( "JDK6_HOME (if set) must point to a Java 1.6
> home, found ${java6Jdk.javaVersion}" );
> }
> final Test mainTestTask = subProject.tasks.test as Test;
> task testWithJdk6(type:Test) {
> inputs = mainTestTask.inputs
> outputs = mainTestTask.outputs
>
> if ( java6Jdk.toolsJar ) {
> bootstrapClasspath java6Jdk.toolsJar
> }
>
> classpath = java6Jdk.runtimeJar + mainTestTask.classpath
> executable = java6Jdk.javaExecutable
>
> // should we recompile the tests using JDK6?  If so, set a different
> classes dir
> // here and clone new JavaCompile task for tests.  But just running with
> the Java 6
> // JRE should be enough
> testClassesDir = mainTestTask.testClassesDir
> testSrcDirs = mainTestTask.testSrcDirs
>
> enableAssertions = mainTestTask.enableAssertions
> environment = mainTestTask.environment
> systemProperties = mainTestTask.systemProperties
> scanForTestClasses = mainTestTask.scanForTestClasses
> includes = mainTestTask.includes
> excludes = mainTestTask.excludes
> jvmArgs = mainTestTask.jvmArgs
> maxHeapSize = mainTestTask.maxHeapSize
> minHeapSize = mainTestTask.minHeapSize
> }
> }
>
> On Sat, Mar 28, 2015 at 11:46 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> On Sat, Mar 28, 2015 at 11:26 AM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>>
>>> Consider also that since we now have N slaves, there is no guarantee
>>> that a second job will run on the same build slave.
>>> So if the JDK8 build produces artifacts but only deployes them in the
>>> local repository, the second node might not find the same as it has an
>>> independent repository cache.
>>>
>>
>> This is one of the major differences between Gradle and Maven.  Gradle
>> has no idea about a "local repository" in terms of publishing.  These jobs,
>> if they publish, always publish to Nexus.
>>
>> We added the ability to read artifacts from "Maven local" mainly to deal
>> with cases where we have local Maven-built projects that we want to have
>> ORM pick up a local snapshot of.  HCANN was the main thing here.  But the
>> "Gradle way" is to have the "other" local project (e.g., HCANN) publish its
>> SNAPSHOT to Nexus and for the ORM build to pick it up from there.
>>
>> More repeatable builds that way.  You pointed out one such scenario.  Of
>> course locally, Gradle (with some help usually) also lets you aggregate
>> these disparate projects together into one cohesive build.
>>
>> And given that IIRC I converted HCANN to use Gradle for building as well,
>> maybe its time to pull that ability.
>>
>>
>> One way would be to actually upload the snapshots to the jboss Nexus,
>>> but it could be easier / more efficient to have a single job which
>>> does the compilation & packaging only with JDK8 but then runs the
>>> tests with JDK6 ?
>>> The JDK paths are well defined, so that should be scriptable with a
>>> couple of sequential invocations to Gradle?
>>
>>
>> That is another option for sure.  And actually it does not even have to
>> be separate invocations.  We could script the creation of a new Test task
>> based on the configured JDK6 path and just have both run in the same Gradle
>> build.
>>
>>
>
>

From steve at hibernate.org  Mon Mar 30 09:42:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 30 Mar 2015 08:42:41 -0500
Subject: [hibernate-dev] ORM Jenkins Builds
In-Reply-To: <CAFdSV9tE4t54mbnL-WJLA1PVyTz9HZBwo-aLwSPaCF3xpc69FQ@mail.gmail.com>
References: <CAFdSV9tby1xjSQCVD7nWp+y8hV7K+JLy-8P156QmKQ4-32mOzw@mail.gmail.com>
	<CAFm4XO29_ECFBV5mzZFttOt==F2xpBywp79VpxggtenvV7x3Ng@mail.gmail.com>
	<CAFdSV9t3k_0PkoHWE43qOJ9=OsxszFPcMFZQ=YzhO9n-Rm1+wQ@mail.gmail.com>
	<CAFm4XO27HoCwbo9w2t-dqFjxmnRR-J-XvQ4J8JRk01L2UMSsew@mail.gmail.com>
	<CAFdSV9vgESmEn-u5AGfJFP3Dax+idzF3qQ87HeD1YnwCxAofwQ@mail.gmail.com>
	<CAFdSV9t7ESOa_kCyThU4+R4HYiXkuLv2eFUdz+F0HiYHdo7ymg@mail.gmail.com>
	<CAFdSV9tE4t54mbnL-WJLA1PVyTz9HZBwo-aLwSPaCF3xpc69FQ@mail.gmail.com>
Message-ID: <CAFdSV9vm0g-zJxXx4Cszve_4v0WRs7FTcf5X0JCdWCDDUQnAaw@mail.gmail.com>

The reason I ask is that it might be better to point the
non-hibernate-java8 modules to use the Java 6 javac when this JDK6_HOME is
set.  So...

1) Running Gradle with Java 8, JDK6_HOME set -> we'd compile all the
non-hibernate-java8 modules setting
JavaCompile#options#forkOptions#executable to the Java 6 javac.  Tests
would still run using Java 8 (although we could adjust that too if we want).

2) Running Gradle with Java 8, JDK6_HOME not set -> everything is compiled
and tests run with Java 8

3) Running Gradle with Java 6 or 7 -> (irrelevant whether JDK6_HOME is
set); hibernate-java8 is not even included in the project

On Mon, Mar 30, 2015 at 6:53 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Does Eclipse have the ability, like IntelliJ does, to define a different
> JDK for each module in a multi-module project?
>
> On Sat, Mar 28, 2015 at 2:10 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Gradle really is quite elegant in most cases:
>>
>> if ( project.name != 'hibernate-java8' && rootProject.hasProperty(
>> "JDK6_HOME" ) ) {
>> final File java6Home = new File( rootProject.property( "JDK6_HOME" ) as
>> String );
>> final org.gradle.internal.jvm.Jvm java6Jdk =
>> org.gradle.internal.jvm.Jvm.forHome( java6Home ) as
>> org.gradle.internal.jvm.Jvm;
>> if ( !java6Jdk.javaVersion.java6 ) {
>> throw new GradleException( "JDK6_HOME (if set) must point to a Java 1.6
>> home, found ${java6Jdk.javaVersion}" );
>> }
>> final Test mainTestTask = subProject.tasks.test as Test;
>> task testWithJdk6(type:Test) {
>> inputs = mainTestTask.inputs
>> outputs = mainTestTask.outputs
>>
>> if ( java6Jdk.toolsJar ) {
>> bootstrapClasspath java6Jdk.toolsJar
>> }
>>
>> classpath = java6Jdk.runtimeJar + mainTestTask.classpath
>> executable = java6Jdk.javaExecutable
>>
>> // should we recompile the tests using JDK6?  If so, set a different
>> classes dir
>> // here and clone new JavaCompile task for tests.  But just running with
>> the Java 6
>> // JRE should be enough
>> testClassesDir = mainTestTask.testClassesDir
>> testSrcDirs = mainTestTask.testSrcDirs
>>
>> enableAssertions = mainTestTask.enableAssertions
>> environment = mainTestTask.environment
>> systemProperties = mainTestTask.systemProperties
>> scanForTestClasses = mainTestTask.scanForTestClasses
>> includes = mainTestTask.includes
>> excludes = mainTestTask.excludes
>> jvmArgs = mainTestTask.jvmArgs
>> maxHeapSize = mainTestTask.maxHeapSize
>> minHeapSize = mainTestTask.minHeapSize
>> }
>> }
>>
>> On Sat, Mar 28, 2015 at 11:46 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> On Sat, Mar 28, 2015 at 11:26 AM, Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>>>
>>>> Consider also that since we now have N slaves, there is no guarantee
>>>> that a second job will run on the same build slave.
>>>> So if the JDK8 build produces artifacts but only deployes them in the
>>>> local repository, the second node might not find the same as it has an
>>>> independent repository cache.
>>>>
>>>
>>> This is one of the major differences between Gradle and Maven.  Gradle
>>> has no idea about a "local repository" in terms of publishing.  These jobs,
>>> if they publish, always publish to Nexus.
>>>
>>> We added the ability to read artifacts from "Maven local" mainly to deal
>>> with cases where we have local Maven-built projects that we want to have
>>> ORM pick up a local snapshot of.  HCANN was the main thing here.  But the
>>> "Gradle way" is to have the "other" local project (e.g., HCANN) publish its
>>> SNAPSHOT to Nexus and for the ORM build to pick it up from there.
>>>
>>> More repeatable builds that way.  You pointed out one such scenario.  Of
>>> course locally, Gradle (with some help usually) also lets you aggregate
>>> these disparate projects together into one cohesive build.
>>>
>>> And given that IIRC I converted HCANN to use Gradle for building as
>>> well, maybe its time to pull that ability.
>>>
>>>
>>> One way would be to actually upload the snapshots to the jboss Nexus,
>>>> but it could be easier / more efficient to have a single job which
>>>> does the compilation & packaging only with JDK8 but then runs the
>>>> tests with JDK6 ?
>>>> The JDK paths are well defined, so that should be scriptable with a
>>>> couple of sequential invocations to Gradle?
>>>
>>>
>>> That is another option for sure.  And actually it does not even have to
>>> be separate invocations.  We could script the creation of a new Test task
>>> based on the configured JDK6 path and just have both run in the same Gradle
>>> build.
>>>
>>>
>>
>>
>

From steve at hibernate.org  Tue Mar 31 17:08:27 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 16:08:27 -0500
Subject: [hibernate-dev] Hibernate ORM 5.0.0.Beta1 release
Message-ID: <CAFdSV9vFuOYa3DAEYAR0+Ne9dHEtgoqoq5c61wND=dURLyGMUg@mail.gmail.com>

Just released 5.0.0.Beta1 :
http://in.relation.to/Bloggers/HibernateORM500Beta1Release

From paranoiabla at gmail.com  Tue Mar 31 17:14:37 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 1 Apr 2015 00:14:37 +0300
Subject: [hibernate-dev] Hibernate ORM 5.0.0.Beta1 release
In-Reply-To: <CAFdSV9vFuOYa3DAEYAR0+Ne9dHEtgoqoq5c61wND=dURLyGMUg@mail.gmail.com>
References: <CAFdSV9vFuOYa3DAEYAR0+Ne9dHEtgoqoq5c61wND=dURLyGMUg@mail.gmail.com>
Message-ID: <CAKnbemWoi644-Mz=dKL2LHs0_4ByuAywa39oSW5d=vMt73PMDg@mail.gmail.com>

Which maven repo is it in?

2015-04-01 0:08 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> Just released 5.0.0.Beta1 :
> http://in.relation.to/Bloggers/HibernateORM500Beta1Release
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From sanne at hibernate.org  Tue Mar 31 17:45:28 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 31 Mar 2015 22:45:28 +0100
Subject: [hibernate-dev] [Hibernate Search] Repository Notice: migrating
	Infinispan integration
Message-ID: <CAFm4XO24HHnaCyL=1Zdkuh2ra-ckaNCrGhJ9LpW-M+6KqFfk2Q@mail.gmail.com>

All,
please do not make changes (or propose patches) to any sources for the
Maven module

   org.hibernate:hibernate-search-infinispan

In other words, anything under the path /infinispan in the repository.

We're currently working to move this module to the Infinispan project,
at the following repository:

  https://github.com/infinispan/infinispan

Of course we'll still maintain and love our integration, it's just
much easier to maintain if it is released together with the Infinispan
core modules.

We'll also migrate some of the integration tests.

Thanks,
Sanne

From steve at hibernate.org  Tue Mar 31 17:49:16 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 16:49:16 -0500
Subject: [hibernate-dev] Hibernate ORM 5.0.0.Beta1 release
In-Reply-To: <CAKnbemWoi644-Mz=dKL2LHs0_4ByuAywa39oSW5d=vMt73PMDg@mail.gmail.com>
References: <CAFdSV9vFuOYa3DAEYAR0+Ne9dHEtgoqoq5c61wND=dURLyGMUg@mail.gmail.com>
	<CAKnbemWoi644-Mz=dKL2LHs0_4ByuAywa39oSW5d=vMt73PMDg@mail.gmail.com>
Message-ID: <CAFdSV9s1NmWbwJsA3a6D4P+4cwb52scScLUjjo__KGDztMY3rQ@mail.gmail.com>

It is in the JBoss repo now, which automatically syncs to Maven central.
Nothing new there.

It does seem that there is a problem though with JBoss's Nexus (I know,
imagine that...).  I am trying to follow up with the folks that manage the
JBoss Nexus.


On Tue, Mar 31, 2015 at 4:14 PM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Which maven repo is it in?
>
> 2015-04-01 0:08 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> Just released 5.0.0.Beta1 :
>> http://in.relation.to/Bloggers/HibernateORM500Beta1Release
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

From paranoiabla at gmail.com  Tue Mar 31 18:07:16 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 1 Apr 2015 01:07:16 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
Message-ID: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>

Hi guys,

I just tried the latest beta and I cannot compile my project. With the
latest hibernate 4.3.X I was able to do this:
-------
        final org.hibernate.cfg.Configuration configuration =
getHibernateConfiguration();
        configuration.buildMappings();
        final SchemaUpdate schemaUpdate = new SchemaUpdate(configuration);
-------

however it seems that the SchemaUpdate constructor has been removed and now
a new one is added:
--------
    public SchemaUpdate(MetadataImplementor metadata) {
        this( metadata.getMetadataBuildingOptions().getServiceRegistry(),
metadata );
    }
---------

Also the configuration.buildMappings() method has been deprecated. Where do
I get the MetadataImplementor from? Also is there any changelog I can refer
to?

Thanks.
-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From steve at hibernate.org  Tue Mar 31 18:18:59 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 17:18:59 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
Message-ID: <CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>

So apparently the artifacts / repo issue is a Nexus bug that is effecting
the JBoss repo (and therefore us)...
http://issues.sonatype.org/browse/NEXUS-7654

As I pointed out in the announcement, I am managing the "migration guide"
in source repo while I develop the Betas.  See
https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
 As far are the new bootstrapping apis, see
http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
and
http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html

On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Hi guys,
>
> I just tried the latest beta and I cannot compile my project. With the
> latest hibernate 4.3.X I was able to do this:
> -------
>         final org.hibernate.cfg.Configuration configuration =
> getHibernateConfiguration();
>         configuration.buildMappings();
>         final SchemaUpdate schemaUpdate = new SchemaUpdate(configuration);
> -------
>
> however it seems that the SchemaUpdate constructor has been removed and now
> a new one is added:
> --------
>     public SchemaUpdate(MetadataImplementor metadata) {
>         this( metadata.getMetadataBuildingOptions().getServiceRegistry(),
> metadata );
>     }
> ---------
>
> Also the configuration.buildMappings() method has been deprecated. Where do
> I get the MetadataImplementor from? Also is there any changelog I can refer
> to?
>
> Thanks.
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Mar 31 18:19:44 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 17:19:44 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
Message-ID: <CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>

hibernate-core seems to be the only artifact that is available in JBoss
Nexus.

On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve at hibernate.org> wrote:

> So apparently the artifacts / repo issue is a Nexus bug that is effecting
> the JBoss repo (and therefore us)...
> http://issues.sonatype.org/browse/NEXUS-7654
>
> As I pointed out in the announcement, I am managing the "migration guide"
> in source repo while I develop the Betas.  See
> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>  As far are the new bootstrapping apis, see
> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
> and
> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>
> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> Hi guys,
>>
>> I just tried the latest beta and I cannot compile my project. With the
>> latest hibernate 4.3.X I was able to do this:
>> -------
>>         final org.hibernate.cfg.Configuration configuration =
>> getHibernateConfiguration();
>>         configuration.buildMappings();
>>         final SchemaUpdate schemaUpdate = new SchemaUpdate(configuration);
>> -------
>>
>> however it seems that the SchemaUpdate constructor has been removed and
>> now
>> a new one is added:
>> --------
>>     public SchemaUpdate(MetadataImplementor metadata) {
>>         this( metadata.getMetadataBuildingOptions().getServiceRegistry(),
>> metadata );
>>     }
>> ---------
>>
>> Also the configuration.buildMappings() method has been deprecated. Where
>> do
>> I get the MetadataImplementor from? Also is there any changelog I can
>> refer
>> to?
>>
>> Thanks.
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Tue Mar 31 18:23:14 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 17:23:14 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
Message-ID: <CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>

I am told that the bug does not affect the JBoss->Central sync process.  So
at some point the artifacts should all be available in Central

On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org> wrote:

> hibernate-core seems to be the only artifact that is available in JBoss
> Nexus.
>
> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> So apparently the artifacts / repo issue is a Nexus bug that is effecting
>> the JBoss repo (and therefore us)...
>> http://issues.sonatype.org/browse/NEXUS-7654
>>
>> As I pointed out in the announcement, I am managing the "migration guide"
>> in source repo while I develop the Betas.  See
>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>  As far are the new bootstrapping apis, see
>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>> and
>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>
>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Hi guys,
>>>
>>> I just tried the latest beta and I cannot compile my project. With the
>>> latest hibernate 4.3.X I was able to do this:
>>> -------
>>>         final org.hibernate.cfg.Configuration configuration =
>>> getHibernateConfiguration();
>>>         configuration.buildMappings();
>>>         final SchemaUpdate schemaUpdate = new
>>> SchemaUpdate(configuration);
>>> -------
>>>
>>> however it seems that the SchemaUpdate constructor has been removed and
>>> now
>>> a new one is added:
>>> --------
>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>         this( metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>> metadata );
>>>     }
>>> ---------
>>>
>>> Also the configuration.buildMappings() method has been deprecated. Where
>>> do
>>> I get the MetadataImplementor from? Also is there any changelog I can
>>> refer
>>> to?
>>>
>>> Thanks.
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From paranoiabla at gmail.com  Tue Mar 31 19:03:05 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 1 Apr 2015 02:03:05 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
Message-ID: <CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>

Thanks Steve,

I managed to migrate my configuration to the new MetamodelImplementor. Now
when I run the scema export I get a lot of these warning:

INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
WARN : JDBC Driver reports it stores quoted identifiers in both mixed and
upper case
WARN : HHH000072: Duplicate joins for class:
com.xxx.platform.core.model.cms.AbstractPageModel
WARN : HHH000072: Duplicate joins for class:
com.xxx.platform.module.invoice.core.model.InvoicePageModel
WARN : HHH000072: Duplicate joins for class:
com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
WARN : HHH000072: Duplicate joins for class:
com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
WARN : HHH000072: Duplicate joins for class:
com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
WARN : HHH000072: Duplicate joins for class:
com.xxx.platform.module.search.core.model.SearchPageRedirectModel
WARN : HHH000072: Duplicate joins for class:
com.xxx.platform.module.promotion.core.model.PromotionModel

and when I run some test I get the following exception:
java.lang.NoSuchMethodError:
java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
    at
org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
    at
org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
    at
org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
    at
org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
    at
org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
    at
org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
    at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
    at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
    at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
    at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
    at
org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
    at
org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)




2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> I am told that the bug does not affect the JBoss->Central sync process.
> So at some point the artifacts should all be available in Central
>
> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> hibernate-core seems to be the only artifact that is available in JBoss
>> Nexus.
>>
>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>> effecting the JBoss repo (and therefore us)...
>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>
>>> As I pointed out in the announcement, I am managing the "migration
>>> guide" in source repo while I develop the Betas.  See
>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>  As far are the new bootstrapping apis, see
>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>> and
>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>
>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <paranoiabla at gmail.com>
>>> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I just tried the latest beta and I cannot compile my project. With the
>>>> latest hibernate 4.3.X I was able to do this:
>>>> -------
>>>>         final org.hibernate.cfg.Configuration configuration =
>>>> getHibernateConfiguration();
>>>>         configuration.buildMappings();
>>>>         final SchemaUpdate schemaUpdate = new
>>>> SchemaUpdate(configuration);
>>>> -------
>>>>
>>>> however it seems that the SchemaUpdate constructor has been removed and
>>>> now
>>>> a new one is added:
>>>> --------
>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>         this(
>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>> metadata );
>>>>     }
>>>> ---------
>>>>
>>>> Also the configuration.buildMappings() method has been deprecated.
>>>> Where do
>>>> I get the MetadataImplementor from? Also is there any changelog I can
>>>> refer
>>>> to?
>>>>
>>>> Thanks.
>>>> --
>>>> Regards, Petar!
>>>> Karlovo, Bulgaria.
>>>> ---
>>>> Public PGP Key at:
>>>>
>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From paranoiabla at gmail.com  Tue Mar 31 19:13:42 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 1 Apr 2015 02:13:42 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
Message-ID: <CAKnbemVfcGVnzhjLWM-uVVNfT_aONCPe_BSwnfE09nY_NwLq9w@mail.gmail.com>

BTW,

I see here: https://hibernate.atlassian.net/browse/HHH-8844 that
Jean-Baptiste Nizet  commented he also gets these "Duplicate joins for
class" warnings:
-----

   - unrelated: I get a warning for **every** entity that I didn't get with
   Hibernate 4, which is not very clear and seems like a false positive: `WARN
   o.h.b.i.InFlightMetadataCollectorImpl - HHH000072: Duplicate joins for
   class: ...`. Note that I get this warning even for entities that have no
   association at all with any other entity.


-----

2015-04-01 2:03 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:

> Thanks Steve,
>
> I managed to migrate my configuration to the new MetamodelImplementor. Now
> when I run the scema export I get a lot of these warning:
>
> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
> WARN : JDBC Driver reports it stores quoted identifiers in both mixed and
> upper case
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.core.model.cms.AbstractPageModel
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.module.invoice.core.model.InvoicePageModel
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.module.promotion.core.model.PromotionModel
>
> and when I run some test I get the following exception:
> java.lang.NoSuchMethodError:
> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>     at
> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>     at
> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>     at
> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>     at
> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>     at
> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>     at
> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>     at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>     at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>     at
> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>     at
> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>
>
>
>
> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> I am told that the bug does not affect the JBoss->Central sync process.
>> So at some point the artifacts should all be available in Central
>>
>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> hibernate-core seems to be the only artifact that is available in JBoss
>>> Nexus.
>>>
>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>> effecting the JBoss repo (and therefore us)...
>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>
>>>> As I pointed out in the announcement, I am managing the "migration
>>>> guide" in source repo while I develop the Betas.  See
>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>  As far are the new bootstrapping apis, see
>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>> and
>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>
>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <paranoiabla at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I just tried the latest beta and I cannot compile my project. With the
>>>>> latest hibernate 4.3.X I was able to do this:
>>>>> -------
>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>> getHibernateConfiguration();
>>>>>         configuration.buildMappings();
>>>>>         final SchemaUpdate schemaUpdate = new
>>>>> SchemaUpdate(configuration);
>>>>> -------
>>>>>
>>>>> however it seems that the SchemaUpdate constructor has been removed
>>>>> and now
>>>>> a new one is added:
>>>>> --------
>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>         this(
>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>> metadata );
>>>>>     }
>>>>> ---------
>>>>>
>>>>> Also the configuration.buildMappings() method has been deprecated.
>>>>> Where do
>>>>> I get the MetadataImplementor from? Also is there any changelog I can
>>>>> refer
>>>>> to?
>>>>>
>>>>> Thanks.
>>>>> --
>>>>> Regards, Petar!
>>>>> Karlovo, Bulgaria.
>>>>> ---
>>>>> Public PGP Key at:
>>>>>
>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From steve at hibernate.org  Tue Mar 31 19:18:49 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 18:18:49 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemVfcGVnzhjLWM-uVVNfT_aONCPe_BSwnfE09nY_NwLq9w@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAKnbemVfcGVnzhjLWM-uVVNfT_aONCPe_BSwnfE09nY_NwLq9w@mail.gmail.com>
Message-ID: <CAFdSV9s--MJpguCus1wgjFBBcQLbbELN98v6qv4KK=tUJaqroA@mail.gmail.com>

So then you also noticed that I replied to him :)

Jean-Baptiste Nizet
<https://hibernate.atlassian.net/secure/ViewProfile.jspa?name=jnizet> Awesome,
thanks for trying it out! I have noticed that occasionally too wrt
HHH000072, but have been so heads down trying to get ready for the 5.0.0
Beta release that I have not yet had time to look closer. I will get to it.

On Tue, Mar 31, 2015 at 6:13 PM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> BTW,
>
> I see here: https://hibernate.atlassian.net/browse/HHH-8844 that
> Jean-Baptiste Nizet  commented he also gets these "Duplicate joins for
> class" warnings:
> -----
>
>    - unrelated: I get a warning for **every** entity that I didn't get
>    with Hibernate 4, which is not very clear and seems like a false positive:
>    `WARN o.h.b.i.InFlightMetadataCollectorImpl - HHH000072: Duplicate joins
>    for class: ...`. Note that I get this warning even for entities that have
>    no association at all with any other entity.
>
>
> -----
>
> 2015-04-01 2:03 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>
>> Thanks Steve,
>>
>> I managed to migrate my configuration to the new MetamodelImplementor.
>> Now when I run the scema export I get a lot of these warning:
>>
>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>> WARN : JDBC Driver reports it stores quoted identifiers in both mixed and
>> upper case
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.core.model.cms.AbstractPageModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.module.promotion.core.model.PromotionModel
>>
>> and when I run some test I get the following exception:
>> java.lang.NoSuchMethodError:
>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>     at
>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>     at
>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>     at
>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>     at
>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>     at
>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>     at
>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>     at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>     at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>     at
>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>     at
>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>
>>
>>
>>
>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> I am told that the bug does not affect the JBoss->Central sync process.
>>> So at some point the artifacts should all be available in Central
>>>
>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> hibernate-core seems to be the only artifact that is available in JBoss
>>>> Nexus.
>>>>
>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>>> effecting the JBoss repo (and therefore us)...
>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>>
>>>>> As I pointed out in the announcement, I am managing the "migration
>>>>> guide" in source repo while I develop the Betas.  See
>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>>  As far are the new bootstrapping apis, see
>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>>> and
>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>>
>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <paranoiabla at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> I just tried the latest beta and I cannot compile my project. With the
>>>>>> latest hibernate 4.3.X I was able to do this:
>>>>>> -------
>>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>>> getHibernateConfiguration();
>>>>>>         configuration.buildMappings();
>>>>>>         final SchemaUpdate schemaUpdate = new
>>>>>> SchemaUpdate(configuration);
>>>>>> -------
>>>>>>
>>>>>> however it seems that the SchemaUpdate constructor has been removed
>>>>>> and now
>>>>>> a new one is added:
>>>>>> --------
>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>>         this(
>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>>> metadata );
>>>>>>     }
>>>>>> ---------
>>>>>>
>>>>>> Also the configuration.buildMappings() method has been deprecated.
>>>>>> Where do
>>>>>> I get the MetadataImplementor from? Also is there any changelog I can
>>>>>> refer
>>>>>> to?
>>>>>>
>>>>>> Thanks.
>>>>>> --
>>>>>> Regards, Petar!
>>>>>> Karlovo, Bulgaria.
>>>>>> ---
>>>>>> Public PGP Key at:
>>>>>>
>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

From paranoiabla at gmail.com  Tue Mar 31 19:21:49 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 1 Apr 2015 02:21:49 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9s--MJpguCus1wgjFBBcQLbbELN98v6qv4KK=tUJaqroA@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAKnbemVfcGVnzhjLWM-uVVNfT_aONCPe_BSwnfE09nY_NwLq9w@mail.gmail.com>
	<CAFdSV9s--MJpguCus1wgjFBBcQLbbELN98v6qv4KK=tUJaqroA@mail.gmail.com>
Message-ID: <CAKnbemVXOZ-sc3j9VaacHyER0jeAUkp3zOfL_xxDaLPLfNvF3Q@mail.gmail.com>

Yeah, too late though.. I need some sleep :))

2015-04-01 2:18 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> So then you also noticed that I replied to him :)
>
> Jean-Baptiste Nizet
> <https://hibernate.atlassian.net/secure/ViewProfile.jspa?name=jnizet> Awesome,
> thanks for trying it out! I have noticed that occasionally too wrt
> HHH000072, but have been so heads down trying to get ready for the 5.0.0
> Beta release that I have not yet had time to look closer. I will get to it.
>
> On Tue, Mar 31, 2015 at 6:13 PM, Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> BTW,
>>
>> I see here: https://hibernate.atlassian.net/browse/HHH-8844 that
>> Jean-Baptiste Nizet  commented he also gets these "Duplicate joins for
>> class" warnings:
>> -----
>>
>>    - unrelated: I get a warning for **every** entity that I didn't get
>>    with Hibernate 4, which is not very clear and seems like a false positive:
>>    `WARN o.h.b.i.InFlightMetadataCollectorImpl - HHH000072: Duplicate joins
>>    for class: ...`. Note that I get this warning even for entities that have
>>    no association at all with any other entity.
>>
>>
>> -----
>>
>> 2015-04-01 2:03 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>
>>> Thanks Steve,
>>>
>>> I managed to migrate my configuration to the new MetamodelImplementor.
>>> Now when I run the scema export I get a lot of these warning:
>>>
>>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>>> WARN : JDBC Driver reports it stores quoted identifiers in both mixed
>>> and upper case
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.core.model.cms.AbstractPageModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.module.promotion.core.model.PromotionModel
>>>
>>> and when I run some test I get the following exception:
>>> java.lang.NoSuchMethodError:
>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>>     at
>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>>     at
>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>>     at
>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>>     at
>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>>     at
>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>>     at
>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>>     at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>>     at
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>>     at
>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>>     at
>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>>
>>>
>>>
>>>
>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> I am told that the bug does not affect the JBoss->Central sync
>>>> process.  So at some point the artifacts should all be available in Central
>>>>
>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> hibernate-core seems to be the only artifact that is available in
>>>>> JBoss Nexus.
>>>>>
>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>>>> effecting the JBoss repo (and therefore us)...
>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>>>
>>>>>> As I pointed out in the announcement, I am managing the "migration
>>>>>> guide" in source repo while I develop the Betas.  See
>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>>>  As far are the new bootstrapping apis, see
>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>>>> and
>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>>>
>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> I just tried the latest beta and I cannot compile my project. With
>>>>>>> the
>>>>>>> latest hibernate 4.3.X I was able to do this:
>>>>>>> -------
>>>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>>>> getHibernateConfiguration();
>>>>>>>         configuration.buildMappings();
>>>>>>>         final SchemaUpdate schemaUpdate = new
>>>>>>> SchemaUpdate(configuration);
>>>>>>> -------
>>>>>>>
>>>>>>> however it seems that the SchemaUpdate constructor has been removed
>>>>>>> and now
>>>>>>> a new one is added:
>>>>>>> --------
>>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>>>         this(
>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>>>> metadata );
>>>>>>>     }
>>>>>>> ---------
>>>>>>>
>>>>>>> Also the configuration.buildMappings() method has been deprecated.
>>>>>>> Where do
>>>>>>> I get the MetadataImplementor from? Also is there any changelog I
>>>>>>> can refer
>>>>>>> to?
>>>>>>>
>>>>>>> Thanks.
>>>>>>> --
>>>>>>> Regards, Petar!
>>>>>>> Karlovo, Bulgaria.
>>>>>>> ---
>>>>>>> Public PGP Key at:
>>>>>>>
>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>
>>
>>
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>
>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From steve at hibernate.org  Tue Mar 31 19:21:57 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 18:21:57 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
Message-ID: <CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>

What JRE are you trying to use?  This error:

java.lang.NoSuchMethodError: java.util.concurrent.ConcurrentHashMap.keySet()
Ljava/util/concurrent/ConcurrentHashMap$KeySetView;

is indicative of an issue in cross-jre support due to a change internal to
java classes.


On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Thanks Steve,
>
> I managed to migrate my configuration to the new MetamodelImplementor. Now
> when I run the scema export I get a lot of these warning:
>
> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
> WARN : JDBC Driver reports it stores quoted identifiers in both mixed and
> upper case
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.core.model.cms.AbstractPageModel
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.module.invoice.core.model.InvoicePageModel
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
> WARN : HHH000072: Duplicate joins for class:
> com.xxx.platform.module.promotion.core.model.PromotionModel
>
> and when I run some test I get the following exception:
> java.lang.NoSuchMethodError:
> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>     at
> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>     at
> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>     at
> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>     at
> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>     at
> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>     at
> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>     at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>     at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>     at
> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>     at
> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>
>
>
>
> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> I am told that the bug does not affect the JBoss->Central sync process.
>> So at some point the artifacts should all be available in Central
>>
>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> hibernate-core seems to be the only artifact that is available in JBoss
>>> Nexus.
>>>
>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>> effecting the JBoss repo (and therefore us)...
>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>
>>>> As I pointed out in the announcement, I am managing the "migration
>>>> guide" in source repo while I develop the Betas.  See
>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>  As far are the new bootstrapping apis, see
>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>> and
>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>
>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <paranoiabla at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I just tried the latest beta and I cannot compile my project. With the
>>>>> latest hibernate 4.3.X I was able to do this:
>>>>> -------
>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>> getHibernateConfiguration();
>>>>>         configuration.buildMappings();
>>>>>         final SchemaUpdate schemaUpdate = new
>>>>> SchemaUpdate(configuration);
>>>>> -------
>>>>>
>>>>> however it seems that the SchemaUpdate constructor has been removed
>>>>> and now
>>>>> a new one is added:
>>>>> --------
>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>         this(
>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>> metadata );
>>>>>     }
>>>>> ---------
>>>>>
>>>>> Also the configuration.buildMappings() method has been deprecated.
>>>>> Where do
>>>>> I get the MetadataImplementor from? Also is there any changelog I can
>>>>> refer
>>>>> to?
>>>>>
>>>>> Thanks.
>>>>> --
>>>>> Regards, Petar!
>>>>> Karlovo, Bulgaria.
>>>>> ---
>>>>> Public PGP Key at:
>>>>>
>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

From steve at hibernate.org  Tue Mar 31 19:25:36 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 18:25:36 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
Message-ID: <CAFdSV9v9cX08Lq1o6tFG_GoOiSP9VBZKpzfu4=SN5BmBnEE85Q@mail.gmail.com>

BTW, thanks for adopting this and trying it!

On Tue, Mar 31, 2015 at 6:21 PM, Steve Ebersole <steve at hibernate.org> wrote:

> What JRE are you trying to use?  This error:
>
> java.lang.NoSuchMethodError: java.util.concurrent.
> ConcurrentHashMap.keySet()Ljava/util/concurrent/
> ConcurrentHashMap$KeySetView;
>
> is indicative of an issue in cross-jre support due to a change internal to
> java classes.
>
>
> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> Thanks Steve,
>>
>> I managed to migrate my configuration to the new MetamodelImplementor.
>> Now when I run the scema export I get a lot of these warning:
>>
>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>> WARN : JDBC Driver reports it stores quoted identifiers in both mixed and
>> upper case
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.core.model.cms.AbstractPageModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.module.promotion.core.model.PromotionModel
>>
>> and when I run some test I get the following exception:
>> java.lang.NoSuchMethodError:
>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>     at
>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>     at
>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>     at
>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>     at
>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>     at
>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>     at
>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>     at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>     at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>     at
>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>     at
>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>
>>
>>
>>
>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> I am told that the bug does not affect the JBoss->Central sync process.
>>> So at some point the artifacts should all be available in Central
>>>
>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> hibernate-core seems to be the only artifact that is available in JBoss
>>>> Nexus.
>>>>
>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>>> effecting the JBoss repo (and therefore us)...
>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>>
>>>>> As I pointed out in the announcement, I am managing the "migration
>>>>> guide" in source repo while I develop the Betas.  See
>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>>  As far are the new bootstrapping apis, see
>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>>> and
>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>>
>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <paranoiabla at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> I just tried the latest beta and I cannot compile my project. With the
>>>>>> latest hibernate 4.3.X I was able to do this:
>>>>>> -------
>>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>>> getHibernateConfiguration();
>>>>>>         configuration.buildMappings();
>>>>>>         final SchemaUpdate schemaUpdate = new
>>>>>> SchemaUpdate(configuration);
>>>>>> -------
>>>>>>
>>>>>> however it seems that the SchemaUpdate constructor has been removed
>>>>>> and now
>>>>>> a new one is added:
>>>>>> --------
>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>>         this(
>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>>> metadata );
>>>>>>     }
>>>>>> ---------
>>>>>>
>>>>>> Also the configuration.buildMappings() method has been deprecated.
>>>>>> Where do
>>>>>> I get the MetadataImplementor from? Also is there any changelog I can
>>>>>> refer
>>>>>> to?
>>>>>>
>>>>>> Thanks.
>>>>>> --
>>>>>> Regards, Petar!
>>>>>> Karlovo, Bulgaria.
>>>>>> ---
>>>>>> Public PGP Key at:
>>>>>>
>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>
>
>

From paranoiabla at gmail.com  Tue Mar 31 19:25:47 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 1 Apr 2015 02:25:47 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
Message-ID: <CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>

petar at petar-ThinkPad-X1-Carbon:~$ java -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
petar at petar-ThinkPad-X1-Carbon:~$ uname -a
Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu Mar 12
12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
petar at petar-ThinkPad-X1-Carbon:~$


2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> What JRE are you trying to use?  This error:
>
> java.lang.NoSuchMethodError: java.util.concurrent.
> ConcurrentHashMap.keySet()Ljava/util/concurrent/
> ConcurrentHashMap$KeySetView;
>
> is indicative of an issue in cross-jre support due to a change internal to
> java classes.
>
>
> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> Thanks Steve,
>>
>> I managed to migrate my configuration to the new MetamodelImplementor.
>> Now when I run the scema export I get a lot of these warning:
>>
>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>> WARN : JDBC Driver reports it stores quoted identifiers in both mixed and
>> upper case
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.core.model.cms.AbstractPageModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.xxx.platform.module.promotion.core.model.PromotionModel
>>
>> and when I run some test I get the following exception:
>> java.lang.NoSuchMethodError:
>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>     at
>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>     at
>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>     at
>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>     at
>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>     at
>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>     at
>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>     at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>     at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>     at
>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>     at
>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>
>>
>>
>>
>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> I am told that the bug does not affect the JBoss->Central sync process.
>>> So at some point the artifacts should all be available in Central
>>>
>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> hibernate-core seems to be the only artifact that is available in JBoss
>>>> Nexus.
>>>>
>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>>> effecting the JBoss repo (and therefore us)...
>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>>
>>>>> As I pointed out in the announcement, I am managing the "migration
>>>>> guide" in source repo while I develop the Betas.  See
>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>>  As far are the new bootstrapping apis, see
>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>>> and
>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>>
>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <paranoiabla at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> I just tried the latest beta and I cannot compile my project. With the
>>>>>> latest hibernate 4.3.X I was able to do this:
>>>>>> -------
>>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>>> getHibernateConfiguration();
>>>>>>         configuration.buildMappings();
>>>>>>         final SchemaUpdate schemaUpdate = new
>>>>>> SchemaUpdate(configuration);
>>>>>> -------
>>>>>>
>>>>>> however it seems that the SchemaUpdate constructor has been removed
>>>>>> and now
>>>>>> a new one is added:
>>>>>> --------
>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>>         this(
>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>>> metadata );
>>>>>>     }
>>>>>> ---------
>>>>>>
>>>>>> Also the configuration.buildMappings() method has been deprecated.
>>>>>> Where do
>>>>>> I get the MetadataImplementor from? Also is there any changelog I can
>>>>>> refer
>>>>>> to?
>>>>>>
>>>>>> Thanks.
>>>>>> --
>>>>>> Regards, Petar!
>>>>>> Karlovo, Bulgaria.
>>>>>> ---
>>>>>> Public PGP Key at:
>>>>>>
>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>
>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From paranoiabla at gmail.com  Tue Mar 31 19:28:34 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 1 Apr 2015 02:28:34 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
Message-ID: <CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>

According to this:

https://gist.github.com/AlainODea/1375759b8720a3f9f094

Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K> while
the 1.8*ConcurrentHashMap#keySet()* returns a
ConcurrentHashMap.KeySetView<K,V>`.

I think you're using some Java8 API.


2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:

> petar at petar-ThinkPad-X1-Carbon:~$ java -version
> java version "1.7.0_71"
> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
> petar at petar-ThinkPad-X1-Carbon:~$ uname -a
> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu Mar 12
> 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> petar at petar-ThinkPad-X1-Carbon:~$
>
>
> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> What JRE are you trying to use?  This error:
>>
>> java.lang.NoSuchMethodError: java.util.concurrent.
>> ConcurrentHashMap.keySet()Ljava/util/concurrent/
>> ConcurrentHashMap$KeySetView;
>>
>> is indicative of an issue in cross-jre support due to a change internal
>> to java classes.
>>
>>
>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Thanks Steve,
>>>
>>> I managed to migrate my configuration to the new MetamodelImplementor.
>>> Now when I run the scema export I get a lot of these warning:
>>>
>>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>>> WARN : JDBC Driver reports it stores quoted identifiers in both mixed
>>> and upper case
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.core.model.cms.AbstractPageModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.module.promotion.core.model.PromotionModel
>>>
>>> and when I run some test I get the following exception:
>>> java.lang.NoSuchMethodError:
>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>>     at
>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>>     at
>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>>     at
>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>>     at
>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>>     at
>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>>     at
>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>>     at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>>     at
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>>     at
>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>>     at
>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>>
>>>
>>>
>>>
>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> I am told that the bug does not affect the JBoss->Central sync
>>>> process.  So at some point the artifacts should all be available in Central
>>>>
>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> hibernate-core seems to be the only artifact that is available in
>>>>> JBoss Nexus.
>>>>>
>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>>>> effecting the JBoss repo (and therefore us)...
>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>>>
>>>>>> As I pointed out in the announcement, I am managing the "migration
>>>>>> guide" in source repo while I develop the Betas.  See
>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>>>  As far are the new bootstrapping apis, see
>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>>>> and
>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>>>
>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> I just tried the latest beta and I cannot compile my project. With
>>>>>>> the
>>>>>>> latest hibernate 4.3.X I was able to do this:
>>>>>>> -------
>>>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>>>> getHibernateConfiguration();
>>>>>>>         configuration.buildMappings();
>>>>>>>         final SchemaUpdate schemaUpdate = new
>>>>>>> SchemaUpdate(configuration);
>>>>>>> -------
>>>>>>>
>>>>>>> however it seems that the SchemaUpdate constructor has been removed
>>>>>>> and now
>>>>>>> a new one is added:
>>>>>>> --------
>>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>>>         this(
>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>>>> metadata );
>>>>>>>     }
>>>>>>> ---------
>>>>>>>
>>>>>>> Also the configuration.buildMappings() method has been deprecated.
>>>>>>> Where do
>>>>>>> I get the MetadataImplementor from? Also is there any changelog I
>>>>>>> can refer
>>>>>>> to?
>>>>>>>
>>>>>>> Thanks.
>>>>>>> --
>>>>>>> Regards, Petar!
>>>>>>> Karlovo, Bulgaria.
>>>>>>> ---
>>>>>>> Public PGP Key at:
>>>>>>>
>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>
>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From steve at hibernate.org  Tue Mar 31 19:28:42 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 18:28:42 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
Message-ID: <CAFdSV9v6nhsRsRw+F4qs5GEdWL4iediMwYUKMLz-_9hVU9j0CQ@mail.gmail.com>

So this should have been compiled for 1.6 compatibility (although Java 7 is
required really as I mentioned).  Looks like that maybe did not work.  Try
running with Java 8

On Tue, Mar 31, 2015 at 6:25 PM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> petar at petar-ThinkPad-X1-Carbon:~$ java -version
> java version "1.7.0_71"
> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
> petar at petar-ThinkPad-X1-Carbon:~$ uname -a
> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu Mar 12
> 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> petar at petar-ThinkPad-X1-Carbon:~$
>
>
> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> What JRE are you trying to use?  This error:
>>
>> java.lang.NoSuchMethodError: java.util.concurrent.
>> ConcurrentHashMap.keySet()Ljava/util/concurrent/
>> ConcurrentHashMap$KeySetView;
>>
>> is indicative of an issue in cross-jre support due to a change internal
>> to java classes.
>>
>>
>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Thanks Steve,
>>>
>>> I managed to migrate my configuration to the new MetamodelImplementor.
>>> Now when I run the scema export I get a lot of these warning:
>>>
>>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>>> WARN : JDBC Driver reports it stores quoted identifiers in both mixed
>>> and upper case
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.core.model.cms.AbstractPageModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>>> WARN : HHH000072: Duplicate joins for class:
>>> com.xxx.platform.module.promotion.core.model.PromotionModel
>>>
>>> and when I run some test I get the following exception:
>>> java.lang.NoSuchMethodError:
>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>>     at
>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>>     at
>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>>     at
>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>>     at
>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>>     at
>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>>     at
>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>>     at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>>     at
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>>     at
>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>>     at
>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>>
>>>
>>>
>>>
>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> I am told that the bug does not affect the JBoss->Central sync
>>>> process.  So at some point the artifacts should all be available in Central
>>>>
>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> hibernate-core seems to be the only artifact that is available in
>>>>> JBoss Nexus.
>>>>>
>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>>>> effecting the JBoss repo (and therefore us)...
>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>>>
>>>>>> As I pointed out in the announcement, I am managing the "migration
>>>>>> guide" in source repo while I develop the Betas.  See
>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>>>  As far are the new bootstrapping apis, see
>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>>>> and
>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>>>
>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> I just tried the latest beta and I cannot compile my project. With
>>>>>>> the
>>>>>>> latest hibernate 4.3.X I was able to do this:
>>>>>>> -------
>>>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>>>> getHibernateConfiguration();
>>>>>>>         configuration.buildMappings();
>>>>>>>         final SchemaUpdate schemaUpdate = new
>>>>>>> SchemaUpdate(configuration);
>>>>>>> -------
>>>>>>>
>>>>>>> however it seems that the SchemaUpdate constructor has been removed
>>>>>>> and now
>>>>>>> a new one is added:
>>>>>>> --------
>>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>>>         this(
>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>>>> metadata );
>>>>>>>     }
>>>>>>> ---------
>>>>>>>
>>>>>>> Also the configuration.buildMappings() method has been deprecated.
>>>>>>> Where do
>>>>>>> I get the MetadataImplementor from? Also is there any changelog I
>>>>>>> can refer
>>>>>>> to?
>>>>>>>
>>>>>>> Thanks.
>>>>>>> --
>>>>>>> Regards, Petar!
>>>>>>> Karlovo, Bulgaria.
>>>>>>> ---
>>>>>>> Public PGP Key at:
>>>>>>>
>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>
>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

From steve at hibernate.org  Tue Mar 31 19:30:38 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 18:30:38 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
Message-ID: <CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>

Nope.  It just effects any code compiled with Java 8 even though the change
is internal.  The problem is the generated bytecode incorporates this
change.   Like I said, this should be compiled with 1.6 compatibility, but
that is apparently not working atm.  I am having a struggle getting a mixed
JDK build working "just right".

On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> According to this:
>
> https://gist.github.com/AlainODea/1375759b8720a3f9f094
>
> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K> while
> the 1.8*ConcurrentHashMap#keySet()* returns a
> ConcurrentHashMap.KeySetView<K,V>`.
>
> I think you're using some Java8 API.
>
>
> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>
>> petar at petar-ThinkPad-X1-Carbon:~$ java -version
>> java version "1.7.0_71"
>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
>> petar at petar-ThinkPad-X1-Carbon:~$ uname -a
>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu Mar
>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>> petar at petar-ThinkPad-X1-Carbon:~$
>>
>>
>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> What JRE are you trying to use?  This error:
>>>
>>> java.lang.NoSuchMethodError: java.util.concurrent.
>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/
>>> ConcurrentHashMap$KeySetView;
>>>
>>> is indicative of an issue in cross-jre support due to a change internal
>>> to java classes.
>>>
>>>
>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla at gmail.com>
>>> wrote:
>>>
>>>> Thanks Steve,
>>>>
>>>> I managed to migrate my configuration to the new MetamodelImplementor.
>>>> Now when I run the scema export I get a lot of these warning:
>>>>
>>>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>>>> WARN : JDBC Driver reports it stores quoted identifiers in both mixed
>>>> and upper case
>>>> WARN : HHH000072: Duplicate joins for class:
>>>> com.xxx.platform.core.model.cms.AbstractPageModel
>>>> WARN : HHH000072: Duplicate joins for class:
>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>>>> WARN : HHH000072: Duplicate joins for class:
>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>>>> WARN : HHH000072: Duplicate joins for class:
>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>>>> WARN : HHH000072: Duplicate joins for class:
>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>>>> WARN : HHH000072: Duplicate joins for class:
>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>>>> WARN : HHH000072: Duplicate joins for class:
>>>> com.xxx.platform.module.promotion.core.model.PromotionModel
>>>>
>>>> and when I run some test I get the following exception:
>>>> java.lang.NoSuchMethodError:
>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>>>     at
>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>>>     at
>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>>>     at
>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>>>     at
>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>>>     at
>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>>>     at
>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>>>     at
>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>>>     at
>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>>>     at
>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>>>     at
>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>>>
>>>>
>>>>
>>>>
>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>
>>>>> I am told that the bug does not affect the JBoss->Central sync
>>>>> process.  So at some point the artifacts should all be available in Central
>>>>>
>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> hibernate-core seems to be the only artifact that is available in
>>>>>> JBoss Nexus.
>>>>>>
>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>>>>> effecting the JBoss repo (and therefore us)...
>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>>>>
>>>>>>> As I pointed out in the announcement, I am managing the "migration
>>>>>>> guide" in source repo while I develop the Betas.  See
>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>>>>  As far are the new bootstrapping apis, see
>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>>>>> and
>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>>>>
>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> I just tried the latest beta and I cannot compile my project. With
>>>>>>>> the
>>>>>>>> latest hibernate 4.3.X I was able to do this:
>>>>>>>> -------
>>>>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>>>>> getHibernateConfiguration();
>>>>>>>>         configuration.buildMappings();
>>>>>>>>         final SchemaUpdate schemaUpdate = new
>>>>>>>> SchemaUpdate(configuration);
>>>>>>>> -------
>>>>>>>>
>>>>>>>> however it seems that the SchemaUpdate constructor has been removed
>>>>>>>> and now
>>>>>>>> a new one is added:
>>>>>>>> --------
>>>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>>>>         this(
>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>>>>> metadata );
>>>>>>>>     }
>>>>>>>> ---------
>>>>>>>>
>>>>>>>> Also the configuration.buildMappings() method has been deprecated.
>>>>>>>> Where do
>>>>>>>> I get the MetadataImplementor from? Also is there any changelog I
>>>>>>>> can refer
>>>>>>>> to?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> --
>>>>>>>> Regards, Petar!
>>>>>>>> Karlovo, Bulgaria.
>>>>>>>> ---
>>>>>>>> Public PGP Key at:
>>>>>>>>
>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>>> _______________________________________________
>>>>>>>> hibernate-dev mailing list
>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards, Petar!
>>>> Karlovo, Bulgaria.
>>>> ---
>>>> Public PGP Key at:
>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>
>>>
>>>
>>
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

From steve at hibernate.org  Tue Mar 31 19:34:05 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 18:34:05 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
Message-ID: <CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>

When I say "internal" here, I mean internal to java classes.

On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Nope.  It just effects any code compiled with Java 8 even though the
> change is internal.  The problem is the generated bytecode incorporates
> this change.   Like I said, this should be compiled with 1.6 compatibility,
> but that is apparently not working atm.  I am having a struggle getting a
> mixed JDK build working "just right".
>
> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> According to this:
>>
>> https://gist.github.com/AlainODea/1375759b8720a3f9f094
>>
>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K> while
>> the 1.8*ConcurrentHashMap#keySet()* returns a
>> ConcurrentHashMap.KeySetView<K,V>`.
>>
>> I think you're using some Java8 API.
>>
>>
>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>
>>> petar at petar-ThinkPad-X1-Carbon:~$ java -version
>>> java version "1.7.0_71"
>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
>>> petar at petar-ThinkPad-X1-Carbon:~$ uname -a
>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu Mar
>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>> petar at petar-ThinkPad-X1-Carbon:~$
>>>
>>>
>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> What JRE are you trying to use?  This error:
>>>>
>>>> java.lang.NoSuchMethodError: java.util.concurrent.
>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/
>>>> ConcurrentHashMap$KeySetView;
>>>>
>>>> is indicative of an issue in cross-jre support due to a change internal
>>>> to java classes.
>>>>
>>>>
>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla at gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks Steve,
>>>>>
>>>>> I managed to migrate my configuration to the new MetamodelImplementor.
>>>>> Now when I run the scema export I get a lot of these warning:
>>>>>
>>>>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both mixed
>>>>> and upper case
>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>> com.xxx.platform.core.model.cms.AbstractPageModel
>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel
>>>>>
>>>>> and when I run some test I get the following exception:
>>>>> java.lang.NoSuchMethodError:
>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>>>>     at
>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>>>>     at
>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>>>>     at
>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>>>>     at
>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>>>>     at
>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>>>>     at
>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>>>>     at
>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>>>>     at
>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>>>>     at
>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>>>>     at
>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>>
>>>>>> I am told that the bug does not affect the JBoss->Central sync
>>>>>> process.  So at some point the artifacts should all be available in Central
>>>>>>
>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> hibernate-core seems to be the only artifact that is available in
>>>>>>> JBoss Nexus.
>>>>>>>
>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve at hibernate.org
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>>>>>> effecting the JBoss repo (and therefore us)...
>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>>>>>
>>>>>>>> As I pointed out in the announcement, I am managing the "migration
>>>>>>>> guide" in source repo while I develop the Betas.  See
>>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>>>>>  As far are the new bootstrapping apis, see
>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>>>>>> and
>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>>>>>
>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>>>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi guys,
>>>>>>>>>
>>>>>>>>> I just tried the latest beta and I cannot compile my project. With
>>>>>>>>> the
>>>>>>>>> latest hibernate 4.3.X I was able to do this:
>>>>>>>>> -------
>>>>>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>>>>>> getHibernateConfiguration();
>>>>>>>>>         configuration.buildMappings();
>>>>>>>>>         final SchemaUpdate schemaUpdate = new
>>>>>>>>> SchemaUpdate(configuration);
>>>>>>>>> -------
>>>>>>>>>
>>>>>>>>> however it seems that the SchemaUpdate constructor has been
>>>>>>>>> removed and now
>>>>>>>>> a new one is added:
>>>>>>>>> --------
>>>>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>>>>>         this(
>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>>>>>> metadata );
>>>>>>>>>     }
>>>>>>>>> ---------
>>>>>>>>>
>>>>>>>>> Also the configuration.buildMappings() method has been deprecated.
>>>>>>>>> Where do
>>>>>>>>> I get the MetadataImplementor from? Also is there any changelog I
>>>>>>>>> can refer
>>>>>>>>> to?
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>> --
>>>>>>>>> Regards, Petar!
>>>>>>>>> Karlovo, Bulgaria.
>>>>>>>>> ---
>>>>>>>>> Public PGP Key at:
>>>>>>>>>
>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>>>> _______________________________________________
>>>>>>>>> hibernate-dev mailing list
>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards, Petar!
>>>>> Karlovo, Bulgaria.
>>>>> ---
>>>>> Public PGP Key at:
>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>
>>
>>
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>
>
>

From steve at hibernate.org  Tue Mar 31 19:36:09 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 18:36:09 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
Message-ID: <CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>

Ahh, seems this may be an option to work around it:

<quote>
Using the general *Map* interface in place of the concrete
*ConcurrentHashMap* type here side-steps the coupling to the Java 8 return
type and will allow this code to be compiled with Java 8 and run on Java 7.
</quote>

I had missed that part.


On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <steve at hibernate.org> wrote:

> When I say "internal" here, I mean internal to java classes.
>
> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Nope.  It just effects any code compiled with Java 8 even though the
>> change is internal.  The problem is the generated bytecode incorporates
>> this change.   Like I said, this should be compiled with 1.6 compatibility,
>> but that is apparently not working atm.  I am having a struggle getting a
>> mixed JDK build working "just right".
>>
>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> According to this:
>>>
>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094
>>>
>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K> while
>>> the 1.8*ConcurrentHashMap#keySet()* returns a
>>> ConcurrentHashMap.KeySetView<K,V>`.
>>>
>>> I think you're using some Java8 API.
>>>
>>>
>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>
>>>> petar at petar-ThinkPad-X1-Carbon:~$ java -version
>>>> java version "1.7.0_71"
>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
>>>> petar at petar-ThinkPad-X1-Carbon:~$ uname -a
>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu Mar
>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>>> petar at petar-ThinkPad-X1-Carbon:~$
>>>>
>>>>
>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>
>>>>> What JRE are you trying to use?  This error:
>>>>>
>>>>> java.lang.NoSuchMethodError: java.util.concurrent.
>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/
>>>>> ConcurrentHashMap$KeySetView;
>>>>>
>>>>> is indicative of an issue in cross-jre support due to a change
>>>>> internal to java classes.
>>>>>
>>>>>
>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Thanks Steve,
>>>>>>
>>>>>> I managed to migrate my configuration to the new
>>>>>> MetamodelImplementor. Now when I run the scema export I get a lot of these
>>>>>> warning:
>>>>>>
>>>>>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both mixed
>>>>>> and upper case
>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel
>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel
>>>>>>
>>>>>> and when I run some test I get the following exception:
>>>>>> java.lang.NoSuchMethodError:
>>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>>>>>     at
>>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>>>>>     at
>>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>>>>>     at
>>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>>>>>     at
>>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>>>>>     at
>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>>>>>     at
>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>>>>>     at
>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>>>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>>>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>>>>>     at
>>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>>>>>     at
>>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>>>>>     at
>>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>
>>>>>>> I am told that the bug does not affect the JBoss->Central sync
>>>>>>> process.  So at some point the artifacts should all be available in Central
>>>>>>>
>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> hibernate-core seems to be the only artifact that is available in
>>>>>>>> JBoss Nexus.
>>>>>>>>
>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <
>>>>>>>> steve at hibernate.org> wrote:
>>>>>>>>
>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>>>>>>> effecting the JBoss repo (and therefore us)...
>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>>>>>>
>>>>>>>>> As I pointed out in the announcement, I am managing the "migration
>>>>>>>>> guide" in source repo while I develop the Betas.  See
>>>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>>>>>>  As far are the new bootstrapping apis, see
>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>>>>>>> and
>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>>>>>>
>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>>>>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi guys,
>>>>>>>>>>
>>>>>>>>>> I just tried the latest beta and I cannot compile my project.
>>>>>>>>>> With the
>>>>>>>>>> latest hibernate 4.3.X I was able to do this:
>>>>>>>>>> -------
>>>>>>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>>>>>>> getHibernateConfiguration();
>>>>>>>>>>         configuration.buildMappings();
>>>>>>>>>>         final SchemaUpdate schemaUpdate = new
>>>>>>>>>> SchemaUpdate(configuration);
>>>>>>>>>> -------
>>>>>>>>>>
>>>>>>>>>> however it seems that the SchemaUpdate constructor has been
>>>>>>>>>> removed and now
>>>>>>>>>> a new one is added:
>>>>>>>>>> --------
>>>>>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>>>>>>         this(
>>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>>>>>>> metadata );
>>>>>>>>>>     }
>>>>>>>>>> ---------
>>>>>>>>>>
>>>>>>>>>> Also the configuration.buildMappings() method has been
>>>>>>>>>> deprecated. Where do
>>>>>>>>>> I get the MetadataImplementor from? Also is there any changelog I
>>>>>>>>>> can refer
>>>>>>>>>> to?
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>> --
>>>>>>>>>> Regards, Petar!
>>>>>>>>>> Karlovo, Bulgaria.
>>>>>>>>>> ---
>>>>>>>>>> Public PGP Key at:
>>>>>>>>>>
>>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>>>>>>>>>> 0611
>>>>>>>>>> _______________________________________________
>>>>>>>>>> hibernate-dev mailing list
>>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards, Petar!
>>>>>> Karlovo, Bulgaria.
>>>>>> ---
>>>>>> Public PGP Key at:
>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards, Petar!
>>>> Karlovo, Bulgaria.
>>>> ---
>>>> Public PGP Key at:
>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>
>>>
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>
>>
>>
>

From sanne at hibernate.org  Tue Mar 31 19:50:16 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 1 Apr 2015 00:50:16 +0100
Subject: [hibernate-dev] The current Hibernate Search sprint: lots of topics!
Message-ID: <CAFm4XO3kCAj1uD9HYnY-O=JvaRZZ2QiYfjQUGocg2eh8hEE-7g@mail.gmail.com>

All,
let me clarify the general goal of this sprint. I don't expect to
celebrate with a 5.2.0.Final this time, but I'd aim at getting some of
the long standing big tasks done, and finish these three weeks with a
5.2.Beta1. We need to organize in several parallel significant themes.

There are some "big" themes going on which you need to be aware of
beyond the granularity of JIRA.
Your help in properly inspecting these with experiments and then break
them down in smaller tasks is what I'm needing the most right now. I'd
highly appreciate if each of you could take on leadership of one of
these themes, and get at least one other team member as primary
reviewer and brainstorming mate.

These are the primary themes:
 - the Faceting refactoring - led by Hardy
 - the dynamic types work - led by me
 - Hibernate ORM 5 compatibility and testing - almost done
 - getting rid of the Infinispan module - led by Gustavo
 - a discussion with the wildFly team about how to share the module
structure / build / definitions (more on this soon)
 - Lucene 5
 - R&D: explore better clustering strategies, better master election
(or no-master architectures)
 - Better integration with ORM's Multi-tenancy - being quite requested
recently - Davide?

If we really could upgrade both ORM and Lucene to 5, then we could
promote this to a new major release. Of course I'm dreaming and that's
not going to happen in practice - not least that would require an ORM
5.0.0.Final.

So what I'm expecting is that we explore the needs for these, and you
help me identify which steps are needed to get these both upgraded in
the near future. That means we might be raising more issues than
solving them, but that's good as it clarifies which atomic, self
contained and consistent steps we then need to perform to get there.

I'm currently working on ORM5 tasks, will soon share some PRs of
things which could already be merged, but of course the final step
won't be applied as we're not really going to upgrade yet - unless we
agree we're only releasing betas until ORM is final too.

For Lucene 5: the work which Hardy is doing is essential:
 - update the Faceting code
 - move our code to use the new FieldDocs
After that, the upgrade won't be that bad (not as hard as Lucene 4)

I just created some JIRAs as "container" for these larger themes, just
please keep in mind that I'm not setting the version to be "5.2" as
they will probably span multiple releases. The goal should not be to
resolve them, but to start them and split them up in subtasks which
can be merged already.
I'm pretty sure that several resulting sub-tasks can be merged already.

There is a new label in JIRA: "current_sprint", so we can identify
them all even though they are not marked to be fixed for version 5.2.

The "R&D" tasks are not in JIRA at all, I'm still gathering
requirements - still we'll need to dedicate some time to
experimentation and brainstorming.

I realize these are many parallel paths to work on; we're many
experienced devs though, and these should be workable in parallel.
If each of you can take some leadership on an area I hope we can close
them all by the next iteration (except probably the R&D task).

===

That said on the larger themes, there is of course a list of
traditional tasks which will shape the 5.2 improvements.
These are marked "5.2" on JIRA; some are trivial, like missing javadoc
or a paragraph of documentation but need some figuring out to craft
the right docs.

Let me comment these briefly to see if any picks your interest.

# HSEARCH-1848 Replace the Infinispan Directory provider with the one
distributed by the Infinispan project
As discussed: we'll remove the module, but need to make sure we can
plug in the one distributed by Infinispan. Needs Infinispan to release
it first.

# HSEARCH-1214 Review SearchFactory initialization
For our own sake of mind.. the boot process is hard to understand. I
have some ideas, and there are many things to keep in mind so I'll
probably try to take this myself but otherwise I'll transfer my brain
dump.. best over voice.

# HSEARCH-1472 Broaden collection of built in IndexManager
implementations to simplify choice of sensible configurations
As discussed at the team meeting. The goal is to simplify
configuration and documentation, prevent sick configuration choices.

# HSEARCH-1474 MassIndexer needs to avoid being timed out by the
TransactionManager
This is high value and long standing, but complex. Gunnar started
working on a test.

# HSEARCH-1536 Improve the test suite around MoreLikeThis
(association, custom fieldbridge, class bridges)
There are several open tasks around MLT. This is the warmup point to
finalize it MLT... I didn't schedule the other tasks for this sprint.

# HSEARCH-1589 ServiceManager closes services too aggressively
A sensible optimisation, probably easy. Beware: concurrency and
bootstrap related.

# HSEARCH-1654 Disable merge policy during Massindexing
A great performance optimisation for mass indexing people. I think
it's trivial, but to be verified you'll need to setup a relatively
long run - we have a repository with instructions to reindex the
Wikipedia

# HSEARCH-1681 Index optimisation should commit to publish the
performed optimisation
Trivial to do - one liner - but not so trivial to test for.

# HSEARCH-1684 ResultTransformer ignores transformList on tuples
No idea, needs to be looked at to make Marc S. happy.

# HSEARCH-1708 Using DistanceSortField does not verify the field
parameter passed to the constructor

# HSEARCH-1711 EntityIndexingInterceptor executes on different part of
the hierarchy

# HSEARCH-1729 Document the Infinispan configuration property
`metadata_writes_async`
This was not documented as it's an highly experimental property. I was
hoping we could run some more tests, but I won't have the time for
that at the moment, so either someone volunteers for the test, or we
keep it a secret, or decide to document it with warnings.

# HSEARCH-1762 Improve javadocs of builtin bridges

# HSEARCH-1773 org.hibernate.search.backend.impl.WorkVisitor not
exported by engine osgi bundle
Or find some alternative way... but whatever the solution we need to
get OSGi as "done" status.

# HSEARCH-1783 Reproduce transaction timeouts during mass indexing
Gunnar already on it.

# HSEARCH-1793 CriteriaObjectInitializer causes too many object loads
in cross hierarchy queries
This one is nasty, we should get rid of it.

# HSEARCH-1803 Infinispan integration test search in the wrong node
since we're removing the code.. we need to apply this as
https://issues.jboss.org/browse/ISPN-5339

# HSEARCH-1804 Boost on IndexedEmbedded properties
This really should just work as the user requests

# HSEARCH-1811 WIldcard with multiple fields
Another sensible usability improvement

# HSEARCH-1812 Documentation doesn't clearly explain how one obtains
the existing SearchIntegrator
Start a documentation section "integrators and framework developers" ?

# HSEARCH-1815 Clarify the need to depend on an implementation of
SerializationProvider
Apparently we don't state one will be needed ;)

# HSEARCH-1816 Explicitly validate the version of Hibernate ORM
A usability improvement, as proposed on the mailing list. +1 for Gunnar's ideas.

# HSEARCH-1826 Make it possible to test Hibernate Search with preview
builds of Hibernate ORM 5
I'm working on this one.

# HSEARCH-1828 Clarify documentation about ways to disable Hibernate Search

# HSEARCH-1839 FieldBridge instance initialization might use reference
access to the booting framework
This is needed by the jBPM / Drools teams. At least the programmatic
configuration should be trivial.

# HSEARCH-1844 Review which components should no longer be tagged as
experimental

# HSEARCH-1847 Create a FSDirectory extension which doesn't ever sync to disk
Requested by Infinispan - might become an urgent requirement soon,
better have this ready.

From steve at hibernate.org  Tue Mar 31 19:56:53 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 18:56:53 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
Message-ID: <CAFdSV9tsQ_i+bShG8U46-fvRVrvfJD8AL4cdrjPULTN5CfCG0g@mail.gmail.com>

Actually this may have been a brain-fart on my part when building the
release.  I think I may have forgotten to pass in the Java 6 JDK to the
build, which I use to set the javac bootclasspath.  So in that case it
would have used the bootclasspath from the Java 8 JDK I used to launch
gradle.

If you get a chance, you can test that theory by getting the sources and
running the hibernate-core build again.  You'd have to use Java 8 to launch
Gradle and pass -PJDK6_HOME=<path-to-java7-jdk>.


On Tue, Mar 31, 2015 at 6:36 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Ahh, seems this may be an option to work around it:
>
> <quote>
> Using the general *Map* interface in place of the concrete
> *ConcurrentHashMap* type here side-steps the coupling to the Java 8
> return type and will allow this code to be compiled with Java 8 and run on
> Java 7.
> </quote>
>
> I had missed that part.
>
>
> On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> When I say "internal" here, I mean internal to java classes.
>>
>> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Nope.  It just effects any code compiled with Java 8 even though the
>>> change is internal.  The problem is the generated bytecode incorporates
>>> this change.   Like I said, this should be compiled with 1.6 compatibility,
>>> but that is apparently not working atm.  I am having a struggle getting a
>>> mixed JDK build working "just right".
>>>
>>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <paranoiabla at gmail.com>
>>> wrote:
>>>
>>>> According to this:
>>>>
>>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094
>>>>
>>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K> while
>>>> the 1.8*ConcurrentHashMap#keySet()* returns a
>>>> ConcurrentHashMap.KeySetView<K,V>`.
>>>>
>>>> I think you're using some Java8 API.
>>>>
>>>>
>>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>
>>>>> petar at petar-ThinkPad-X1-Carbon:~$ java -version
>>>>> java version "1.7.0_71"
>>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
>>>>> petar at petar-ThinkPad-X1-Carbon:~$ uname -a
>>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu
>>>>> Mar 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>>>> petar at petar-ThinkPad-X1-Carbon:~$
>>>>>
>>>>>
>>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>>
>>>>>> What JRE are you trying to use?  This error:
>>>>>>
>>>>>> java.lang.NoSuchMethodError: java.util.concurrent.
>>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/
>>>>>> ConcurrentHashMap$KeySetView;
>>>>>>
>>>>>> is indicative of an issue in cross-jre support due to a change
>>>>>> internal to java classes.
>>>>>>
>>>>>>
>>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <
>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>
>>>>>>> Thanks Steve,
>>>>>>>
>>>>>>> I managed to migrate my configuration to the new
>>>>>>> MetamodelImplementor. Now when I run the scema export I get a lot of these
>>>>>>> warning:
>>>>>>>
>>>>>>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both
>>>>>>> mixed and upper case
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel
>>>>>>>
>>>>>>> and when I run some test I get the following exception:
>>>>>>> java.lang.NoSuchMethodError:
>>>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>>>>>>     at
>>>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>>>>>>     at
>>>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>>>>>>     at
>>>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>>>>>>     at
>>>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>>>>>>     at
>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>>>>>>     at
>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>>>>>>     at
>>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>>>>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>>>>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>>>>>>     at
>>>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>>>>>>     at
>>>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>>>>>>     at
>>>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>>
>>>>>>>> I am told that the bug does not affect the JBoss->Central sync
>>>>>>>> process.  So at some point the artifacts should all be available in Central
>>>>>>>>
>>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <
>>>>>>>> steve at hibernate.org> wrote:
>>>>>>>>
>>>>>>>>> hibernate-core seems to be the only artifact that is available in
>>>>>>>>> JBoss Nexus.
>>>>>>>>>
>>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <
>>>>>>>>> steve at hibernate.org> wrote:
>>>>>>>>>
>>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>>>>>>>> effecting the JBoss repo (and therefore us)...
>>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>>>>>>>
>>>>>>>>>> As I pointed out in the announcement, I am managing the
>>>>>>>>>> "migration guide" in source repo while I develop the Betas.  See
>>>>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>>>>>>>  As far are the new bootstrapping apis, see
>>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>>>>>>>> and
>>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>>>>>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi guys,
>>>>>>>>>>>
>>>>>>>>>>> I just tried the latest beta and I cannot compile my project.
>>>>>>>>>>> With the
>>>>>>>>>>> latest hibernate 4.3.X I was able to do this:
>>>>>>>>>>> -------
>>>>>>>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>>>>>>>> getHibernateConfiguration();
>>>>>>>>>>>         configuration.buildMappings();
>>>>>>>>>>>         final SchemaUpdate schemaUpdate = new
>>>>>>>>>>> SchemaUpdate(configuration);
>>>>>>>>>>> -------
>>>>>>>>>>>
>>>>>>>>>>> however it seems that the SchemaUpdate constructor has been
>>>>>>>>>>> removed and now
>>>>>>>>>>> a new one is added:
>>>>>>>>>>> --------
>>>>>>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>>>>>>>         this(
>>>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>>>>>>>> metadata );
>>>>>>>>>>>     }
>>>>>>>>>>> ---------
>>>>>>>>>>>
>>>>>>>>>>> Also the configuration.buildMappings() method has been
>>>>>>>>>>> deprecated. Where do
>>>>>>>>>>> I get the MetadataImplementor from? Also is there any changelog
>>>>>>>>>>> I can refer
>>>>>>>>>>> to?
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>> --
>>>>>>>>>>> Regards, Petar!
>>>>>>>>>>> Karlovo, Bulgaria.
>>>>>>>>>>> ---
>>>>>>>>>>> Public PGP Key at:
>>>>>>>>>>>
>>>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>>>>>>>>>>> 0611
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> hibernate-dev mailing list
>>>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards, Petar!
>>>>>>> Karlovo, Bulgaria.
>>>>>>> ---
>>>>>>> Public PGP Key at:
>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards, Petar!
>>>>> Karlovo, Bulgaria.
>>>>> ---
>>>>> Public PGP Key at:
>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards, Petar!
>>>> Karlovo, Bulgaria.
>>>> ---
>>>> Public PGP Key at:
>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>
>>>
>>>
>>
>

From steve at hibernate.org  Tue Mar 31 19:58:04 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 18:58:04 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9tsQ_i+bShG8U46-fvRVrvfJD8AL4cdrjPULTN5CfCG0g@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFdSV9tsQ_i+bShG8U46-fvRVrvfJD8AL4cdrjPULTN5CfCG0g@mail.gmail.com>
Message-ID: <CAFdSV9sBLSQ-WEht+GFicpSpHW2_Z3-pgmiyNKfLfmmAZAWhhQ@mail.gmail.com>

And no that's not a typo :)  It's JDK6_HOME, but you pass it a Java 7 jdk :)

On Tue, Mar 31, 2015 at 6:56 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Actually this may have been a brain-fart on my part when building the
> release.  I think I may have forgotten to pass in the Java 6 JDK to the
> build, which I use to set the javac bootclasspath.  So in that case it
> would have used the bootclasspath from the Java 8 JDK I used to launch
> gradle.
>
> If you get a chance, you can test that theory by getting the sources and
> running the hibernate-core build again.  You'd have to use Java 8 to launch
> Gradle and pass -PJDK6_HOME=<path-to-java7-jdk>.
>
>
> On Tue, Mar 31, 2015 at 6:36 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Ahh, seems this may be an option to work around it:
>>
>> <quote>
>> Using the general *Map* interface in place of the concrete
>> *ConcurrentHashMap* type here side-steps the coupling to the Java 8
>> return type and will allow this code to be compiled with Java 8 and run on
>> Java 7.
>> </quote>
>>
>> I had missed that part.
>>
>>
>> On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> When I say "internal" here, I mean internal to java classes.
>>>
>>> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> Nope.  It just effects any code compiled with Java 8 even though the
>>>> change is internal.  The problem is the generated bytecode incorporates
>>>> this change.   Like I said, this should be compiled with 1.6 compatibility,
>>>> but that is apparently not working atm.  I am having a struggle getting a
>>>> mixed JDK build working "just right".
>>>>
>>>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <paranoiabla at gmail.com>
>>>> wrote:
>>>>
>>>>> According to this:
>>>>>
>>>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094
>>>>>
>>>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K> while
>>>>> the 1.8*ConcurrentHashMap#keySet()* returns a
>>>>> ConcurrentHashMap.KeySetView<K,V>`.
>>>>>
>>>>> I think you're using some Java8 API.
>>>>>
>>>>>
>>>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>>
>>>>>> petar at petar-ThinkPad-X1-Carbon:~$ java -version
>>>>>> java version "1.7.0_71"
>>>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
>>>>>> petar at petar-ThinkPad-X1-Carbon:~$ uname -a
>>>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu
>>>>>> Mar 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>>>>> petar at petar-ThinkPad-X1-Carbon:~$
>>>>>>
>>>>>>
>>>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>
>>>>>>> What JRE are you trying to use?  This error:
>>>>>>>
>>>>>>> java.lang.NoSuchMethodError: java.util.concurrent.
>>>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/
>>>>>>> ConcurrentHashMap$KeySetView;
>>>>>>>
>>>>>>> is indicative of an issue in cross-jre support due to a change
>>>>>>> internal to java classes.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <
>>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>>
>>>>>>>> Thanks Steve,
>>>>>>>>
>>>>>>>> I managed to migrate my configuration to the new
>>>>>>>> MetamodelImplementor. Now when I run the scema export I get a lot of these
>>>>>>>> warning:
>>>>>>>>
>>>>>>>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>>>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both
>>>>>>>> mixed and upper case
>>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel
>>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel
>>>>>>>>
>>>>>>>> and when I run some test I get the following exception:
>>>>>>>> java.lang.NoSuchMethodError:
>>>>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>>>>>>>     at
>>>>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>>>>>>>     at
>>>>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>>>>>>>     at
>>>>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>>>>>>>     at
>>>>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>>>>>>>     at
>>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>>>>>>>     at
>>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>>>>>>>     at
>>>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>>>>>>>     at
>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>>>>>>>     at
>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>>>>>>>     at
>>>>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>>>>>>>     at
>>>>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>>>>>>>     at
>>>>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>>>
>>>>>>>>> I am told that the bug does not affect the JBoss->Central sync
>>>>>>>>> process.  So at some point the artifacts should all be available in Central
>>>>>>>>>
>>>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <
>>>>>>>>> steve at hibernate.org> wrote:
>>>>>>>>>
>>>>>>>>>> hibernate-core seems to be the only artifact that is available in
>>>>>>>>>> JBoss Nexus.
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <
>>>>>>>>>> steve at hibernate.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>>>>>>>>> effecting the JBoss repo (and therefore us)...
>>>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>>>>>>>>
>>>>>>>>>>> As I pointed out in the announcement, I am managing the
>>>>>>>>>>> "migration guide" in source repo while I develop the Betas.  See
>>>>>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>>>>>>>>  As far are the new bootstrapping apis, see
>>>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>>>>>>>>> and
>>>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>>>>>>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi guys,
>>>>>>>>>>>>
>>>>>>>>>>>> I just tried the latest beta and I cannot compile my project.
>>>>>>>>>>>> With the
>>>>>>>>>>>> latest hibernate 4.3.X I was able to do this:
>>>>>>>>>>>> -------
>>>>>>>>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>>>>>>>>> getHibernateConfiguration();
>>>>>>>>>>>>         configuration.buildMappings();
>>>>>>>>>>>>         final SchemaUpdate schemaUpdate = new
>>>>>>>>>>>> SchemaUpdate(configuration);
>>>>>>>>>>>> -------
>>>>>>>>>>>>
>>>>>>>>>>>> however it seems that the SchemaUpdate constructor has been
>>>>>>>>>>>> removed and now
>>>>>>>>>>>> a new one is added:
>>>>>>>>>>>> --------
>>>>>>>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>>>>>>>>         this(
>>>>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>>>>>>>>> metadata );
>>>>>>>>>>>>     }
>>>>>>>>>>>> ---------
>>>>>>>>>>>>
>>>>>>>>>>>> Also the configuration.buildMappings() method has been
>>>>>>>>>>>> deprecated. Where do
>>>>>>>>>>>> I get the MetadataImplementor from? Also is there any changelog
>>>>>>>>>>>> I can refer
>>>>>>>>>>>> to?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>> --
>>>>>>>>>>>> Regards, Petar!
>>>>>>>>>>>> Karlovo, Bulgaria.
>>>>>>>>>>>> ---
>>>>>>>>>>>> Public PGP Key at:
>>>>>>>>>>>>
>>>>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>>>>>>>>>>>> 0611
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> hibernate-dev mailing list
>>>>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Regards, Petar!
>>>>>>>> Karlovo, Bulgaria.
>>>>>>>> ---
>>>>>>>> Public PGP Key at:
>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards, Petar!
>>>>>> Karlovo, Bulgaria.
>>>>>> ---
>>>>>> Public PGP Key at:
>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards, Petar!
>>>>> Karlovo, Bulgaria.
>>>>> ---
>>>>> Public PGP Key at:
>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>
>>>>
>>>>
>>>
>>
>

From sanne at hibernate.org  Tue Mar 31 19:59:37 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 1 Apr 2015 00:59:37 +0100
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
Message-ID: <CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>

There are many similar issues discussed on the Lucene developer's
mailing list, it's an interesting read:
 - http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401d06aba%240b477c80%2421d67580%24%40thetaphi.de%3E

I see no alternative than to have those test jobs actually exercising
ORM with JDK6, or maybe even compile it all with JDK6 except the Java8
additional module to be compiled with JDK8 ?



On 1 April 2015 at 00:36, Steve Ebersole <steve at hibernate.org> wrote:
> Ahh, seems this may be an option to work around it:
>
> <quote>
> Using the general *Map* interface in place of the concrete
> *ConcurrentHashMap* type here side-steps the coupling to the Java 8 return
> type and will allow this code to be compiled with Java 8 and run on Java 7.
> </quote>
>
> I had missed that part.
>
>
> On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <steve at hibernate.org> wrote:
>
>> When I say "internal" here, I mean internal to java classes.
>>
>> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Nope.  It just effects any code compiled with Java 8 even though the
>>> change is internal.  The problem is the generated bytecode incorporates
>>> this change.   Like I said, this should be compiled with 1.6 compatibility,
>>> but that is apparently not working atm.  I am having a struggle getting a
>>> mixed JDK build working "just right".
>>>
>>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <paranoiabla at gmail.com>
>>> wrote:
>>>
>>>> According to this:
>>>>
>>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094
>>>>
>>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K> while
>>>> the 1.8*ConcurrentHashMap#keySet()* returns a
>>>> ConcurrentHashMap.KeySetView<K,V>`.
>>>>
>>>> I think you're using some Java8 API.
>>>>
>>>>
>>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>
>>>>> petar at petar-ThinkPad-X1-Carbon:~$ java -version
>>>>> java version "1.7.0_71"
>>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
>>>>> petar at petar-ThinkPad-X1-Carbon:~$ uname -a
>>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu Mar
>>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>>>> petar at petar-ThinkPad-X1-Carbon:~$
>>>>>
>>>>>
>>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>>
>>>>>> What JRE are you trying to use?  This error:
>>>>>>
>>>>>> java.lang.NoSuchMethodError: java.util.concurrent.
>>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/
>>>>>> ConcurrentHashMap$KeySetView;
>>>>>>
>>>>>> is indicative of an issue in cross-jre support due to a change
>>>>>> internal to java classes.
>>>>>>
>>>>>>
>>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla at gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Thanks Steve,
>>>>>>>
>>>>>>> I managed to migrate my configuration to the new
>>>>>>> MetamodelImplementor. Now when I run the scema export I get a lot of these
>>>>>>> warning:
>>>>>>>
>>>>>>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both mixed
>>>>>>> and upper case
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>>>>>>> WARN : HHH000072: Duplicate joins for class:
>>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel
>>>>>>>
>>>>>>> and when I run some test I get the following exception:
>>>>>>> java.lang.NoSuchMethodError:
>>>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>>>>>>     at
>>>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>>>>>>     at
>>>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>>>>>>     at
>>>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>>>>>>     at
>>>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>>>>>>     at
>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>>>>>>     at
>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>>>>>>     at
>>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>>>>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>>>>>>     at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>>>>>>     at
>>>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>>>>>>     at
>>>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>>>>>>     at
>>>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>>
>>>>>>>> I am told that the bug does not affect the JBoss->Central sync
>>>>>>>> process.  So at some point the artifacts should all be available in Central
>>>>>>>>
>>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve at hibernate.org
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> hibernate-core seems to be the only artifact that is available in
>>>>>>>>> JBoss Nexus.
>>>>>>>>>
>>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <
>>>>>>>>> steve at hibernate.org> wrote:
>>>>>>>>>
>>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>>>>>>>>>> effecting the JBoss repo (and therefore us)...
>>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>>>>>>>>>
>>>>>>>>>> As I pointed out in the announcement, I am managing the "migration
>>>>>>>>>> guide" in source repo while I develop the Betas.  See
>>>>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>>>>>>>>>  As far are the new bootstrapping apis, see
>>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>>>>>>>> and
>>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>>>>>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi guys,
>>>>>>>>>>>
>>>>>>>>>>> I just tried the latest beta and I cannot compile my project.
>>>>>>>>>>> With the
>>>>>>>>>>> latest hibernate 4.3.X I was able to do this:
>>>>>>>>>>> -------
>>>>>>>>>>>         final org.hibernate.cfg.Configuration configuration =
>>>>>>>>>>> getHibernateConfiguration();
>>>>>>>>>>>         configuration.buildMappings();
>>>>>>>>>>>         final SchemaUpdate schemaUpdate = new
>>>>>>>>>>> SchemaUpdate(configuration);
>>>>>>>>>>> -------
>>>>>>>>>>>
>>>>>>>>>>> however it seems that the SchemaUpdate constructor has been
>>>>>>>>>>> removed and now
>>>>>>>>>>> a new one is added:
>>>>>>>>>>> --------
>>>>>>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>>>>>>>>>>         this(
>>>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>>>>>>>> metadata );
>>>>>>>>>>>     }
>>>>>>>>>>> ---------
>>>>>>>>>>>
>>>>>>>>>>> Also the configuration.buildMappings() method has been
>>>>>>>>>>> deprecated. Where do
>>>>>>>>>>> I get the MetadataImplementor from? Also is there any changelog I
>>>>>>>>>>> can refer
>>>>>>>>>>> to?
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>> --
>>>>>>>>>>> Regards, Petar!
>>>>>>>>>>> Karlovo, Bulgaria.
>>>>>>>>>>> ---
>>>>>>>>>>> Public PGP Key at:
>>>>>>>>>>>
>>>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>>>>>>>>>>> 0611
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> hibernate-dev mailing list
>>>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards, Petar!
>>>>>>> Karlovo, Bulgaria.
>>>>>>> ---
>>>>>>> Public PGP Key at:
>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards, Petar!
>>>>> Karlovo, Bulgaria.
>>>>> ---
>>>>> Public PGP Key at:
>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards, Petar!
>>>> Karlovo, Bulgaria.
>>>> ---
>>>> Public PGP Key at:
>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>
>>>
>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Tue Mar 31 20:04:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 19:04:20 -0500
Subject: [hibernate-dev] Java 6, 7 and 8... oh my!
Message-ID: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>

So we now have to deal with a multi-jdk build in Hibernate ORM.  We need
Java 8 in order to compile the new hibernate-java8 module.

I wanted to remain compatible with Java 6 for the rest.  However, I ran
into a snag there because of JAXB which we now use (in conjunction with
StAX) to process XML in ORM.  ANyway, the JAX generation creates a model
that is only compatible with Java 7.  I have not yet had time to
investigate this deeply.  But it has to do with a change in the definition
of javax.xml.bind.annotation.XmlElement and a change in its definition
between 1.6 and 1.7 to add a new
attribute javax.xml.bind.annotation.XmlElement#required.

If anyone is familiar with this situation, I'd love to hear some options
before I spend a lot of time investigating it.

The other option is that we say we are going to drop Java 6 support since
it has been unsupported now for, what, 3 years?

From steve at hibernate.org  Tue Mar 31 20:13:53 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 19:13:53 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
Message-ID: <CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>

Well the idea is to run the Gradle process with Java 8 (the build itself is
a Java process too don't forget).  We pass in the older JDK specifically to
be able to set the bootclasspath for compilation and the executable for
running tests.  That's the theory.

Interestingly I developed a simplified project to test these theories:
https://github.com/sebersole/gradle-mixed-jdk  And of course this all works
there.  As you'd expect right?

I think the JAXB thing comes into play here as well.  Gradle does not have
any XJC support built in, so we have to make use of its Ant support to run
the XJC Ant tasks for JAXB model generation.  The problem there is that,
afaik, there is no way to tell Gradle's AntBuilder to use a JDK other than
the one that launched Gradle.  I think this is why we see a JAXB model
defined for Java 7, rather than Java 6, because we essentially run XJC with
Java 8.

Anyway, this certainly makes the build more complex and we definitely have
to think through all these scenarios.  In fact after Beta1, one of my todos
is to build up the build "from scratch" using that gradle-mixed-jdk project
as a basis.

In general the plan though is to run all the tests (other than
hibernate-java8, obviously) with the "baseline JDK, whether that be Java 6
or 7.

On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> There are many similar issues discussed on the Lucene developer's
> mailing list, it's an interesting read:
>  -
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401d06aba%240b477c80%2421d67580%24%40thetaphi.de%3E
>
> I see no alternative than to have those test jobs actually exercising
> ORM with JDK6, or maybe even compile it all with JDK6 except the Java8
> additional module to be compiled with JDK8 ?
>
>
>
> On 1 April 2015 at 00:36, Steve Ebersole <steve at hibernate.org> wrote:
> > Ahh, seems this may be an option to work around it:
> >
> > <quote>
> > Using the general *Map* interface in place of the concrete
> > *ConcurrentHashMap* type here side-steps the coupling to the Java 8
> return
> > type and will allow this code to be compiled with Java 8 and run on Java
> 7.
> > </quote>
> >
> > I had missed that part.
> >
> >
> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> When I say "internal" here, I mean internal to java classes.
> >>
> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >>> Nope.  It just effects any code compiled with Java 8 even though the
> >>> change is internal.  The problem is the generated bytecode incorporates
> >>> this change.   Like I said, this should be compiled with 1.6
> compatibility,
> >>> but that is apparently not working atm.  I am having a struggle
> getting a
> >>> mixed JDK build working "just right".
> >>>
> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <paranoiabla at gmail.com
> >
> >>> wrote:
> >>>
> >>>> According to this:
> >>>>
> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094
> >>>>
> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K>
> while
> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a
> >>>> ConcurrentHashMap.KeySetView<K,V>`.
> >>>>
> >>>> I think you're using some Java8 API.
> >>>>
> >>>>
> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
> >>>>
> >>>>> petar at petar-ThinkPad-X1-Carbon:~$ java -version
> >>>>> java version "1.7.0_71"
> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
> >>>>> petar at petar-ThinkPad-X1-Carbon:~$ uname -a
> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu
> Mar
> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> >>>>> petar at petar-ThinkPad-X1-Carbon:~$
> >>>>>
> >>>>>
> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
> >>>>>
> >>>>>> What JRE are you trying to use?  This error:
> >>>>>>
> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent.
> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/
> >>>>>> ConcurrentHashMap$KeySetView;
> >>>>>>
> >>>>>> is indicative of an issue in cross-jre support due to a change
> >>>>>> internal to java classes.
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <
> paranoiabla at gmail.com
> >>>>>> > wrote:
> >>>>>>
> >>>>>>> Thanks Steve,
> >>>>>>>
> >>>>>>> I managed to migrate my configuration to the new
> >>>>>>> MetamodelImplementor. Now when I run the scema export I get a lot
> of these
> >>>>>>> warning:
> >>>>>>>
> >>>>>>> INFO : HHH000400: Using dialect:
> org.hibernate.dialect.MySQL5Dialect
> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both
> mixed
> >>>>>>> and upper case
> >>>>>>> WARN : HHH000072: Duplicate joins for class:
> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel
> >>>>>>> WARN : HHH000072: Duplicate joins for class:
> >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
> >>>>>>> WARN : HHH000072: Duplicate joins for class:
> >>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
> >>>>>>> WARN : HHH000072: Duplicate joins for class:
> >>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
> >>>>>>> WARN : HHH000072: Duplicate joins for class:
> >>>>>>>
> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
> >>>>>>> WARN : HHH000072: Duplicate joins for class:
> >>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
> >>>>>>> WARN : HHH000072: Duplicate joins for class:
> >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel
> >>>>>>>
> >>>>>>> and when I run some test I get the following exception:
> >>>>>>> java.lang.NoSuchMethodError:
> >>>>>>>
> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
> >>>>>>>     at
> >>>>>>>
> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
> >>>>>>>     at
> >>>>>>>
> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
> >>>>>>>     at
> >>>>>>>
> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
> >>>>>>>     at
> >>>>>>>
> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
> >>>>>>>     at
> >>>>>>>
> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
> >>>>>>>     at
> >>>>>>>
> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
> >>>>>>>     at
> >>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
> >>>>>>>     at
> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
> >>>>>>>     at
> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
> >>>>>>>     at
> >>>>>>>
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
> >>>>>>>     at
> >>>>>>>
> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
> >>>>>>>     at
> >>>>>>>
> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
> >>>>>>>
> >>>>>>>> I am told that the bug does not affect the JBoss->Central sync
> >>>>>>>> process.  So at some point the artifacts should all be available
> in Central
> >>>>>>>>
> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <
> steve at hibernate.org
> >>>>>>>> > wrote:
> >>>>>>>>
> >>>>>>>>> hibernate-core seems to be the only artifact that is available in
> >>>>>>>>> JBoss Nexus.
> >>>>>>>>>
> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <
> >>>>>>>>> steve at hibernate.org> wrote:
> >>>>>>>>>
> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
> >>>>>>>>>> effecting the JBoss repo (and therefore us)...
> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
> >>>>>>>>>>
> >>>>>>>>>> As I pointed out in the announcement, I am managing the
> "migration
> >>>>>>>>>> guide" in source repo while I develop the Betas.  See
> >>>>>>>>>>
> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
> >>>>>>>>>>  As far are the new bootstrapping apis, see
> >>>>>>>>>>
> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
> >>>>>>>>>> and
> >>>>>>>>>>
> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
> >>>>>>>>>> paranoiabla at gmail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi guys,
> >>>>>>>>>>>
> >>>>>>>>>>> I just tried the latest beta and I cannot compile my project.
> >>>>>>>>>>> With the
> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this:
> >>>>>>>>>>> -------
> >>>>>>>>>>>         final org.hibernate.cfg.Configuration configuration =
> >>>>>>>>>>> getHibernateConfiguration();
> >>>>>>>>>>>         configuration.buildMappings();
> >>>>>>>>>>>         final SchemaUpdate schemaUpdate = new
> >>>>>>>>>>> SchemaUpdate(configuration);
> >>>>>>>>>>> -------
> >>>>>>>>>>>
> >>>>>>>>>>> however it seems that the SchemaUpdate constructor has been
> >>>>>>>>>>> removed and now
> >>>>>>>>>>> a new one is added:
> >>>>>>>>>>> --------
> >>>>>>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
> >>>>>>>>>>>         this(
> >>>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
> >>>>>>>>>>> metadata );
> >>>>>>>>>>>     }
> >>>>>>>>>>> ---------
> >>>>>>>>>>>
> >>>>>>>>>>> Also the configuration.buildMappings() method has been
> >>>>>>>>>>> deprecated. Where do
> >>>>>>>>>>> I get the MetadataImplementor from? Also is there any
> changelog I
> >>>>>>>>>>> can refer
> >>>>>>>>>>> to?
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks.
> >>>>>>>>>>> --
> >>>>>>>>>>> Regards, Petar!
> >>>>>>>>>>> Karlovo, Bulgaria.
> >>>>>>>>>>> ---
> >>>>>>>>>>> Public PGP Key at:
> >>>>>>>>>>>
> >>>>>>>>>>>
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
> >>>>>>>>>>> 0611
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> hibernate-dev mailing list
> >>>>>>>>>>> hibernate-dev at lists.jboss.org
> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Regards, Petar!
> >>>>>>> Karlovo, Bulgaria.
> >>>>>>> ---
> >>>>>>> Public PGP Key at:
> >>>>>>>
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Regards, Petar!
> >>>>> Karlovo, Bulgaria.
> >>>>> ---
> >>>>> Public PGP Key at:
> >>>>>
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Regards, Petar!
> >>>> Karlovo, Bulgaria.
> >>>> ---
> >>>> Public PGP Key at:
> >>>>
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >>>>
> >>>
> >>>
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From paranoiabla at gmail.com  Tue Mar 31 20:18:38 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 1 Apr 2015 03:18:38 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
Message-ID: <CAKnbemXkBcBNNtwYCBPWQ2pNHovWd8NZ+cEijjbt3BUWDe-3qg@mail.gmail.com>

Hi all,

just to confirm - I tried it with java8 and the exception is gone. I still
see the "Duplicate joins for class.." error, as well as a new foreign key
exception:

WARN : SQL Error: 1452, SQLState: 23000
ERROR: Cannot add or update a child row: a foreign key constraint fails
(`solarapparel`.`entity_filters`, CONSTRAINT `FK6yx2wc1w1yb6qa1cx4byv7mju`
FOREIGN KEY (`entity_pk`) REFERENCES `classification_feature` (`pk`))
ERROR: HHH000315: Exception executing batch [could not execute batch]
ERROR: Encountered an error executing step csv-import in job ncsvImportJob
javax.persistence.PersistenceException:
org.hibernate.exception.ConstraintViolationException: could not execute
batch
    at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
    at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677)
    at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1683)
    at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1338)
    at
org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:84)


2015-04-01 3:13 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> Well the idea is to run the Gradle process with Java 8 (the build itself
> is a Java process too don't forget).  We pass in the older JDK specifically
> to be able to set the bootclasspath for compilation and the executable for
> running tests.  That's the theory.
>
> Interestingly I developed a simplified project to test these theories:
> https://github.com/sebersole/gradle-mixed-jdk  And of course this all
> works there.  As you'd expect right?
>
> I think the JAXB thing comes into play here as well.  Gradle does not have
> any XJC support built in, so we have to make use of its Ant support to run
> the XJC Ant tasks for JAXB model generation.  The problem there is that,
> afaik, there is no way to tell Gradle's AntBuilder to use a JDK other than
> the one that launched Gradle.  I think this is why we see a JAXB model
> defined for Java 7, rather than Java 6, because we essentially run XJC with
> Java 8.
>
> Anyway, this certainly makes the build more complex and we definitely have
> to think through all these scenarios.  In fact after Beta1, one of my todos
> is to build up the build "from scratch" using that gradle-mixed-jdk project
> as a basis.
>
> In general the plan though is to run all the tests (other than
> hibernate-java8, obviously) with the "baseline JDK, whether that be Java 6
> or 7.
>
> On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> There are many similar issues discussed on the Lucene developer's
>> mailing list, it's an interesting read:
>>  -
>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401d06aba%240b477c80%2421d67580%24%40thetaphi.de%3E
>>
>> I see no alternative than to have those test jobs actually exercising
>> ORM with JDK6, or maybe even compile it all with JDK6 except the Java8
>> additional module to be compiled with JDK8 ?
>>
>>
>>
>> On 1 April 2015 at 00:36, Steve Ebersole <steve at hibernate.org> wrote:
>> > Ahh, seems this may be an option to work around it:
>> >
>> > <quote>
>> > Using the general *Map* interface in place of the concrete
>> > *ConcurrentHashMap* type here side-steps the coupling to the Java 8
>> return
>> > type and will allow this code to be compiled with Java 8 and run on
>> Java 7.
>> > </quote>
>> >
>> > I had missed that part.
>> >
>> >
>> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >
>> >> When I say "internal" here, I mean internal to java classes.
>> >>
>> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <steve at hibernate.org>
>> >> wrote:
>> >>
>> >>> Nope.  It just effects any code compiled with Java 8 even though the
>> >>> change is internal.  The problem is the generated bytecode
>> incorporates
>> >>> this change.   Like I said, this should be compiled with 1.6
>> compatibility,
>> >>> but that is apparently not working atm.  I am having a struggle
>> getting a
>> >>> mixed JDK build working "just right".
>> >>>
>> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <
>> paranoiabla at gmail.com>
>> >>> wrote:
>> >>>
>> >>>> According to this:
>> >>>>
>> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094
>> >>>>
>> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K>
>> while
>> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a
>> >>>> ConcurrentHashMap.KeySetView<K,V>`.
>> >>>>
>> >>>> I think you're using some Java8 API.
>> >>>>
>> >>>>
>> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>> >>>>
>> >>>>> petar at petar-ThinkPad-X1-Carbon:~$ java -version
>> >>>>> java version "1.7.0_71"
>> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
>> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
>> >>>>> petar at petar-ThinkPad-X1-Carbon:~$ uname -a
>> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu
>> Mar
>> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>> >>>>> petar at petar-ThinkPad-X1-Carbon:~$
>> >>>>>
>> >>>>>
>> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>> >>>>>
>> >>>>>> What JRE are you trying to use?  This error:
>> >>>>>>
>> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent.
>> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/
>> >>>>>> ConcurrentHashMap$KeySetView;
>> >>>>>>
>> >>>>>> is indicative of an issue in cross-jre support due to a change
>> >>>>>> internal to java classes.
>> >>>>>>
>> >>>>>>
>> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <
>> paranoiabla at gmail.com
>> >>>>>> > wrote:
>> >>>>>>
>> >>>>>>> Thanks Steve,
>> >>>>>>>
>> >>>>>>> I managed to migrate my configuration to the new
>> >>>>>>> MetamodelImplementor. Now when I run the scema export I get a lot
>> of these
>> >>>>>>> warning:
>> >>>>>>>
>> >>>>>>> INFO : HHH000400: Using dialect:
>> org.hibernate.dialect.MySQL5Dialect
>> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both
>> mixed
>> >>>>>>> and upper case
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>>
>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel
>> >>>>>>>
>> >>>>>>> and when I run some test I get the following exception:
>> >>>>>>> java.lang.NoSuchMethodError:
>> >>>>>>>
>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>> >>>>>>>     at
>> >>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>> >>>>>>>     at
>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>> >>>>>>>     at
>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>> >>>>>>>     at
>> >>>>>>>
>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>> >>>>>>>     at
>> >>>>>>>
>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>> >>>>>>>
>> >>>>>>>> I am told that the bug does not affect the JBoss->Central sync
>> >>>>>>>> process.  So at some point the artifacts should all be available
>> in Central
>> >>>>>>>>
>> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <
>> steve at hibernate.org
>> >>>>>>>> > wrote:
>> >>>>>>>>
>> >>>>>>>>> hibernate-core seems to be the only artifact that is available
>> in
>> >>>>>>>>> JBoss Nexus.
>> >>>>>>>>>
>> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <
>> >>>>>>>>> steve at hibernate.org> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>> >>>>>>>>>> effecting the JBoss repo (and therefore us)...
>> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>> >>>>>>>>>>
>> >>>>>>>>>> As I pointed out in the announcement, I am managing the
>> "migration
>> >>>>>>>>>> guide" in source repo while I develop the Betas.  See
>> >>>>>>>>>>
>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>> >>>>>>>>>>  As far are the new bootstrapping apis, see
>> >>>>>>>>>>
>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>> >>>>>>>>>> and
>> >>>>>>>>>>
>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>> >>>>>>>>>>
>> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>> >>>>>>>>>> paranoiabla at gmail.com> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> Hi guys,
>> >>>>>>>>>>>
>> >>>>>>>>>>> I just tried the latest beta and I cannot compile my project.
>> >>>>>>>>>>> With the
>> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this:
>> >>>>>>>>>>> -------
>> >>>>>>>>>>>         final org.hibernate.cfg.Configuration configuration =
>> >>>>>>>>>>> getHibernateConfiguration();
>> >>>>>>>>>>>         configuration.buildMappings();
>> >>>>>>>>>>>         final SchemaUpdate schemaUpdate = new
>> >>>>>>>>>>> SchemaUpdate(configuration);
>> >>>>>>>>>>> -------
>> >>>>>>>>>>>
>> >>>>>>>>>>> however it seems that the SchemaUpdate constructor has been
>> >>>>>>>>>>> removed and now
>> >>>>>>>>>>> a new one is added:
>> >>>>>>>>>>> --------
>> >>>>>>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>> >>>>>>>>>>>         this(
>> >>>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>> >>>>>>>>>>> metadata );
>> >>>>>>>>>>>     }
>> >>>>>>>>>>> ---------
>> >>>>>>>>>>>
>> >>>>>>>>>>> Also the configuration.buildMappings() method has been
>> >>>>>>>>>>> deprecated. Where do
>> >>>>>>>>>>> I get the MetadataImplementor from? Also is there any
>> changelog I
>> >>>>>>>>>>> can refer
>> >>>>>>>>>>> to?
>> >>>>>>>>>>>
>> >>>>>>>>>>> Thanks.
>> >>>>>>>>>>> --
>> >>>>>>>>>>> Regards, Petar!
>> >>>>>>>>>>> Karlovo, Bulgaria.
>> >>>>>>>>>>> ---
>> >>>>>>>>>>> Public PGP Key at:
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>> >>>>>>>>>>> 0611
>> >>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>> hibernate-dev mailing list
>> >>>>>>>>>>> hibernate-dev at lists.jboss.org
>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Regards, Petar!
>> >>>>>>> Karlovo, Bulgaria.
>> >>>>>>> ---
>> >>>>>>> Public PGP Key at:
>> >>>>>>>
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>> 0611
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Regards, Petar!
>> >>>>> Karlovo, Bulgaria.
>> >>>>> ---
>> >>>>> Public PGP Key at:
>> >>>>>
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Regards, Petar!
>> >>>> Karlovo, Bulgaria.
>> >>>> ---
>> >>>> Public PGP Key at:
>> >>>>
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> >>>>
>> >>>
>> >>>
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From sanne at hibernate.org  Tue Mar 31 20:18:56 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 1 Apr 2015 01:18:56 +0100
Subject: [hibernate-dev] Java 6, 7 and 8... oh my!
In-Reply-To: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
References: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
Message-ID: <CAFm4XO1KUTg6qqquu7o=FhKXPz4DfdJk4G9LAXf-KG8adBUuoQ@mail.gmail.com>

I wouldn't disagree on requiring Java 7.
I probably wouldn't disagree with Java 8 either, after all we're not
removing older versions of Hibernate from any download location and
we'll still support and maintain some older versions. It would
actually be nice to have the latest ORM version to be able to
experiment with significant API improvements.

FYI Hibernate Search is requiring Java 7 already, and our CI servers
are already testing our projects with JDK9 as well.

That said, Java 6 is still being supported by some vendors. Not by
Oracle, but Red Hat and SAP will support it for much longer.

-- Sanne

On 1 April 2015 at 01:04, Steve Ebersole <steve at hibernate.org> wrote:
> So we now have to deal with a multi-jdk build in Hibernate ORM.  We need
> Java 8 in order to compile the new hibernate-java8 module.
>
> I wanted to remain compatible with Java 6 for the rest.  However, I ran
> into a snag there because of JAXB which we now use (in conjunction with
> StAX) to process XML in ORM.  ANyway, the JAX generation creates a model
> that is only compatible with Java 7.  I have not yet had time to
> investigate this deeply.  But it has to do with a change in the definition
> of javax.xml.bind.annotation.XmlElement and a change in its definition
> between 1.6 and 1.7 to add a new
> attribute javax.xml.bind.annotation.XmlElement#required.
>
> If anyone is familiar with this situation, I'd love to hear some options
> before I spend a lot of time investigating it.
>
> The other option is that we say we are going to drop Java 6 support since
> it has been unsupported now for, what, 3 years?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Tue Mar 31 20:21:03 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 19:21:03 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
Message-ID: <CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>

Just to clarify...  I *think* that as long as we run the build with Java 8
and set the bootclasspath to 6 or 7 we should be fine.

On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Well the idea is to run the Gradle process with Java 8 (the build itself
> is a Java process too don't forget).  We pass in the older JDK specifically
> to be able to set the bootclasspath for compilation and the executable for
> running tests.  That's the theory.
>
> Interestingly I developed a simplified project to test these theories:
> https://github.com/sebersole/gradle-mixed-jdk  And of course this all
> works there.  As you'd expect right?
>
> I think the JAXB thing comes into play here as well.  Gradle does not have
> any XJC support built in, so we have to make use of its Ant support to run
> the XJC Ant tasks for JAXB model generation.  The problem there is that,
> afaik, there is no way to tell Gradle's AntBuilder to use a JDK other than
> the one that launched Gradle.  I think this is why we see a JAXB model
> defined for Java 7, rather than Java 6, because we essentially run XJC with
> Java 8.
>
> Anyway, this certainly makes the build more complex and we definitely have
> to think through all these scenarios.  In fact after Beta1, one of my todos
> is to build up the build "from scratch" using that gradle-mixed-jdk project
> as a basis.
>
> In general the plan though is to run all the tests (other than
> hibernate-java8, obviously) with the "baseline JDK, whether that be Java 6
> or 7.
>
> On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> There are many similar issues discussed on the Lucene developer's
>> mailing list, it's an interesting read:
>>  -
>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401d06aba%240b477c80%2421d67580%24%40thetaphi.de%3E
>>
>> I see no alternative than to have those test jobs actually exercising
>> ORM with JDK6, or maybe even compile it all with JDK6 except the Java8
>> additional module to be compiled with JDK8 ?
>>
>>
>>
>> On 1 April 2015 at 00:36, Steve Ebersole <steve at hibernate.org> wrote:
>> > Ahh, seems this may be an option to work around it:
>> >
>> > <quote>
>> > Using the general *Map* interface in place of the concrete
>> > *ConcurrentHashMap* type here side-steps the coupling to the Java 8
>> return
>> > type and will allow this code to be compiled with Java 8 and run on
>> Java 7.
>> > </quote>
>> >
>> > I had missed that part.
>> >
>> >
>> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >
>> >> When I say "internal" here, I mean internal to java classes.
>> >>
>> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <steve at hibernate.org>
>> >> wrote:
>> >>
>> >>> Nope.  It just effects any code compiled with Java 8 even though the
>> >>> change is internal.  The problem is the generated bytecode
>> incorporates
>> >>> this change.   Like I said, this should be compiled with 1.6
>> compatibility,
>> >>> but that is apparently not working atm.  I am having a struggle
>> getting a
>> >>> mixed JDK build working "just right".
>> >>>
>> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <
>> paranoiabla at gmail.com>
>> >>> wrote:
>> >>>
>> >>>> According to this:
>> >>>>
>> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094
>> >>>>
>> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K>
>> while
>> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a
>> >>>> ConcurrentHashMap.KeySetView<K,V>`.
>> >>>>
>> >>>> I think you're using some Java8 API.
>> >>>>
>> >>>>
>> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>> >>>>
>> >>>>> petar at petar-ThinkPad-X1-Carbon:~$ java -version
>> >>>>> java version "1.7.0_71"
>> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
>> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
>> >>>>> petar at petar-ThinkPad-X1-Carbon:~$ uname -a
>> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu
>> Mar
>> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>> >>>>> petar at petar-ThinkPad-X1-Carbon:~$
>> >>>>>
>> >>>>>
>> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>> >>>>>
>> >>>>>> What JRE are you trying to use?  This error:
>> >>>>>>
>> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent.
>> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/
>> >>>>>> ConcurrentHashMap$KeySetView;
>> >>>>>>
>> >>>>>> is indicative of an issue in cross-jre support due to a change
>> >>>>>> internal to java classes.
>> >>>>>>
>> >>>>>>
>> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <
>> paranoiabla at gmail.com
>> >>>>>> > wrote:
>> >>>>>>
>> >>>>>>> Thanks Steve,
>> >>>>>>>
>> >>>>>>> I managed to migrate my configuration to the new
>> >>>>>>> MetamodelImplementor. Now when I run the scema export I get a lot
>> of these
>> >>>>>>> warning:
>> >>>>>>>
>> >>>>>>> INFO : HHH000400: Using dialect:
>> org.hibernate.dialect.MySQL5Dialect
>> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both
>> mixed
>> >>>>>>> and upper case
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>>
>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel
>> >>>>>>>
>> >>>>>>> and when I run some test I get the following exception:
>> >>>>>>> java.lang.NoSuchMethodError:
>> >>>>>>>
>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>> >>>>>>>     at
>> >>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>> >>>>>>>     at
>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>> >>>>>>>     at
>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>> >>>>>>>     at
>> >>>>>>>
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>> >>>>>>>     at
>> >>>>>>>
>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>> >>>>>>>     at
>> >>>>>>>
>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>> >>>>>>>
>> >>>>>>>> I am told that the bug does not affect the JBoss->Central sync
>> >>>>>>>> process.  So at some point the artifacts should all be available
>> in Central
>> >>>>>>>>
>> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <
>> steve at hibernate.org
>> >>>>>>>> > wrote:
>> >>>>>>>>
>> >>>>>>>>> hibernate-core seems to be the only artifact that is available
>> in
>> >>>>>>>>> JBoss Nexus.
>> >>>>>>>>>
>> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <
>> >>>>>>>>> steve at hibernate.org> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is
>> >>>>>>>>>> effecting the JBoss repo (and therefore us)...
>> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>> >>>>>>>>>>
>> >>>>>>>>>> As I pointed out in the announcement, I am managing the
>> "migration
>> >>>>>>>>>> guide" in source repo while I develop the Betas.  See
>> >>>>>>>>>>
>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>> >>>>>>>>>>  As far are the new bootstrapping apis, see
>> >>>>>>>>>>
>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>> >>>>>>>>>> and
>> >>>>>>>>>>
>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>> >>>>>>>>>>
>> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>> >>>>>>>>>> paranoiabla at gmail.com> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> Hi guys,
>> >>>>>>>>>>>
>> >>>>>>>>>>> I just tried the latest beta and I cannot compile my project.
>> >>>>>>>>>>> With the
>> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this:
>> >>>>>>>>>>> -------
>> >>>>>>>>>>>         final org.hibernate.cfg.Configuration configuration =
>> >>>>>>>>>>> getHibernateConfiguration();
>> >>>>>>>>>>>         configuration.buildMappings();
>> >>>>>>>>>>>         final SchemaUpdate schemaUpdate = new
>> >>>>>>>>>>> SchemaUpdate(configuration);
>> >>>>>>>>>>> -------
>> >>>>>>>>>>>
>> >>>>>>>>>>> however it seems that the SchemaUpdate constructor has been
>> >>>>>>>>>>> removed and now
>> >>>>>>>>>>> a new one is added:
>> >>>>>>>>>>> --------
>> >>>>>>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>> >>>>>>>>>>>         this(
>> >>>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>> >>>>>>>>>>> metadata );
>> >>>>>>>>>>>     }
>> >>>>>>>>>>> ---------
>> >>>>>>>>>>>
>> >>>>>>>>>>> Also the configuration.buildMappings() method has been
>> >>>>>>>>>>> deprecated. Where do
>> >>>>>>>>>>> I get the MetadataImplementor from? Also is there any
>> changelog I
>> >>>>>>>>>>> can refer
>> >>>>>>>>>>> to?
>> >>>>>>>>>>>
>> >>>>>>>>>>> Thanks.
>> >>>>>>>>>>> --
>> >>>>>>>>>>> Regards, Petar!
>> >>>>>>>>>>> Karlovo, Bulgaria.
>> >>>>>>>>>>> ---
>> >>>>>>>>>>> Public PGP Key at:
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>> >>>>>>>>>>> 0611
>> >>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>> hibernate-dev mailing list
>> >>>>>>>>>>> hibernate-dev at lists.jboss.org
>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Regards, Petar!
>> >>>>>>> Karlovo, Bulgaria.
>> >>>>>>> ---
>> >>>>>>> Public PGP Key at:
>> >>>>>>>
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>> 0611
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Regards, Petar!
>> >>>>> Karlovo, Bulgaria.
>> >>>>> ---
>> >>>>> Public PGP Key at:
>> >>>>>
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Regards, Petar!
>> >>>> Karlovo, Bulgaria.
>> >>>> ---
>> >>>> Public PGP Key at:
>> >>>>
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> >>>>
>> >>>
>> >>>
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Tue Mar 31 20:22:34 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 19:22:34 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemXkBcBNNtwYCBPWQ2pNHovWd8NZ+cEijjbt3BUWDe-3qg@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAKnbemXkBcBNNtwYCBPWQ2pNHovWd8NZ+cEijjbt3BUWDe-3qg@mail.gmail.com>
Message-ID: <CAFdSV9tG9J2xrBBR1SFOBQ_S3WVG1hoRgEq-zrW1985pDr72Pw@mail.gmail.com>

Those messages are not errors, just warnings.  To be precise...

Not sure about that constraint one.  Would need more info.

On Tue, Mar 31, 2015 at 7:18 PM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Hi all,
>
> just to confirm - I tried it with java8 and the exception is gone. I still
> see the "Duplicate joins for class.." error, as well as a new foreign key
> exception:
>
> WARN : SQL Error: 1452, SQLState: 23000
> ERROR: Cannot add or update a child row: a foreign key constraint fails
> (`solarapparel`.`entity_filters`, CONSTRAINT `FK6yx2wc1w1yb6qa1cx4byv7mju`
> FOREIGN KEY (`entity_pk`) REFERENCES `classification_feature` (`pk`))
> ERROR: HHH000315: Exception executing batch [could not execute batch]
> ERROR: Encountered an error executing step csv-import in job ncsvImportJob
> javax.persistence.PersistenceException:
> org.hibernate.exception.ConstraintViolationException: could not execute
> batch
>     at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
>     at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677)
>     at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1683)
>     at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1338)
>     at
> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:84)
>
>
> 2015-04-01 3:13 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> Well the idea is to run the Gradle process with Java 8 (the build itself
>> is a Java process too don't forget).  We pass in the older JDK specifically
>> to be able to set the bootclasspath for compilation and the executable for
>> running tests.  That's the theory.
>>
>> Interestingly I developed a simplified project to test these theories:
>> https://github.com/sebersole/gradle-mixed-jdk  And of course this all
>> works there.  As you'd expect right?
>>
>> I think the JAXB thing comes into play here as well.  Gradle does not
>> have any XJC support built in, so we have to make use of its Ant support to
>> run the XJC Ant tasks for JAXB model generation.  The problem there is
>> that, afaik, there is no way to tell Gradle's AntBuilder to use a JDK other
>> than the one that launched Gradle.  I think this is why we see a JAXB model
>> defined for Java 7, rather than Java 6, because we essentially run XJC with
>> Java 8.
>>
>> Anyway, this certainly makes the build more complex and we definitely
>> have to think through all these scenarios.  In fact after Beta1, one of my
>> todos is to build up the build "from scratch" using that gradle-mixed-jdk
>> project as a basis.
>>
>> In general the plan though is to run all the tests (other than
>> hibernate-java8, obviously) with the "baseline JDK, whether that be Java 6
>> or 7.
>>
>> On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>>> There are many similar issues discussed on the Lucene developer's
>>> mailing list, it's an interesting read:
>>>  -
>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401d06aba%240b477c80%2421d67580%24%40thetaphi.de%3E
>>>
>>> I see no alternative than to have those test jobs actually exercising
>>> ORM with JDK6, or maybe even compile it all with JDK6 except the Java8
>>> additional module to be compiled with JDK8 ?
>>>
>>>
>>>
>>> On 1 April 2015 at 00:36, Steve Ebersole <steve at hibernate.org> wrote:
>>> > Ahh, seems this may be an option to work around it:
>>> >
>>> > <quote>
>>> > Using the general *Map* interface in place of the concrete
>>> > *ConcurrentHashMap* type here side-steps the coupling to the Java 8
>>> return
>>> > type and will allow this code to be compiled with Java 8 and run on
>>> Java 7.
>>> > </quote>
>>> >
>>> > I had missed that part.
>>> >
>>> >
>>> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>> >
>>> >> When I say "internal" here, I mean internal to java classes.
>>> >>
>>> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <steve at hibernate.org>
>>> >> wrote:
>>> >>
>>> >>> Nope.  It just effects any code compiled with Java 8 even though the
>>> >>> change is internal.  The problem is the generated bytecode
>>> incorporates
>>> >>> this change.   Like I said, this should be compiled with 1.6
>>> compatibility,
>>> >>> but that is apparently not working atm.  I am having a struggle
>>> getting a
>>> >>> mixed JDK build working "just right".
>>> >>>
>>> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <
>>> paranoiabla at gmail.com>
>>> >>> wrote:
>>> >>>
>>> >>>> According to this:
>>> >>>>
>>> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094
>>> >>>>
>>> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K>
>>> while
>>> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a
>>> >>>> ConcurrentHashMap.KeySetView<K,V>`.
>>> >>>>
>>> >>>> I think you're using some Java8 API.
>>> >>>>
>>> >>>>
>>> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>> >>>>
>>> >>>>> petar at petar-ThinkPad-X1-Carbon:~$ java -version
>>> >>>>> java version "1.7.0_71"
>>> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
>>> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
>>> >>>>> petar at petar-ThinkPad-X1-Carbon:~$ uname -a
>>> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP
>>> Thu Mar
>>> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>> >>>>> petar at petar-ThinkPad-X1-Carbon:~$
>>> >>>>>
>>> >>>>>
>>> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>> >>>>>
>>> >>>>>> What JRE are you trying to use?  This error:
>>> >>>>>>
>>> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent.
>>> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/
>>> >>>>>> ConcurrentHashMap$KeySetView;
>>> >>>>>>
>>> >>>>>> is indicative of an issue in cross-jre support due to a change
>>> >>>>>> internal to java classes.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <
>>> paranoiabla at gmail.com
>>> >>>>>> > wrote:
>>> >>>>>>
>>> >>>>>>> Thanks Steve,
>>> >>>>>>>
>>> >>>>>>> I managed to migrate my configuration to the new
>>> >>>>>>> MetamodelImplementor. Now when I run the scema export I get a
>>> lot of these
>>> >>>>>>> warning:
>>> >>>>>>>
>>> >>>>>>> INFO : HHH000400: Using dialect:
>>> org.hibernate.dialect.MySQL5Dialect
>>> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both
>>> mixed
>>> >>>>>>> and upper case
>>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>>> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel
>>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>>> >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>>> >>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>>> >>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>>> >>>>>>>
>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>>> >>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>>> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>>> >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel
>>> >>>>>>>
>>> >>>>>>> and when I run some test I get the following exception:
>>> >>>>>>> java.lang.NoSuchMethodError:
>>> >>>>>>>
>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>> >>>>>>>     at
>>> >>>>>>>
>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>> >>>>>>>     at
>>> >>>>>>>
>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>> >>>>>>>     at
>>> >>>>>>>
>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>> >>>>>>>     at
>>> >>>>>>>
>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>> >>>>>>>     at
>>> >>>>>>>
>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>> >>>>>>>     at
>>> >>>>>>>
>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>> >>>>>>>     at
>>> >>>>>>>
>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>> >>>>>>>     at
>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>> >>>>>>>     at
>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>> >>>>>>>     at
>>> >>>>>>>
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>> >>>>>>>     at
>>> >>>>>>>
>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>> >>>>>>>     at
>>> >>>>>>>
>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>> >>>>>>>
>>> >>>>>>>> I am told that the bug does not affect the JBoss->Central sync
>>> >>>>>>>> process.  So at some point the artifacts should all be
>>> available in Central
>>> >>>>>>>>
>>> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <
>>> steve at hibernate.org
>>> >>>>>>>> > wrote:
>>> >>>>>>>>
>>> >>>>>>>>> hibernate-core seems to be the only artifact that is available
>>> in
>>> >>>>>>>>> JBoss Nexus.
>>> >>>>>>>>>
>>> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <
>>> >>>>>>>>> steve at hibernate.org> wrote:
>>> >>>>>>>>>
>>> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that
>>> is
>>> >>>>>>>>>> effecting the JBoss repo (and therefore us)...
>>> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>>> >>>>>>>>>>
>>> >>>>>>>>>> As I pointed out in the announcement, I am managing the
>>> "migration
>>> >>>>>>>>>> guide" in source repo while I develop the Betas.  See
>>> >>>>>>>>>>
>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>>> >>>>>>>>>>  As far are the new bootstrapping apis, see
>>> >>>>>>>>>>
>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>> >>>>>>>>>> and
>>> >>>>>>>>>>
>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>> >>>>>>>>>>
>>> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>>> >>>>>>>>>> paranoiabla at gmail.com> wrote:
>>> >>>>>>>>>>
>>> >>>>>>>>>>> Hi guys,
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> I just tried the latest beta and I cannot compile my project.
>>> >>>>>>>>>>> With the
>>> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this:
>>> >>>>>>>>>>> -------
>>> >>>>>>>>>>>         final org.hibernate.cfg.Configuration configuration =
>>> >>>>>>>>>>> getHibernateConfiguration();
>>> >>>>>>>>>>>         configuration.buildMappings();
>>> >>>>>>>>>>>         final SchemaUpdate schemaUpdate = new
>>> >>>>>>>>>>> SchemaUpdate(configuration);
>>> >>>>>>>>>>> -------
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> however it seems that the SchemaUpdate constructor has been
>>> >>>>>>>>>>> removed and now
>>> >>>>>>>>>>> a new one is added:
>>> >>>>>>>>>>> --------
>>> >>>>>>>>>>>     public SchemaUpdate(MetadataImplementor metadata) {
>>> >>>>>>>>>>>         this(
>>> >>>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>> >>>>>>>>>>> metadata );
>>> >>>>>>>>>>>     }
>>> >>>>>>>>>>> ---------
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Also the configuration.buildMappings() method has been
>>> >>>>>>>>>>> deprecated. Where do
>>> >>>>>>>>>>> I get the MetadataImplementor from? Also is there any
>>> changelog I
>>> >>>>>>>>>>> can refer
>>> >>>>>>>>>>> to?
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Thanks.
>>> >>>>>>>>>>> --
>>> >>>>>>>>>>> Regards, Petar!
>>> >>>>>>>>>>> Karlovo, Bulgaria.
>>> >>>>>>>>>>> ---
>>> >>>>>>>>>>> Public PGP Key at:
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550
>>> C311
>>> >>>>>>>>>>> 0611
>>> >>>>>>>>>>> _______________________________________________
>>> >>>>>>>>>>> hibernate-dev mailing list
>>> >>>>>>>>>>> hibernate-dev at lists.jboss.org
>>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> --
>>> >>>>>>> Regards, Petar!
>>> >>>>>>> Karlovo, Bulgaria.
>>> >>>>>>> ---
>>> >>>>>>> Public PGP Key at:
>>> >>>>>>>
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>>> 0611
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> Regards, Petar!
>>> >>>>> Karlovo, Bulgaria.
>>> >>>>> ---
>>> >>>>> Public PGP Key at:
>>> >>>>>
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Regards, Petar!
>>> >>>> Karlovo, Bulgaria.
>>> >>>> ---
>>> >>>> Public PGP Key at:
>>> >>>>
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>> >>>>
>>> >>>
>>> >>>
>>> >>
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

From steve at hibernate.org  Tue Mar 31 22:43:46 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 31 Mar 2015 21:43:46 -0500
Subject: [hibernate-dev] Release YML
In-Reply-To: <CAFdSV9v-F1Fdinx7RUz3jdK+vmxhngEfhV9h1TKL1+p+OVw0eQ@mail.gmail.com>
References: <CAFdSV9v-F1Fdinx7RUz3jdK+vmxhngEfhV9h1TKL1+p+OVw0eQ@mail.gmail.com>
Message-ID: <CAFdSV9uJSUrysw=w5QBn69P9W5OqBeEPAW8zaQMFCoAMU=6QFQ@mail.gmail.com>

For today's release I added a YML file to both staging staging and verified
that the staging site picked it up properly.  I then pushed it to the
production branch, but it is not being displayed there.  Any idea why?

https://github.com/hibernate/hibernate.org/blob/production/_data/projects/orm/releases/5.0.0.Beta1.yml