From guillaume.smet at gmail.com  Sun Oct  1 10:05:58 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Sun, 1 Oct 2017 16:05:58 +0200
Subject: [hibernate-dev] New layout for in.relation.to
In-Reply-To: <CALt0+o_r-Mg2GeFCBgbSynWq8hyg4oBBn=2vB2T9njmr4wzsMQ@mail.gmail.com>
References: <CALt0+o_r-Mg2GeFCBgbSynWq8hyg4oBBn=2vB2T9njmr4wzsMQ@mail.gmail.com>
Message-ID: <CALt0+o_=KZ5HjkTwcQwWA86+9E9aHLp427wt582rHji8a9ZX=g@mail.gmail.com>

On Fri, Sep 29, 2017 at 7:57 PM, Guillaume Smet
<guillaume.smet at gmail.com> wrote:
> Note that I still have some work to do on the mobile side. Will do once the
> dust has settled and we agree on the layout.

Mobile is OK now. The mobile experience should be better than with the
previous layout (most notably, the content of the post is hidden in
the blog post list).

-- 
Guillaume

From guillaume.smet at gmail.com  Sun Oct  1 12:43:43 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Sun, 1 Oct 2017 18:43:43 +0200
Subject: [hibernate-dev] New layout for in.relation.to
In-Reply-To: <CACYzyevodPSVOsJavOip3btHt_qZ9CV-OyEzKnCg1zbfg8rwzg@mail.gmail.com>
References: <CALt0+o_r-Mg2GeFCBgbSynWq8hyg4oBBn=2vB2T9njmr4wzsMQ@mail.gmail.com>
	<CALt0+o_=KZ5HjkTwcQwWA86+9E9aHLp427wt582rHji8a9ZX=g@mail.gmail.com>
	<CACYzyevodPSVOsJavOip3btHt_qZ9CV-OyEzKnCg1zbfg8rwzg@mail.gmail.com>
Message-ID: <CALt0+o9+omB3magt_X_KK=KGEKYpKH9T+CjyA8pNeXNJHGaW+w@mail.gmail.com>

On Sun, Oct 1, 2017 at 6:18 PM, Marko Bekhta <marko.prykladna at gmail.com>
wrote:

> otherwise they are displayed differently for each post. WDYT?
>
>
Good idea. As of now, they should be on a separate line on mobile.

From yoann at hibernate.org  Mon Oct  2 03:12:05 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Mon, 2 Oct 2017 09:12:05 +0200
Subject: [hibernate-dev] New layout for in.relation.to
In-Reply-To: <CALt0+o9+omB3magt_X_KK=KGEKYpKH9T+CjyA8pNeXNJHGaW+w@mail.gmail.com>
References: <CALt0+o_r-Mg2GeFCBgbSynWq8hyg4oBBn=2vB2T9njmr4wzsMQ@mail.gmail.com>
	<CALt0+o_=KZ5HjkTwcQwWA86+9E9aHLp427wt582rHji8a9ZX=g@mail.gmail.com>
	<CACYzyevodPSVOsJavOip3btHt_qZ9CV-OyEzKnCg1zbfg8rwzg@mail.gmail.com>
	<CALt0+o9+omB3magt_X_KK=KGEKYpKH9T+CjyA8pNeXNJHGaW+w@mail.gmail.com>
Message-ID: <CAEqagpqJYj4m_imED2eEVAYPK4+eK-+KXbX7vuB3a0MYsL5KEA@mail.gmail.com>

Looks great! Thanks for all the good work.

Two suggestions:

   - Add a button to display the menu on mobile
   - Do not display the author's picture on mobile, or display it on a
   separate row. I think it's currently responsible for the minimal screen
   width being relatively high, which will not look good on smaller devices.
   Note there's a "hidden-phone" class on the image, but it doesn't seem to
   work.


Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org

On 1 October 2017 at 18:43, Guillaume Smet <guillaume.smet at gmail.com> wrote:

> On Sun, Oct 1, 2017 at 6:18 PM, Marko Bekhta <marko.prykladna at gmail.com>
> wrote:
>
> > otherwise they are displayed differently for each post. WDYT?
> >
> >
> Good idea. As of now, they should be on a separate line on mobile.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.smet at gmail.com  Mon Oct  2 05:12:05 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 2 Oct 2017 11:12:05 +0200
Subject: [hibernate-dev] New layout for in.relation.to
In-Reply-To: <CAEqagpqJYj4m_imED2eEVAYPK4+eK-+KXbX7vuB3a0MYsL5KEA@mail.gmail.com>
References: <CALt0+o_r-Mg2GeFCBgbSynWq8hyg4oBBn=2vB2T9njmr4wzsMQ@mail.gmail.com>
	<CALt0+o_=KZ5HjkTwcQwWA86+9E9aHLp427wt582rHji8a9ZX=g@mail.gmail.com>
	<CACYzyevodPSVOsJavOip3btHt_qZ9CV-OyEzKnCg1zbfg8rwzg@mail.gmail.com>
	<CALt0+o9+omB3magt_X_KK=KGEKYpKH9T+CjyA8pNeXNJHGaW+w@mail.gmail.com>
	<CAEqagpqJYj4m_imED2eEVAYPK4+eK-+KXbX7vuB3a0MYsL5KEA@mail.gmail.com>
Message-ID: <CALt0+o8ni1DKR+i9JPiy3=H5oU+kgU5nxk0cEzaUfwoe-RLaRg@mail.gmail.com>

On Mon, Oct 2, 2017 at 9:12 AM, Yoann Rodiere <yoann at hibernate.org> wrote:
> Add a button to display the menu on mobile

I don't think it has much value on in.relation.to. That's why I don't show it.

> Do not display the author's picture on mobile, or display it on a separate row. I think it's currently responsible for the minimal screen width being relatively high, which will not look good on smaller devices. Note there's a "hidden-phone" class on the image, but it doesn't seem to work.

I wanted to show them (the class was a leftover I didn't notice as
these classes are not supported anymore) but you're right. I changed
the resolution of my mobile testing the other day and I didn't notice
it while testing in.relation.to. Better remove them.

Done and pushed.

-- 
Guillaume


From yoann at hibernate.org  Mon Oct  2 05:44:48 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Mon, 2 Oct 2017 11:44:48 +0200
Subject: [hibernate-dev] New layout for in.relation.to
In-Reply-To: <CALt0+o8ni1DKR+i9JPiy3=H5oU+kgU5nxk0cEzaUfwoe-RLaRg@mail.gmail.com>
References: <CALt0+o_r-Mg2GeFCBgbSynWq8hyg4oBBn=2vB2T9njmr4wzsMQ@mail.gmail.com>
	<CALt0+o_=KZ5HjkTwcQwWA86+9E9aHLp427wt582rHji8a9ZX=g@mail.gmail.com>
	<CACYzyevodPSVOsJavOip3btHt_qZ9CV-OyEzKnCg1zbfg8rwzg@mail.gmail.com>
	<CALt0+o9+omB3magt_X_KK=KGEKYpKH9T+CjyA8pNeXNJHGaW+w@mail.gmail.com>
	<CAEqagpqJYj4m_imED2eEVAYPK4+eK-+KXbX7vuB3a0MYsL5KEA@mail.gmail.com>
	<CALt0+o8ni1DKR+i9JPiy3=H5oU+kgU5nxk0cEzaUfwoe-RLaRg@mail.gmail.com>
Message-ID: <CAEqagpqCGGLihQcQun=PcV9wb8aaxLrPh_ix9Cvqm=j7GtO1Og@mail.gmail.com>

> I don't think it has much value on in.relation.to. That's why I don't
show it.

Well it's a bit confusing when coming from hibernate.org, since we made
sure to make everything look like it's the same website, and yet this
important part disappears... Granted, we could only have a stripped-down
version of the hibernate.org menu, so it would still be confusing, but
that's still better than nothing in my opinion.
On top of that, the menu button would only fill some currently unused space
on the top right, so there's really not much of a reason to remove it.

Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org

On 2 October 2017 at 11:12, Guillaume Smet <guillaume.smet at gmail.com> wrote:

> On Mon, Oct 2, 2017 at 9:12 AM, Yoann Rodiere <yoann at hibernate.org> wrote:
> > Add a button to display the menu on mobile
>
> I don't think it has much value on in.relation.to. That's why I don't
> show it.
>
> > Do not display the author's picture on mobile, or display it on a
> separate row. I think it's currently responsible for the minimal screen
> width being relatively high, which will not look good on smaller devices.
> Note there's a "hidden-phone" class on the image, but it doesn't seem to
> work.
>
> I wanted to show them (the class was a leftover I didn't notice as
> these classes are not supported anymore) but you're right. I changed
> the resolution of my mobile testing the other day and I didn't notice
> it while testing in.relation.to. Better remove them.
>
> Done and pushed.
>
> --
> Guillaume
>

From guillaume.smet at gmail.com  Mon Oct  2 06:55:51 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 2 Oct 2017 12:55:51 +0200
Subject: [hibernate-dev] New layout for in.relation.to
In-Reply-To: <CAEqagpqCGGLihQcQun=PcV9wb8aaxLrPh_ix9Cvqm=j7GtO1Og@mail.gmail.com>
References: <CALt0+o_r-Mg2GeFCBgbSynWq8hyg4oBBn=2vB2T9njmr4wzsMQ@mail.gmail.com>
	<CALt0+o_=KZ5HjkTwcQwWA86+9E9aHLp427wt582rHji8a9ZX=g@mail.gmail.com>
	<CACYzyevodPSVOsJavOip3btHt_qZ9CV-OyEzKnCg1zbfg8rwzg@mail.gmail.com>
	<CALt0+o9+omB3magt_X_KK=KGEKYpKH9T+CjyA8pNeXNJHGaW+w@mail.gmail.com>
	<CAEqagpqJYj4m_imED2eEVAYPK4+eK-+KXbX7vuB3a0MYsL5KEA@mail.gmail.com>
	<CALt0+o8ni1DKR+i9JPiy3=H5oU+kgU5nxk0cEzaUfwoe-RLaRg@mail.gmail.com>
	<CAEqagpqCGGLihQcQun=PcV9wb8aaxLrPh_ix9Cvqm=j7GtO1Og@mail.gmail.com>
Message-ID: <CALt0+o-TGS9er4jQMZG0xY=paAUqsOqqALSZkbNF47LwzZSBEg@mail.gmail.com>

On Mon, Oct 2, 2017 at 11:44 AM, Yoann Rodiere <yoann at hibernate.org> wrote:
> Well it's a bit confusing when coming from hibernate.org, since we made sure
> to make everything look like it's the same website, and yet this important
> part disappears... Granted, we could only have a stripped-down version of
> the hibernate.org menu, so it would still be confusing, but that's still
> better than nothing in my opinion.
> On top of that, the menu button would only fill some currently unused space
> on the top right, so there's really not much of a reason to remove it.

After discussing it with Yoann, I brought back a simplified version of
the menu on mobile (to avoid having to maintain the whole
hibernate.org tree on in.relation.to).

-- 
Guillaume

From guillaume.smet at gmail.com  Mon Oct  2 07:41:35 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 2 Oct 2017 13:41:35 +0200
Subject: [hibernate-dev] New layout for in.relation.to
In-Reply-To: <CALt0+o-TGS9er4jQMZG0xY=paAUqsOqqALSZkbNF47LwzZSBEg@mail.gmail.com>
References: <CALt0+o_r-Mg2GeFCBgbSynWq8hyg4oBBn=2vB2T9njmr4wzsMQ@mail.gmail.com>
	<CALt0+o_=KZ5HjkTwcQwWA86+9E9aHLp427wt582rHji8a9ZX=g@mail.gmail.com>
	<CACYzyevodPSVOsJavOip3btHt_qZ9CV-OyEzKnCg1zbfg8rwzg@mail.gmail.com>
	<CALt0+o9+omB3magt_X_KK=KGEKYpKH9T+CjyA8pNeXNJHGaW+w@mail.gmail.com>
	<CAEqagpqJYj4m_imED2eEVAYPK4+eK-+KXbX7vuB3a0MYsL5KEA@mail.gmail.com>
	<CALt0+o8ni1DKR+i9JPiy3=H5oU+kgU5nxk0cEzaUfwoe-RLaRg@mail.gmail.com>
	<CAEqagpqCGGLihQcQun=PcV9wb8aaxLrPh_ix9Cvqm=j7GtO1Og@mail.gmail.com>
	<CALt0+o-TGS9er4jQMZG0xY=paAUqsOqqALSZkbNF47LwzZSBEg@mail.gmail.com>
Message-ID: <CALt0+o9SHxTO8Gi4C2hw+Ef=Bkwj92uNaaW9R+KsVh_xyvQNaA@mail.gmail.com>

Thanks everyone for the useful feedback.

I pushed it to production just now.

If you have any other issue, just shout an email, I'll fix them as they come.

-- 
Guillaume

On Mon, Oct 2, 2017 at 12:55 PM, Guillaume Smet
<guillaume.smet at gmail.com> wrote:
> On Mon, Oct 2, 2017 at 11:44 AM, Yoann Rodiere <yoann at hibernate.org> wrote:
>> Well it's a bit confusing when coming from hibernate.org, since we made sure
>> to make everything look like it's the same website, and yet this important
>> part disappears... Granted, we could only have a stripped-down version of
>> the hibernate.org menu, so it would still be confusing, but that's still
>> better than nothing in my opinion.
>> On top of that, the menu button would only fill some currently unused space
>> on the top right, so there's really not much of a reason to remove it.
>
> After discussing it with Yoann, I brought back a simplified version of
> the menu on mobile (to avoid having to maintain the whole
> hibernate.org tree on in.relation.to).
>
> --
> Guillaume

From sanne at hibernate.org  Mon Oct  2 10:42:07 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 2 Oct 2017 15:42:07 +0100
Subject: [hibernate-dev] New layout for in.relation.to
In-Reply-To: <CALt0+o9SHxTO8Gi4C2hw+Ef=Bkwj92uNaaW9R+KsVh_xyvQNaA@mail.gmail.com>
References: <CALt0+o_r-Mg2GeFCBgbSynWq8hyg4oBBn=2vB2T9njmr4wzsMQ@mail.gmail.com>
	<CALt0+o_=KZ5HjkTwcQwWA86+9E9aHLp427wt582rHji8a9ZX=g@mail.gmail.com>
	<CACYzyevodPSVOsJavOip3btHt_qZ9CV-OyEzKnCg1zbfg8rwzg@mail.gmail.com>
	<CALt0+o9+omB3magt_X_KK=KGEKYpKH9T+CjyA8pNeXNJHGaW+w@mail.gmail.com>
	<CAEqagpqJYj4m_imED2eEVAYPK4+eK-+KXbX7vuB3a0MYsL5KEA@mail.gmail.com>
	<CALt0+o8ni1DKR+i9JPiy3=H5oU+kgU5nxk0cEzaUfwoe-RLaRg@mail.gmail.com>
	<CAEqagpqCGGLihQcQun=PcV9wb8aaxLrPh_ix9Cvqm=j7GtO1Og@mail.gmail.com>
	<CALt0+o-TGS9er4jQMZG0xY=paAUqsOqqALSZkbNF47LwzZSBEg@mail.gmail.com>
	<CALt0+o9SHxTO8Gi4C2hw+Ef=Bkwj92uNaaW9R+KsVh_xyvQNaA@mail.gmail.com>
Message-ID: <CAFm4XO1nSsCKbEK6GEM1+YNULG2wL7Kawotx24eiTviPuiFhMQ@mail.gmail.com>

Thanks Guillaume!

As for feedback, in case your TODO list gets out of hand over emails
you can also just WEBSITE project on JIRA:
 - https://hibernate.atlassian.net/projects/WEBSITE

On 2 October 2017 at 12:41, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Thanks everyone for the useful feedback.
>
> I pushed it to production just now.
>
> If you have any other issue, just shout an email, I'll fix them as they come.
>
> --
> Guillaume
>
> On Mon, Oct 2, 2017 at 12:55 PM, Guillaume Smet
> <guillaume.smet at gmail.com> wrote:
>> On Mon, Oct 2, 2017 at 11:44 AM, Yoann Rodiere <yoann at hibernate.org> wrote:
>>> Well it's a bit confusing when coming from hibernate.org, since we made sure
>>> to make everything look like it's the same website, and yet this important
>>> part disappears... Granted, we could only have a stripped-down version of
>>> the hibernate.org menu, so it would still be confusing, but that's still
>>> better than nothing in my opinion.
>>> On top of that, the menu button would only fill some currently unused space
>>> on the top right, so there's really not much of a reason to remove it.
>>
>> After discussing it with Yoann, I brought back a simplified version of
>> the menu on mobile (to avoid having to maintain the whole
>> hibernate.org tree on in.relation.to).
>>
>> --
>> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Mon Oct  2 11:49:55 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 2 Oct 2017 17:49:55 +0200
Subject: [hibernate-dev] New layout for in.relation.to
In-Reply-To: <CAFm4XO1nSsCKbEK6GEM1+YNULG2wL7Kawotx24eiTviPuiFhMQ@mail.gmail.com>
References: <CALt0+o_r-Mg2GeFCBgbSynWq8hyg4oBBn=2vB2T9njmr4wzsMQ@mail.gmail.com>
	<CALt0+o_=KZ5HjkTwcQwWA86+9E9aHLp427wt582rHji8a9ZX=g@mail.gmail.com>
	<CACYzyevodPSVOsJavOip3btHt_qZ9CV-OyEzKnCg1zbfg8rwzg@mail.gmail.com>
	<CALt0+o9+omB3magt_X_KK=KGEKYpKH9T+CjyA8pNeXNJHGaW+w@mail.gmail.com>
	<CAEqagpqJYj4m_imED2eEVAYPK4+eK-+KXbX7vuB3a0MYsL5KEA@mail.gmail.com>
	<CALt0+o8ni1DKR+i9JPiy3=H5oU+kgU5nxk0cEzaUfwoe-RLaRg@mail.gmail.com>
	<CAEqagpqCGGLihQcQun=PcV9wb8aaxLrPh_ix9Cvqm=j7GtO1Og@mail.gmail.com>
	<CALt0+o-TGS9er4jQMZG0xY=paAUqsOqqALSZkbNF47LwzZSBEg@mail.gmail.com>
	<CALt0+o9SHxTO8Gi4C2hw+Ef=Bkwj92uNaaW9R+KsVh_xyvQNaA@mail.gmail.com>
	<CAFm4XO1nSsCKbEK6GEM1+YNULG2wL7Kawotx24eiTviPuiFhMQ@mail.gmail.com>
Message-ID: <CALt0+o9TKyYAHFB+uoxqjognAY4nr1-+96qzGwGYDRvbnTQJHQ@mail.gmail.com>

Yup. For now, it has been easier to fix things on the fly.

But thanks for the suggestion.

On Mon, Oct 2, 2017 at 4:42 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> Thanks Guillaume!
>
> As for feedback, in case your TODO list gets out of hand over emails
> you can also just WEBSITE project on JIRA:
>  - https://hibernate.atlassian.net/projects/WEBSITE
>
> On 2 October 2017 at 12:41, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>> Thanks everyone for the useful feedback.
>>
>> I pushed it to production just now.
>>
>> If you have any other issue, just shout an email, I'll fix them as they come.
>>
>> --
>> Guillaume
>>
>> On Mon, Oct 2, 2017 at 12:55 PM, Guillaume Smet
>> <guillaume.smet at gmail.com> wrote:
>>> On Mon, Oct 2, 2017 at 11:44 AM, Yoann Rodiere <yoann at hibernate.org> wrote:
>>>> Well it's a bit confusing when coming from hibernate.org, since we made sure
>>>> to make everything look like it's the same website, and yet this important
>>>> part disappears... Granted, we could only have a stripped-down version of
>>>> the hibernate.org menu, so it would still be confusing, but that's still
>>>> better than nothing in my opinion.
>>>> On top of that, the menu button would only fill some currently unused space
>>>> on the top right, so there's really not much of a reason to remove it.
>>>
>>> After discussing it with Yoann, I brought back a simplified version of
>>> the menu on mobile (to avoid having to maintain the whole
>>> hibernate.org tree on in.relation.to).
>>>
>>> --
>>> Guillaume
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From yoann at hibernate.org  Wed Oct  4 03:31:06 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Wed, 4 Oct 2017 09:31:06 +0200
Subject: [hibernate-dev] Hibernate Search 5.8.0.Final released
Message-ID: <CAEqagprrvV16uCcFoej8CcKyymOcn2787no5oWY-PdYxfRfTKg@mail.gmail.com>

Hello everyone,

We just released Hibernate Search 5.8.1.Final, with several
Elasticsearch-related fixes.

Check out our blog for more information about this release:

http://in.relation.to/2017/10/04/hibernate-search-5-8-1-Final/

Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org

From yoann at hibernate.org  Wed Oct  4 03:50:29 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Wed, 4 Oct 2017 09:50:29 +0200
Subject: [hibernate-dev] Hibernate Search 5.8.0.Final released
In-Reply-To: <CAEqagprrvV16uCcFoej8CcKyymOcn2787no5oWY-PdYxfRfTKg@mail.gmail.com>
References: <CAEqagprrvV16uCcFoej8CcKyymOcn2787no5oWY-PdYxfRfTKg@mail.gmail.com>
Message-ID: <CAEqagprcVTcd+E6gqYtHoB1_Qx5vWGaCqNTj6Sib6O-u6jtH7Q@mail.gmail.com>

As you may have understood, the subject of the previous email was wrong.
The version we just released is indeed 5.8.1.Final and not 5.8.0.Final.

Apologies for the confusion.

Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org

On 4 October 2017 at 09:31, Yoann Rodiere <yoann at hibernate.org> wrote:

> Hello everyone,
>
> We just released Hibernate Search 5.8.1.Final, with several
> Elasticsearch-related fixes.
>
> Check out our blog for more information about this release:
>
> http://in.relation.to/2017/10/04/hibernate-search-5-8-1-Final/
>
> Yoann Rodi?re
> Hibernate NoORM Team
> yoann at hibernate.org
>

From hardy at hibernate.org  Wed Oct  4 07:22:25 2017
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 4 Oct 2017 13:22:25 +0200
Subject: [hibernate-dev] New layout for in.relation.to
In-Reply-To: <CALt0+o9TKyYAHFB+uoxqjognAY4nr1-+96qzGwGYDRvbnTQJHQ@mail.gmail.com>
References: <CALt0+o_=KZ5HjkTwcQwWA86+9E9aHLp427wt582rHji8a9ZX=g@mail.gmail.com>
	<CACYzyevodPSVOsJavOip3btHt_qZ9CV-OyEzKnCg1zbfg8rwzg@mail.gmail.com>
	<CALt0+o9+omB3magt_X_KK=KGEKYpKH9T+CjyA8pNeXNJHGaW+w@mail.gmail.com>
	<CAEqagpqJYj4m_imED2eEVAYPK4+eK-+KXbX7vuB3a0MYsL5KEA@mail.gmail.com>
	<CALt0+o8ni1DKR+i9JPiy3=H5oU+kgU5nxk0cEzaUfwoe-RLaRg@mail.gmail.com>
	<CAEqagpqCGGLihQcQun=PcV9wb8aaxLrPh_ix9Cvqm=j7GtO1Og@mail.gmail.com>
	<CALt0+o-TGS9er4jQMZG0xY=paAUqsOqqALSZkbNF47LwzZSBEg@mail.gmail.com>
	<CALt0+o9SHxTO8Gi4C2hw+Ef=Bkwj92uNaaW9R+KsVh_xyvQNaA@mail.gmail.com>
	<CAFm4XO1nSsCKbEK6GEM1+YNULG2wL7Kawotx24eiTviPuiFhMQ@mail.gmail.com>
	<CALt0+o9TKyYAHFB+uoxqjognAY4nr1-+96qzGwGYDRvbnTQJHQ@mail.gmail.com>
Message-ID: <20171004112225.GA96634@nineveh.lan>

Hi,

I like the new layout and navigation. Well done. One thing I am wondering though
is the rectangular "box" around the two lines in the header? Is this intended?
I find it quite harsh. I first thought it is a browser issue, but it seems
to render the same way with any browser or device. 

--Hardy


From yoann at hibernate.org  Wed Oct  4 07:43:55 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Wed, 4 Oct 2017 13:43:55 +0200
Subject: [hibernate-dev] New layout for in.relation.to
In-Reply-To: <20171004112225.GA96634@nineveh.lan>
References: <CALt0+o_=KZ5HjkTwcQwWA86+9E9aHLp427wt582rHji8a9ZX=g@mail.gmail.com>
	<CACYzyevodPSVOsJavOip3btHt_qZ9CV-OyEzKnCg1zbfg8rwzg@mail.gmail.com>
	<CALt0+o9+omB3magt_X_KK=KGEKYpKH9T+CjyA8pNeXNJHGaW+w@mail.gmail.com>
	<CAEqagpqJYj4m_imED2eEVAYPK4+eK-+KXbX7vuB3a0MYsL5KEA@mail.gmail.com>
	<CALt0+o8ni1DKR+i9JPiy3=H5oU+kgU5nxk0cEzaUfwoe-RLaRg@mail.gmail.com>
	<CAEqagpqCGGLihQcQun=PcV9wb8aaxLrPh_ix9Cvqm=j7GtO1Og@mail.gmail.com>
	<CALt0+o-TGS9er4jQMZG0xY=paAUqsOqqALSZkbNF47LwzZSBEg@mail.gmail.com>
	<CALt0+o9SHxTO8Gi4C2hw+Ef=Bkwj92uNaaW9R+KsVh_xyvQNaA@mail.gmail.com>
	<CAFm4XO1nSsCKbEK6GEM1+YNULG2wL7Kawotx24eiTviPuiFhMQ@mail.gmail.com>
	<CALt0+o9TKyYAHFB+uoxqjognAY4nr1-+96qzGwGYDRvbnTQJHQ@mail.gmail.com>
	<20171004112225.GA96634@nineveh.lan>
Message-ID: <CAEqagpraYuXGUxFehqFXYqMvd0pmdpJu+KcQuUMJxbGstXeU3Q@mail.gmail.com>

Hush, it's a sensitive topic :) Let's just say it's on purpose, and it
could have been... harsher. The current style is already a compromise.


Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org

On 4 October 2017 at 13:22, Hardy Ferentschik <hardy at hibernate.org> wrote:

> Hi,
>
> I like the new layout and navigation. Well done. One thing I am wondering
> though
> is the rectangular "box" around the two lines in the header? Is this
> intended?
> I find it quite harsh. I first thought it is a browser issue, but it seems
> to render the same way with any browser or device.
>
> --Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Thu Oct  5 09:24:07 2017
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 5 Oct 2017 15:24:07 +0200
Subject: [hibernate-dev] New layout for in.relation.to
In-Reply-To: <CAEqagpraYuXGUxFehqFXYqMvd0pmdpJu+KcQuUMJxbGstXeU3Q@mail.gmail.com>
References: <CALt0+o9+omB3magt_X_KK=KGEKYpKH9T+CjyA8pNeXNJHGaW+w@mail.gmail.com>
	<CAEqagpqJYj4m_imED2eEVAYPK4+eK-+KXbX7vuB3a0MYsL5KEA@mail.gmail.com>
	<CALt0+o8ni1DKR+i9JPiy3=H5oU+kgU5nxk0cEzaUfwoe-RLaRg@mail.gmail.com>
	<CAEqagpqCGGLihQcQun=PcV9wb8aaxLrPh_ix9Cvqm=j7GtO1Og@mail.gmail.com>
	<CALt0+o-TGS9er4jQMZG0xY=paAUqsOqqALSZkbNF47LwzZSBEg@mail.gmail.com>
	<CALt0+o9SHxTO8Gi4C2hw+Ef=Bkwj92uNaaW9R+KsVh_xyvQNaA@mail.gmail.com>
	<CAFm4XO1nSsCKbEK6GEM1+YNULG2wL7Kawotx24eiTviPuiFhMQ@mail.gmail.com>
	<CALt0+o9TKyYAHFB+uoxqjognAY4nr1-+96qzGwGYDRvbnTQJHQ@mail.gmail.com>
	<20171004112225.GA96634@nineveh.lan>
	<CAEqagpraYuXGUxFehqFXYqMvd0pmdpJu+KcQuUMJxbGstXeU3Q@mail.gmail.com>
Message-ID: <20171005132407.GA45867@ovpn-116-61.ams2.redhat.com>

On Wed, 04-Oct-2017 13:43, Yoann Rodiere wrote:
> Hush, it's a sensitive topic :) Let's just say it's on purpose, and it
> could have been... harsher. The current style is already a compromise.

Interesting. I got more interested now, but maybe better to leave it at this. ;-)

--Hardy


From guillaume.smet at gmail.com  Tue Oct 10 06:36:24 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 10 Oct 2017 12:36:24 +0200
Subject: [hibernate-dev] Property "ogm.datastore.create_database": fit
	for purpose?
In-Reply-To: <CAFm4XO0VUFwN_yCLrw_VuUs8LO-9iJZdUy1rt-5Y3urgXOBz+A@mail.gmail.com>
References: <CAFm4XO1TRT=ARFn89gXoqFix-uVPYWZFxGwcZsLrVGUe4a7CkQ@mail.gmail.com>
	<CALt0+o_ZW0cW43kZEP8zXbvtyhK0rR0eZ0L5iC_qTdHjYxoTmg@mail.gmail.com>
	<CANoTJYMyBW15=SbXu0_Omr+1ADmovQPG53RA1mjA+LL6As+C=w@mail.gmail.com>
	<CAFm4XO3GAr6M-Ea9HgskeA=8c2dv6PrEg18fr+-bwmexNH-U-g@mail.gmail.com>
	<CANoTJYNQQu_t4XncXG8O_g0KEVGGF3-WC6EutunGe8=OQJc1YQ@mail.gmail.com>
	<CAFm4XO2g=02YaKJXJRft1F5KCeHSr_Wmd_5t8u3t8CBw6dtvbg@mail.gmail.com>
	<CADGJaX-E5X9shvrUGZdHnX16fsT5NMfFaAA_MDedtdVMmWv2yg@mail.gmail.com>
	<CAFm4XO15=GeapnuzC5C=1=CB-9rJdG3Q7haE+bmzHL2L+9JBtw@mail.gmail.com>
	<CADGJaX-jUTY36mnugquzB9ODaSsr+Q9_FP9GNRYOKr97akPsfg@mail.gmail.com>
	<CAFm4XO0VUFwN_yCLrw_VuUs8LO-9iJZdUy1rt-5Y3urgXOBz+A@mail.gmail.com>
Message-ID: <CALt0+o_ErW3nJbCxeriSmjUAk_s6wQvtK20Cn3FwP-d6Zv8H=Q@mail.gmail.com>

On Wed, Sep 27, 2017 at 2:55 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> But essentially looks we're on the same page about using HBM2DDL_AUTO
> and ignoring "create_database" for the sake of practical usage.

Just to be sure, in the end, did we do it?

-- 
Guillaume

From davide at hibernate.org  Tue Oct 10 06:45:59 2017
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 10 Oct 2017 11:45:59 +0100
Subject: [hibernate-dev] Property "ogm.datastore.create_database": fit
	for purpose?
In-Reply-To: <CALt0+o_ErW3nJbCxeriSmjUAk_s6wQvtK20Cn3FwP-d6Zv8H=Q@mail.gmail.com>
References: <CAFm4XO1TRT=ARFn89gXoqFix-uVPYWZFxGwcZsLrVGUe4a7CkQ@mail.gmail.com>
	<CALt0+o_ZW0cW43kZEP8zXbvtyhK0rR0eZ0L5iC_qTdHjYxoTmg@mail.gmail.com>
	<CANoTJYMyBW15=SbXu0_Omr+1ADmovQPG53RA1mjA+LL6As+C=w@mail.gmail.com>
	<CAFm4XO3GAr6M-Ea9HgskeA=8c2dv6PrEg18fr+-bwmexNH-U-g@mail.gmail.com>
	<CANoTJYNQQu_t4XncXG8O_g0KEVGGF3-WC6EutunGe8=OQJc1YQ@mail.gmail.com>
	<CAFm4XO2g=02YaKJXJRft1F5KCeHSr_Wmd_5t8u3t8CBw6dtvbg@mail.gmail.com>
	<CADGJaX-E5X9shvrUGZdHnX16fsT5NMfFaAA_MDedtdVMmWv2yg@mail.gmail.com>
	<CAFm4XO15=GeapnuzC5C=1=CB-9rJdG3Q7haE+bmzHL2L+9JBtw@mail.gmail.com>
	<CADGJaX-jUTY36mnugquzB9ODaSsr+Q9_FP9GNRYOKr97akPsfg@mail.gmail.com>
	<CAFm4XO0VUFwN_yCLrw_VuUs8LO-9iJZdUy1rt-5Y3urgXOBz+A@mail.gmail.com>
	<CALt0+o_ErW3nJbCxeriSmjUAk_s6wQvtK20Cn3FwP-d6Zv8H=Q@mail.gmail.com>
Message-ID: <CANoTJYP5VmD_5RysoVhf76ra6sX+tGqN+ApgCio7pniusoSSJg@mail.gmail.com>

I'm working on it.



On Tue, Oct 10, 2017 at 11:36 AM, Guillaume Smet
<guillaume.smet at gmail.com> wrote:
> On Wed, Sep 27, 2017 at 2:55 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> But essentially looks we're on the same page about using HBM2DDL_AUTO
>> and ignoring "create_database" for the sake of practical usage.
>
> Just to be sure, in the end, did we do it?
>
> --
> Guillaume

From guillaume.smet at gmail.com  Tue Oct 10 07:08:46 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 10 Oct 2017 13:08:46 +0200
Subject: [hibernate-dev] Property "ogm.datastore.create_database": fit
	for purpose?
In-Reply-To: <CANoTJYP5VmD_5RysoVhf76ra6sX+tGqN+ApgCio7pniusoSSJg@mail.gmail.com>
References: <CAFm4XO1TRT=ARFn89gXoqFix-uVPYWZFxGwcZsLrVGUe4a7CkQ@mail.gmail.com>
	<CALt0+o_ZW0cW43kZEP8zXbvtyhK0rR0eZ0L5iC_qTdHjYxoTmg@mail.gmail.com>
	<CANoTJYMyBW15=SbXu0_Omr+1ADmovQPG53RA1mjA+LL6As+C=w@mail.gmail.com>
	<CAFm4XO3GAr6M-Ea9HgskeA=8c2dv6PrEg18fr+-bwmexNH-U-g@mail.gmail.com>
	<CANoTJYNQQu_t4XncXG8O_g0KEVGGF3-WC6EutunGe8=OQJc1YQ@mail.gmail.com>
	<CAFm4XO2g=02YaKJXJRft1F5KCeHSr_Wmd_5t8u3t8CBw6dtvbg@mail.gmail.com>
	<CADGJaX-E5X9shvrUGZdHnX16fsT5NMfFaAA_MDedtdVMmWv2yg@mail.gmail.com>
	<CAFm4XO15=GeapnuzC5C=1=CB-9rJdG3Q7haE+bmzHL2L+9JBtw@mail.gmail.com>
	<CADGJaX-jUTY36mnugquzB9ODaSsr+Q9_FP9GNRYOKr97akPsfg@mail.gmail.com>
	<CAFm4XO0VUFwN_yCLrw_VuUs8LO-9iJZdUy1rt-5Y3urgXOBz+A@mail.gmail.com>
	<CALt0+o_ErW3nJbCxeriSmjUAk_s6wQvtK20Cn3FwP-d6Zv8H=Q@mail.gmail.com>
	<CANoTJYP5VmD_5RysoVhf76ra6sX+tGqN+ApgCio7pniusoSSJg@mail.gmail.com>
Message-ID: <CALt0+o9KDcdRX1m61q=vsge9oz1WQaLqWdMm8HUfsbR0M-jiRg@mail.gmail.com>

OK cool, just wanted to be sure we didn't forget about it!

On Tue, Oct 10, 2017 at 12:45 PM, Davide D'Alto <davide at hibernate.org> wrote:
> I'm working on it.
>
>
>
> On Tue, Oct 10, 2017 at 11:36 AM, Guillaume Smet
> <guillaume.smet at gmail.com> wrote:
>> On Wed, Sep 27, 2017 at 2:55 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> But essentially looks we're on the same page about using HBM2DDL_AUTO
>>> and ignoring "create_database" for the sake of practical usage.
>>
>> Just to be sure, in the end, did we do it?
>>
>> --
>> Guillaume

From robert at marcanoonline.com  Wed Oct 11 13:43:39 2017
From: robert at marcanoonline.com (Robert Marcano)
Date: Wed, 11 Oct 2017 13:43:39 -0400
Subject: [hibernate-dev] Statements leaks when using JPA
	StoredProcedureQuery API
Message-ID: <575ba814-1873-2be5-f8ad-a00296e94efa@marcanoonline.com>

Migrating code from the Hibernate API to JPA, I found a stored procedure 
being called on a loop that was generating DB2 errors [1] on tests. This 
error is caused in this case for having a lot of not closed statements.

The problem didn't happen using ProcedureCall Hibernate API because the 
method getOutputs() and release() from the Outputs instance are available.

StoredProcedureQuery JPA API doesn't have any way to "close" the query 
and by that, the statement. Reusing the same instance of 
StoredProcedureQuery trying to only leak an unclosed statement but that 
doesn't help either, ProcedureCallImpl is creating a new statement for 
every call [2].

The only option is to unwrap the StoredProcedureQuery to an 
StoredProcedureQuery and release the Outputs instance.

I don't think there is a way to avoid this without enhancing the JPA 
API. Client code can call an store procedure and in some cases not 
caring about all the results, so there is no way for a JPA 
implementation to know when to close the statement.

Making StoredProcedureQuery an AutoCloseable may help, but it will 
contrast with other Query types that don't need to be closed.

Note: It is not frequent to call many store procedures on a loop, I 
would have preferred to just create a new procedure with the loop, but 
for this application the conditions about when to call the procedure for 
each iteration are outside the database.

[1] http://www-01.ibm.com/support/docview.wss?uid=swg21504334
[2] 
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/procedure/internal/ProcedureCallImpl.java#L437



From steve at hibernate.org  Thu Oct 12 08:22:11 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 12 Oct 2017 12:22:11 +0000
Subject: [hibernate-dev] @db.dialect@ - yet again
Message-ID: <CAFdSV9sxZrTFDU-3ioG9a95txdz8kkXr7sMQdfvBSvXFH3WyXQ@mail.gmail.com>

I just upgraded to IntelliJ 2017.3 EAP and am back to this frustrating
"Dialect class not found: @db.dialect@" problem.  I run the
`processTestResources` (or `compile`, does not matter) and then when I try
to run a test in the IDE I get this error.

What is the magic incantation I am missing?

From galovicsarnold at gmail.com  Thu Oct 12 09:15:28 2017
From: galovicsarnold at gmail.com (=?UTF-8?Q?Arnold_G=C3=A1lovics?=)
Date: Thu, 12 Oct 2017 15:15:28 +0200
Subject: [hibernate-dev] @db.dialect@ - yet again
In-Reply-To: <CAFdSV9sxZrTFDU-3ioG9a95txdz8kkXr7sMQdfvBSvXFH3WyXQ@mail.gmail.com>
References: <CAFdSV9sxZrTFDU-3ioG9a95txdz8kkXr7sMQdfvBSvXFH3WyXQ@mail.gmail.com>
Message-ID: <CAH_GnZ5UXqxuYpq_AjcLDaj0FH91d_SxnV=KO-YMRz7ajFUkOQ@mail.gmail.com>

Hi Steve,

Had the same issue. https://youtrack.jetbrains.com/issue/IDEA-175172

I solved it by running the processTestResources task and copying the
properties file from the build folder to the out folder.

Hope it helps!

Best,
Arnold

On Thu, Oct 12, 2017 at 2:22 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I just upgraded to IntelliJ 2017.3 EAP and am back to this frustrating
> "Dialect class not found: @db.dialect@" problem.  I run the
> `processTestResources` (or `compile`, does not matter) and then when I try
> to run a test in the IDE I get this error.
>
> What is the magic incantation I am missing?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From dreborier at gmail.com  Thu Oct 12 09:20:19 2017
From: dreborier at gmail.com (andrea boriero)
Date: Thu, 12 Oct 2017 14:20:19 +0100
Subject: [hibernate-dev] @db.dialect@ - yet again
In-Reply-To: <CAFdSV9sxZrTFDU-3ioG9a95txdz8kkXr7sMQdfvBSvXFH3WyXQ@mail.gmail.com>
References: <CAFdSV9sxZrTFDU-3ioG9a95txdz8kkXr7sMQdfvBSvXFH3WyXQ@mail.gmail.com>
Message-ID: <CAL00eSRZMWYWH0E8ADh_5bGHO-KoNj5Ep-poHn61g7B5sEz4cw@mail.gmail.com>

With the new version of IntelliJ the only way I found to run tests from
inside the IDE is to override the hibernate.properties file in the
out/test/resources folder with the one in target/resources/test generated
by gradle

On 12 October 2017 at 13:22, Steve Ebersole <steve at hibernate.org> wrote:

> I just upgraded to IntelliJ 2017.3 EAP and am back to this frustrating
> "Dialect class not found: @db.dialect@" problem.  I run the
> `processTestResources` (or `compile`, does not matter) and then when I try
> to run a test in the IDE I get this error.
>
> What is the magic incantation I am missing?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Thu Oct 12 09:22:35 2017
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 12 Oct 2017 16:22:35 +0300
Subject: [hibernate-dev] @db.dialect@ - yet again
In-Reply-To: <CAFdSV9sxZrTFDU-3ioG9a95txdz8kkXr7sMQdfvBSvXFH3WyXQ@mail.gmail.com>
References: <CAFdSV9sxZrTFDU-3ioG9a95txdz8kkXr7sMQdfvBSvXFH3WyXQ@mail.gmail.com>
Message-ID: <CA+gWKMBZDCU8r50hz6HhFEJ_22XXfWk=fkAOrqYrPSHTNCXGfw@mail.gmail.com>

Hi,

Looks like IDEA rebuilds the project and generates the @db.dialect@ issue.

I tackled it with the following Bash script:

@echo off
> set db=%1
> set module="hibernate-core"
> if not "%2"=="" SET module="hibernate-%2"
> if "%2"=="doc" SET module="documentation"
> set target="d:\Vlad\Work\GitHub\hibernate-orm\%module%\target\"
> IF EXIST %target%\resources\test (
>     del %target%\resources\test\hibernate.properties
> )
> pushd %target%
> cd ..
> gradlew pTR -Pdb=%db%
> popd


It's Windows, but it can be easily translated to Linux bash.

I call it as follows:

> ptr h2

This one prepared hibernate-core for H2

> ptr mysql

This one prepared hibernate-core for MySQL

>  ptr h2 envers

This one prepared hibernate-envers for H2

I usually run it from Idea Terminal.

Vlad

On Thu, Oct 12, 2017 at 3:22 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I just upgraded to IntelliJ 2017.3 EAP and am back to this frustrating
> "Dialect class not found: @db.dialect@" problem.  I run the
> `processTestResources` (or `compile`, does not matter) and then when I try
> to run a test in the IDE I get this error.
>
> What is the magic incantation I am missing?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From andrea at hibernate.org  Thu Oct 12 16:21:08 2017
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 12 Oct 2017 21:21:08 +0100
Subject: [hibernate-dev] @db.dialect@ - yet again
In-Reply-To: <CA+gWKMBZDCU8r50hz6HhFEJ_22XXfWk=fkAOrqYrPSHTNCXGfw@mail.gmail.com>
References: <CAFdSV9sxZrTFDU-3ioG9a95txdz8kkXr7sMQdfvBSvXFH3WyXQ@mail.gmail.com>
	<CA+gWKMBZDCU8r50hz6HhFEJ_22XXfWk=fkAOrqYrPSHTNCXGfw@mail.gmail.com>
Message-ID: <CAL00eSQSZoyu4ETcGsZJEqGAoN1nLvVt9NgOWj9nmS_+VPF8yQ@mail.gmail.com>

One hack I have found is to add, inside the subprojects block of
the build.gradle file, the following task

task copyResourcesToIntelliJOutFolder(type: Copy)  {
      from "$subProject.buildDir/resources/test"
      into 'out/test/resources'
}

Then in the IntelliJ gradle tool window locate the task
copyResourceToIntelliJOutFolder (it should be under hibernate-orm > Tasks
-> other), right click on it and select the "Execute After build" option.


On 12 October 2017 at 14:22, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> Hi,
>
> Looks like IDEA rebuilds the project and generates the @db.dialect@ issue.
>
> I tackled it with the following Bash script:
>
> @echo off
> > set db=%1
> > set module="hibernate-core"
> > if not "%2"=="" SET module="hibernate-%2"
> > if "%2"=="doc" SET module="documentation"
> > set target="d:\Vlad\Work\GitHub\hibernate-orm\%module%\target\"
> > IF EXIST %target%\resources\test (
> >     del %target%\resources\test\hibernate.properties
> > )
> > pushd %target%
> > cd ..
> > gradlew pTR -Pdb=%db%
> > popd
>
>
> It's Windows, but it can be easily translated to Linux bash.
>
> I call it as follows:
>
> > ptr h2
>
> This one prepared hibernate-core for H2
>
> > ptr mysql
>
> This one prepared hibernate-core for MySQL
>
> >  ptr h2 envers
>
> This one prepared hibernate-envers for H2
>
> I usually run it from Idea Terminal.
>
> Vlad
>
> On Thu, Oct 12, 2017 at 3:22 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > I just upgraded to IntelliJ 2017.3 EAP and am back to this frustrating
> > "Dialect class not found: @db.dialect@" problem.  I run the
> > `processTestResources` (or `compile`, does not matter) and then when I
> try
> > to run a test in the IDE I get this error.
> >
> > What is the magic incantation I am missing?
> > _______________________________________________
> > 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 Oct 13 08:31:08 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Oct 2017 12:31:08 +0000
Subject: [hibernate-dev] <join ... fetch="select"/>
Message-ID: <CAFdSV9tJmSt_PCYuuRCjY2BuimV=0c33tYuKg6EcmzoBDaCUNw@mail.gmail.com>

Hibernate mappings define a feature to allow a secondary table (`<join/>`
in hbm terms) to be defined as not joined via : `<join ...
fetch="select"/>`.  This actually creates a subsequent select to load the
data from the secondary table.

I am trying to figure out how to best incorporate this into the paradigm
for JDBC statement execution in 6.0.  My first thought was "do we need to
keep this?".  Does anyone know of a real usage of this feature?  In theory
it could be useful to some degree along with bytecode enhanced interception
for lazy-loading individual attributes.  But even then, I'm not sure how
practically useful that is.

From steve at hibernate.org  Fri Oct 13 15:11:41 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Oct 2017 19:11:41 +0000
Subject: [hibernate-dev] Statements leaks when using JPA
 StoredProcedureQuery API
In-Reply-To: <575ba814-1873-2be5-f8ad-a00296e94efa@marcanoonline.com>
References: <575ba814-1873-2be5-f8ad-a00296e94efa@marcanoonline.com>
Message-ID: <CAFdSV9s0USQ-eoFxGq1WrUVA2xMeOPeZ3PVh9gTTeCDPUddAvA@mail.gmail.com>

The conceptualization of a Query for both Hibernate and JPA is that you
execute it and get back the result of that execution: a List, a single
result, a ScrollableResult, a Stream, etc.

Yet then JPA throws in StoredProcedureQuery which is completely different
conceptually.  Here you execute and then (statefully!!!) access the
individual pieces of that execution's results.

Sadly the JPA StoredProcedureQuery API is just messed up.  In my opinion
(yes, of course I'm biased) our ProcedureCall + ProcedureOutputs model is
MUCH better. It is more in line with that conceptualization of Query ->
Result as opposed to StoredProcedureQuery's Query -> Query-as-Result.

All that said...

What you are asking for here is to implicitly close the JDBC
CallableStatement when we recognize <some condition> that signifies
the exhaustion
of the execution results.  What is that condition?  Can't be just when
there are no more ResultSets in the CallableStatement's pipeline.  Consider
calling StoredProcedureQuery#getOutputParameterValue (which would require
accessing the CallableStatement) *after* we have implicitly closed the
CallableStatement.

So what is that condition?  That's the rub...


On Wed, Oct 11, 2017 at 1:07 PM Robert Marcano <robert at marcanoonline.com>
wrote:

> Migrating code from the Hibernate API to JPA, I found a stored procedure
> being called on a loop that was generating DB2 errors [1] on tests. This
> error is caused in this case for having a lot of not closed statements.
>
> The problem didn't happen using ProcedureCall Hibernate API because the
> method getOutputs() and release() from the Outputs instance are available.
>
> StoredProcedureQuery JPA API doesn't have any way to "close" the query
> and by that, the statement. Reusing the same instance of
> StoredProcedureQuery trying to only leak an unclosed statement but that
> doesn't help either, ProcedureCallImpl is creating a new statement for
> every call [2].
>
> The only option is to unwrap the StoredProcedureQuery to an
> StoredProcedureQuery and release the Outputs instance.
>
> I don't think there is a way to avoid this without enhancing the JPA
> API. Client code can call an store procedure and in some cases not
> caring about all the results, so there is no way for a JPA
> implementation to know when to close the statement.
>
> Making StoredProcedureQuery an AutoCloseable may help, but it will
> contrast with other Query types that don't need to be closed.
>
> Note: It is not frequent to call many store procedures on a loop, I
> would have preferred to just create a new procedure with the loop, but
> for this application the conditions about when to call the procedure for
> each iteration are outside the database.
>
> [1] http://www-01.ibm.com/support/docview.wss?uid=swg21504334
> [2]
>
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/procedure/internal/ProcedureCallImpl.java#L437
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Fri Oct 13 15:21:11 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 13 Oct 2017 21:21:11 +0200
Subject: [hibernate-dev] Programmatic entity mapping API
Message-ID: <CADGJaX-94Zypr_HxJkEbirNuX7p2PTbGwLCOMUxzNOQdPSjw+A@mail.gmail.com>

Hi all,

This has crossed my mind for a few times: should we provide a programmatic
API in Hibernate ORM for mapping entities, as an alternative mapping
definition source to annotations and XML? I.e. something similar to the
programmatic mapping APIs we have in Hibernate Validator and Search.

It'd probably be a fair bit of work (though giving lots of fun with API
design), but I can see how it could be appealing to folks preferring
API-style ways of configuring their stack, which seems more and more en
vogue these days. Using lambda expressions would be attractive especially
when it comes to plugging in custom behaviours, e.g. for value generators.

Any thoughts?

--Gunnar

From gbadner at redhat.com  Fri Oct 13 16:35:05 2017
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 13 Oct 2017 13:35:05 -0700
Subject: [hibernate-dev] Question..
In-Reply-To: <CAFdSV9sVf1V2FAGLcYV1+AbcsQYWdKyj+gX8d_=6pPueebfg-Q@mail.gmail.com>
References: <CAFdSV9sCuXkss+hwHtp8hXJnFY3NpYdf1Es-gRg+ttX3ObJMFQ@mail.gmail.com>
	<CAFDzhiTN8s1tWd1NnRzMRjjTzy_ucO4RFJ=nnOGpEXZSJBXS4g@mail.gmail.com>
	<CAFdSV9sVf1V2FAGLcYV1+AbcsQYWdKyj+gX8d_=6pPueebfg-Q@mail.gmail.com>
Message-ID: <CAFDzhiT7a46YtOmHD1XsOJAHFiaoKsnL720F13VkS2ZDnYWhRg@mail.gmail.com>

Hi Steve,

I'm circling back to this. Please see below...

On Sat, Sep 2, 2017 at 8:47 AM, Steve Ebersole <steve at hibernate.org> wrote:
> I don't have the original email to reply to.  So I'll reply here.
>
> Overall, I had not really considered the primitive attribute case, but yeah
> that's clearly an issue.  My mistake.
>
> A) I agree that the con here is huge.  Not the best option
>
> B) Is close to better.  We could certainly check this and throw an error.

Throwing an exception is option A.

>  A better logical option is to do similar to what we do for ids and versions...
> on startup instantiate one of these and grab/store its initial state when
> freshly instantiated.  We can later use those values to perform the empty
> check.  This is more logical, but not sure how "practical" it is given that
> we do not really have a good place to keep this relative to an embeddable,
> nor relative to an embedded, aside from CompositeType, but that does not
> feel right.

Is this what you refer to as (B) (expanded)?

My first email in the thread (which I told you to disregard) basically
suggests doing this. I told you to disregard it because I realized
that it would have serious issues.

Please see an example of the consequences when the embedded represents
an ID: https://github.com/hibernate/hibernate-orm/pull/1993/commits/329354bfa4bd86190252f1d5a7019f8b06c21b17

> This is better in 6 as we have an actual runtime model
> representation of the embedded and embeddable - but of course that does not
> help us in 5
>
> C) I really hate exposing `ComponentType` on a new SPI interface considering
> the type system is completely revamped in 6.  This would be (1) a very short
> lived contract in this form and therefore (2) means yet another pain point
> for user upgrading 5->6.  Ultimately I think this is the most promising
> solution moving forward (possibly coupled with the "expanded" B option)..
> However, that said, I am not sure we have a choice prior to 6 if we want to
> go this route - we'd have to expose the CompositeType..  There is no good
> singular thing prior to 6 to describe a embedded/embeddable.  To clarify
> what sounds like a misunderstanding though, CompositeType is unique to each
> embedded usage, not embeddable.  The CompositeType however does not expose
> its "role", so not sure if that distinction helps here.

Thanks for mentioning this. I'd forgotten that CompositeType is for
the "embedded" (JPA meaning)  type.

If it's possible to get the role set in ComponentMetamodel, then it
seems we could use the role instead of the ComponentType in
EmptyCompositeStrategy SPI. H5 could determine the Type using the
role. Would that work in H6 as well?

(I noticed I had a redundant argument (Object component) in
EmptyCompositeStrategy#isEmptyComposite; it's removed below)

public interface EmptyCompositeStrategy {
    /**
     * Should a composite/embeddable be instantiated when a null attribute
     * having the specified role is read?
     *
     * @return true if Hibernate should instantiate a composite/embeddable
     * object when a null composite attribute is read.
     */
    boolean supportsEmptyComposite(String role);

    /**
     * Is the specified value an empty composite that should be considered
     * equal to <code>null</code>?
     *
     * @return true if the specified value is an empty composite.
     */
    boolean isEmptyComposite(String role, Object value,
SessionFactoryImplementor factory);
}

>
> To make sure I understand your (D)... you mean to allow users to disable
> this option globally but to allow this option per specific embedded?  Longer
> term (6) I think this is something else we ought to support as well as the
> inverse (globally opt-in, but allowing a local opt-out).

This is what I was suggesting, although I see I had a typo. It should have said:

D) Provide a way to opt-in when
hibernate.create_empty_composites_strategy=false, or to opt-out when
hibernate.create_empty_composites_strategy=true.

> That's not necessarily a strategy though for dealing with embeddeds that are "opted-in"
> that happen to use primitives.  Yes, it allows the user to more actively and
> selectively manage that themselves, but if they happen to opt-in an embedded
> which contains primitives we have the same issue to deal with.

I'm not sure I'm following this.

In the case where an application opts-in using
hibernate.create_empty_composites_strategy=true, and there is an
embeddabIe with primitive or non-null initialized values, I think it
would be reasonable to throw an exception as described by (A).

>
> Longer term I see allowing a mix of (B) (expanded), (C) and (D).
>
> For the short term (5), I think a the (possibly expanded) (B) option is the
> best.  I say that because (a) I prefer to not add a new contract like this
> for a bug-fix release and (b) the concern about the immediate contract
> change in 6.  If we all deem that this is acceptable, I's be fine with (C)
> as well.
>

If I'm understanding what you mean by (B) (expanded), then I don't
think that's is a good idea.

I think C is a good starting point in H5, preferably using role (if
that can be done).

Thanks,
Gail

>
> On Fri, Sep 1, 2017 at 4:14 PM Gail Badner <gbadner at redhat.com> wrote:
>>
>> Hi Steve,
>>
>> No, I didn't hear back from you.
>>
>> I asked for a response to an email sent to hibernate-dev mailing list with
>> subject, "HHH-11898: more "empty" composite issues".
>>
>> You can ignore the first message and just read the 2nd one.
>>
>> Thanks,
>> Gail
>>
>> On Fri, Sep 1, 2017 at 12:53 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>>
>>> You asked me to comment on an email, I'm sorry but I don't remember if I
>>> did. Did I respond to you?
>>
>>
>

From sanne at hibernate.org  Sat Oct 14 09:07:09 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 14 Oct 2017 15:07:09 +0200
Subject: [hibernate-dev] <join ... fetch="select"/>
In-Reply-To: <CAFdSV9tJmSt_PCYuuRCjY2BuimV=0c33tYuKg6EcmzoBDaCUNw@mail.gmail.com>
References: <CAFdSV9tJmSt_PCYuuRCjY2BuimV=0c33tYuKg6EcmzoBDaCUNw@mail.gmail.com>
Message-ID: <CAFm4XO3e4N8hOTNnxOtw8tFSLFQ688L6g97f7T1RQi5Akj0Afg@mail.gmail.com>

I remember finding secondary fetch options very useful when there's
good chances that the second fetch is prevented by 2nd level caching.

Even when 2nd level caching wasn't an option, we had plenty of very
complex objects so loading one would imly many joins; this would
reduce the number of joins per statement to something the RDBMS would
handle more reasonably in terms of performance. The performance
penalty for having many joins was both a metter of complexity but also
of cardinality of the size of results.

Both these cases were "joined" though at entity level, just tuning the
fetch option, so maybe it's not related to your question?

Thanks,
Sanne



On 13 October 2017 at 14:31, Steve Ebersole <steve at hibernate.org> wrote:
> Hibernate mappings define a feature to allow a secondary table (`<join/>`
> in hbm terms) to be defined as not joined via : `<join ...
> fetch="select"/>`.  This actually creates a subsequent select to load the
> data from the secondary table.
>
> I am trying to figure out how to best incorporate this into the paradigm
> for JDBC statement execution in 6.0.  My first thought was "do we need to
> keep this?".  Does anyone know of a real usage of this feature?  In theory
> it could be useful to some degree along with bytecode enhanced interception
> for lazy-loading individual attributes.  But even then, I'm not sure how
> practically useful that is.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Sun Oct 15 12:20:53 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 15 Oct 2017 16:20:53 +0000
Subject: [hibernate-dev] <join ... fetch="select"/>
In-Reply-To: <CAFm4XO3e4N8hOTNnxOtw8tFSLFQ688L6g97f7T1RQi5Akj0Afg@mail.gmail.com>
References: <CAFdSV9tJmSt_PCYuuRCjY2BuimV=0c33tYuKg6EcmzoBDaCUNw@mail.gmail.com>
	<CAFm4XO3e4N8hOTNnxOtw8tFSLFQ688L6g97f7T1RQi5Akj0Afg@mail.gmail.com>
Message-ID: <CAFdSV9tp1FLd=2GxoCBbdZwaHoWOvJZOgAe6nF6DcVJfK_bAqw@mail.gmail.com>

It sounds like you may be confused - like you are talking about
associations.  I am talking about "secondary tables".

On Sat, Oct 14, 2017 at 8:07 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> I remember finding secondary fetch options very useful when there's
> good chances that the second fetch is prevented by 2nd level caching.
>
> Even when 2nd level caching wasn't an option, we had plenty of very
> complex objects so loading one would imly many joins; this would
> reduce the number of joins per statement to something the RDBMS would
> handle more reasonably in terms of performance. The performance
> penalty for having many joins was both a metter of complexity but also
> of cardinality of the size of results.
>
> Both these cases were "joined" though at entity level, just tuning the
> fetch option, so maybe it's not related to your question?
>
> Thanks,
> Sanne
>
>
>
> On 13 October 2017 at 14:31, Steve Ebersole <steve at hibernate.org> wrote:
> > Hibernate mappings define a feature to allow a secondary table (`<join/>`
> > in hbm terms) to be defined as not joined via : `<join ...
> > fetch="select"/>`.  This actually creates a subsequent select to load the
> > data from the secondary table.
> >
> > I am trying to figure out how to best incorporate this into the paradigm
> > for JDBC statement execution in 6.0.  My first thought was "do we need to
> > keep this?".  Does anyone know of a real usage of this feature?  In
> theory
> > it could be useful to some degree along with bytecode enhanced
> interception
> > for lazy-loading individual attributes.  But even then, I'm not sure how
> > practically useful that is.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Sun Oct 15 13:46:41 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 15 Oct 2017 17:46:41 +0000
Subject: [hibernate-dev] Question..
In-Reply-To: <CAFDzhiT7a46YtOmHD1XsOJAHFiaoKsnL720F13VkS2ZDnYWhRg@mail.gmail.com>
References: <CAFdSV9sCuXkss+hwHtp8hXJnFY3NpYdf1Es-gRg+ttX3ObJMFQ@mail.gmail.com>
	<CAFDzhiTN8s1tWd1NnRzMRjjTzy_ucO4RFJ=nnOGpEXZSJBXS4g@mail.gmail.com>
	<CAFdSV9sVf1V2FAGLcYV1+AbcsQYWdKyj+gX8d_=6pPueebfg-Q@mail.gmail.com>
	<CAFDzhiT7a46YtOmHD1XsOJAHFiaoKsnL720F13VkS2ZDnYWhRg@mail.gmail.com>
Message-ID: <CAFdSV9sEYQnU0t9pfKRitu4knaBtwnD02zdW3M1S_EP2cctBcw@mail.gmail.com>

On Fri, Oct 13, 2017, 3:35 PM Gail Badner <gbadner at redhat.com> wrote:

> Hi Steve,
>
> I'm circling back to this. Please see below...
>
> On Sat, Sep 2, 2017 at 8:47 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
> > I don't have the original email to reply to.  So I'll reply here.
> >
> > Overall, I had not really considered the primitive attribute case, but
> yeah
> > that's clearly an issue.  My mistake.
> >
> > A) I agree that the con here is huge.  Not the best option
> >
> > B) Is close to better.  We could certainly check this and throw an error.
>
> Throwing an exception is option A.
>

Your (A) and (B) are the exact same thing (same underlying condition check)
except in (A) you throw an exception and in (B) you log a warning and
disregard an explicit user setting.

WRT to the condition check, you suggest to "compare a primitive value in a
composite with the default for the primitive type  (e.g, comparing an int
value with 0 instead of null)".  That's not the best condition check.  I
was pointing out that we already have better handling for this for ids and
versions and that we ought to follow that paradigm, mainly on startup we
would instantiate an instance of said component and check the initial
values for its attributes.  E.g., consider:

@Embeddable
public class MyEmbeddable {
    private int someInt;
    private int anotherInt = -1;
}

Here, comparison of `#anotherInt` to 0 is not really correct.  The proper
comparison is to -1.  Again, this is exactly what we do for ids and
versions.

So because your (A) and (B) check the same condition I was pointing out
that they actually are based on the incorrect condition check (0 versus
-1), so we should correct that assumption.  But even then we have  and
further that we should update the check and that we still have the
different outcome between (A) and (B) to decide between.

The downside I was trying to point out (and it is the same for issue for
some of the other parts of the discussion) is that we currently do not have
a singular place where we keep "embeddable" metadata - again, CompositeType
describes the embedded, not the embeddable.  But maybe it is ok to
duplicate this "instantiate and check" for each CompositeType.  A
alternative is to keep a mapping of this information as part of the
bootstrap data structures to help do that just once for every embedded of
that embeddable.

Further, in discussing these various options it is important to make the
distinction between the best solution in terms of

   1. short-term - how do we handle this for 5.x
   2. longer-term - how do we address this in 6.0+ because here we have
   some more flexibility.

Longer term, I ultimately think the following is the best solution:

   1. correct the condition as discussed above
   2. slightly modified version of (C) - see below
   3. slightly modified version of (D) - see below

The change I'd make to `EmptyCompositeStrategy` is specifically the
signatures and (slightly) the intent to work with (D).  Best case scenario,
again for 6.0+) I'd pass in
`org.hibernate.metamodel.model.domain.spi.EmbeddedTypeDescriptor` whose
intent is kind of, sort of the same as `ComponentMetamodel`[1].  Worst case
we'd pass in this `org.hibernate.metamodel.model.domain.NavigableRole` you
can see exposed here.  NavigableRoles can be resolved to their Navigable
via the TypeConfiguration (the Navigable here would be the
EmbeddedTypeDescriptor).  Additionally, these roles are nice in terms of
configuration as we will see below.

In terms of (D), I think configuration here is a good idea especially in
combination with (C).  In fact I can see the following settings:


   1. hibernate.empty_composite_creation
   1. enable - enable creation & throw exceptions when we deem we cannot
      create them (condition check discussion).  This is basically (A)
      2. warn - same as "enable", but warn when we cannot create them -
      basically (B)
      3. disable (default) - "opt out"
      4. strategy - consult the configured EmptyCompositeStrategy
   2. hibernate.empty_composite_strategy - names a `EmptyCompositeStrategy`
   to use


Additionally, I think it would be awesome to allow configuring (1) per
role, e.g. (assuming Person#name as a composite):

   1. hibernate.empty_composite_creation = strategy
   2.  hibernate.empty_composite_creation.com.acme.Person.name = disable

So for all composites we will use the configured strategy, except for
Person#name, which we have explicitly disabled / opted-out-of.





> >  A better logical option is to do similar to what we do for ids and
> versions...
> > on startup instantiate one of these and grab/store its initial state when
> > freshly instantiated.  We can later use those values to perform the empty
> > check.  This is more logical, but not sure how "practical" it is given
> that
> > we do not really have a good place to keep this relative to an
> embeddable,
> > nor relative to an embedded, aside from CompositeType, but that does not
> > feel right.
>
> Is this what you refer to as (B) (expanded)?
>

> My first email in the thread (which I told you to disregard) basically
> suggests doing this. I told you to disregard it because I realized
> that it would have serious issues.
>

I'm not seeing where that first email suggests checking based on the actual
initialized value rather than the "primitive type default".  But if it did,
then yes that is a better check as discussed above.



Please see an example of the consequences when the embedded represents
> an ID:
> https://github.com/hibernate/hibernate-orm/pull/1993/commits/329354bfa4bd86190252f1d5a7019f8b06c21b17


Ids should be excluded from this completely.  Hibernate does not support
any part of a PK to be nullable - ergo this entire discussion is completely
irrelevant for composite PKs.




> If I'm understanding what you mean by (B) (expanded), then I don't
> think that's is a good idea.
>

As I said in my initial reply and above, I am not a fan of (B) - I think it
is, generally speaking, a bad option to ignore settings that the user has
explicitly set.  But again, we need to keep short/long term in mind because
short-term I think every other option has some significant drawbacks.

And long-term it comes down to what we allow for configuration.  E.g. if we
do not allow the full breath of config options I mentioned, then that
changes things.



I think C is a good starting point in H5, preferably using role (if
> that can be done).
>

For 5.x, (C) may be the best option aside from the argument discussion.
Like I said, in terms of 6 the best argument to pass would be
EmbeddedTypeDescriptor.  Or, depending on the timing (boot model versus
runtime model) `org.hibernate.boot.model.domain.EmbeddedMapping` /
`org.hibernate.boot.model.domain.EmbeddedValueMapping`.

We *could* pass in this role as a String, but I really hate passing
Strings.  Another option would be to back-port NavigableRole and expose
these from EntityPersister/EntityType, CollectionPersister/CollectionType
and ComponentType.

I'm trying to get something that will work in both 5 and 6 to minimize
changes for users as they migrate.  Assuming we back-port NavigableRole,
something like:


public interface EmptyCompositeStrategy {
    /**
     * Should a composite/embeddable be instantiated all of
     * its composed attribute values are null?
     */
    boolean supportsEmptyComposite(NavigableRole compositeRole);

    /**
     * Is the given composite value considered "empty"?
     */
    boolean isEmptyComposite(
            NavigableRole compositeRole,
            Object value,
            Object component,
            SessionFactoryImplementor factory);
}

Although, tbh I am not really understanding the intent of your second
method.  Are you asking the strategy to check each individual sub-attribute
for emptiness?  Also, are you thinking this gets called when reading the
values?  Or when writing the values?


[1]
https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/metamodel/model/domain/spi/EmbeddedTypeDescriptor.java

From robert at marcanoonline.com  Mon Oct 16 08:37:43 2017
From: robert at marcanoonline.com (Robert Marcano)
Date: Mon, 16 Oct 2017 08:37:43 -0400
Subject: [hibernate-dev] Statements leaks when using JPA
 StoredProcedureQuery API
In-Reply-To: <CAFdSV9s0USQ-eoFxGq1WrUVA2xMeOPeZ3PVh9gTTeCDPUddAvA@mail.gmail.com>
References: <575ba814-1873-2be5-f8ad-a00296e94efa@marcanoonline.com>
	<CAFdSV9s0USQ-eoFxGq1WrUVA2xMeOPeZ3PVh9gTTeCDPUddAvA@mail.gmail.com>
Message-ID: <099f1ccb-3bc5-b711-04eb-2edf82f731ca@marcanoonline.com>

On 10/13/2017 03:11 PM, Steve Ebersole wrote:
> The conceptualization of a Query for both Hibernate and JPA is that you 
> execute it and get back the result of that execution: a List, a single 
> result, a ScrollableResult, a Stream, etc.
> 
> Yet then JPA throws in StoredProcedureQuery which is completely 
> different conceptually.? Here you execute and then (statefully!!!) 
> access the individual pieces of that execution's results.
> 
> Sadly the JPA StoredProcedureQuery API is just messed up.? In my opinion 
> (yes, of course I'm biased) our ProcedureCall?+ ProcedureOutputs model 
> is MUCH better. It is more in line with that conceptualization of Query 
> -> Result as opposed to StoredProcedureQuery's Query -> Query-as-Result.
> 
> All that said...
> 
> What you are asking for here is to implicitly close the JDBC 
> CallableStatement when we recognize <some condition> that signifies?the 
> exhaustion of the execution results.? What is that condition?? Can't be 
> just when there are no more ResultSets in the CallableStatement's 
> pipeline.? Consider calling StoredProcedureQuery#getOutputParameterValue 
> (which would require accessing the CallableStatement) *after*?we have 
> implicitly closed the CallableStatement.

No, I know implicitly closing the JDBC statement is not possible with 
only the current CallableStatement API. There is no way to know if the 
client code needs or read all possible outputs from the stored 
procedure. My previous email mentioned making CallableStatement an 
AutoCloseable but that will make the API too different from the other 
kind of queries, that you explained better than me, are stateless.

Maybe exposing Hibernate ProcedureOutputs to JPA or StoredProcedureQuery 
implementing some kind of prepareCall() method that return a stateful 
object that implement AutoCloseable.

> 
> So what is that condition?? That's the rub...
> 
> 
> On Wed, Oct 11, 2017 at 1:07 PM Robert Marcano <robert at marcanoonline.com 
> <mailto:robert at marcanoonline.com>> wrote:
> 
>     Migrating code from the Hibernate API to JPA, I found a stored procedure
>     being called on a loop that was generating DB2 errors [1] on tests. This
>     error is caused in this case for having a lot of not closed statements.
> 
>     The problem didn't happen using ProcedureCall Hibernate API because the
>     method getOutputs() and release() from the Outputs instance are
>     available.
> 
>     StoredProcedureQuery JPA API doesn't have any way to "close" the query
>     and by that, the statement. Reusing the same instance of
>     StoredProcedureQuery trying to only leak an unclosed statement but that
>     doesn't help either, ProcedureCallImpl is creating a new statement for
>     every call [2].
> 
>     The only option is to unwrap the StoredProcedureQuery to an
>     StoredProcedureQuery and release the Outputs instance.
> 
>     I don't think there is a way to avoid this without enhancing the JPA
>     API. Client code can call an store procedure and in some cases not
>     caring about all the results, so there is no way for a JPA
>     implementation to know when to close the statement.
> 
>     Making StoredProcedureQuery an AutoCloseable may help, but it will
>     contrast with other Query types that don't need to be closed.
> 
>     Note: It is not frequent to call many store procedures on a loop, I
>     would have preferred to just create a new procedure with the loop, but
>     for this application the conditions about when to call the procedure for
>     each iteration are outside the database.
> 
>     [1] http://www-01.ibm.com/support/docview.wss?uid=swg21504334
>     [2]
>     https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/procedure/internal/ProcedureCallImpl.java#L437
> 
> 
>     _______________________________________________
>     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 robert at marcanoonline.com  Mon Oct 16 09:37:04 2017
From: robert at marcanoonline.com (Robert Marcano)
Date: Mon, 16 Oct 2017 09:37:04 -0400
Subject: [hibernate-dev] Statements leaks when using JPA
 StoredProcedureQuery API
In-Reply-To: <CA+gWKMB_1jXwDUj=ziyobd6xiiYDLSHAo6w5+nXznfSGJmcojQ@mail.gmail.com>
References: <575ba814-1873-2be5-f8ad-a00296e94efa@marcanoonline.com>
	<CA+gWKMB_1jXwDUj=ziyobd6xiiYDLSHAo6w5+nXznfSGJmcojQ@mail.gmail.com>
Message-ID: <6b9c95c2-dd62-afdb-e010-b23390887ad9@marcanoonline.com>

On 10/11/2017 03:15 PM, Vlad Mihalcea wrote:
> You can open a GitHub issue for JPA. Meanwhile, you can work around it 
> as you suggested.

Opened an issue on JPA spec https://github.com/javaee/jpa-spec/issues/162

> 
> On 11 Oct 2017 9:08 pm, "Robert Marcano" <robert at marcanoonline.com 
> <mailto:robert at marcanoonline.com>> wrote:
> 
>     Migrating code from the Hibernate API to JPA, I found a stored procedure
>     being called on a loop that was generating DB2 errors [1] on tests. This
>     error is caused in this case for having a lot of not closed statements.
> 
>     The problem didn't happen using ProcedureCall Hibernate API because the
>     method getOutputs() and release() from the Outputs instance are
>     available.
> 
>     StoredProcedureQuery JPA API doesn't have any way to "close" the query
>     and by that, the statement. Reusing the same instance of
>     StoredProcedureQuery trying to only leak an unclosed statement but that
>     doesn't help either, ProcedureCallImpl is creating a new statement for
>     every call [2].
> 
>     The only option is to unwrap the StoredProcedureQuery to an
>     StoredProcedureQuery and release the Outputs instance.
> 
>     I don't think there is a way to avoid this without enhancing the JPA
>     API. Client code can call an store procedure and in some cases not
>     caring about all the results, so there is no way for a JPA
>     implementation to know when to close the statement.
> 
>     Making StoredProcedureQuery an AutoCloseable may help, but it will
>     contrast with other Query types that don't need to be closed.
> 
>     Note: It is not frequent to call many store procedures on a loop, I
>     would have preferred to just create a new procedure with the loop, but
>     for this application the conditions about when to call the procedure for
>     each iteration are outside the database.
> 
>     [1] http://www-01.ibm.com/support/docview.wss?uid=swg21504334
>     <http://www-01.ibm.com/support/docview.wss?uid=swg21504334>
>     [2]
>     https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/procedure/internal/ProcedureCallImpl.java#L437
>     <https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/procedure/internal/ProcedureCallImpl.java#L437>
> 
> 
>     _______________________________________________
>     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
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> 


From steve at hibernate.org  Mon Oct 16 10:13:44 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 16 Oct 2017 14:13:44 +0000
Subject: [hibernate-dev] Statements leaks when using JPA
 StoredProcedureQuery API
In-Reply-To: <099f1ccb-3bc5-b711-04eb-2edf82f731ca@marcanoonline.com>
References: <575ba814-1873-2be5-f8ad-a00296e94efa@marcanoonline.com>
	<CAFdSV9s0USQ-eoFxGq1WrUVA2xMeOPeZ3PVh9gTTeCDPUddAvA@mail.gmail.com>
	<099f1ccb-3bc5-b711-04eb-2edf82f731ca@marcanoonline.com>
Message-ID: <CAFdSV9sxopnxNUQyZrL6h3aM2N8ViBb+5dz6c_txRP2AkTANYw@mail.gmail.com>

On Mon, Oct 16, 2017 at 9:00 AM Robert Marcano <robert at marcanoonline.com>
wrote:

> No, I know implicitly closing the JDBC statement is not possible with
> only the current CallableStatement API. There is no way to know if the
> client code needs or read all possible outputs from the stored
> procedure. My previous email mentioned making CallableStatement an
> AutoCloseable but that will make the API too different from the other
> kind of queries, that you explained better than me, are stateless.
>
> Maybe exposing Hibernate ProcedureOutputs to JPA or StoredProcedureQuery
> implementing some kind of prepareCall() method that return a stateful
> object that implement AutoCloseable.
>

"Exposing Hibernate ProcedureOutputs to JPA" how?  Something beyond the
`storedProcedureQuery.unwrap( ProcedureOutputs.class )` I mentioned earlier?

From robert at marcanoonline.com  Mon Oct 16 10:28:03 2017
From: robert at marcanoonline.com (Robert Marcano)
Date: Mon, 16 Oct 2017 10:28:03 -0400
Subject: [hibernate-dev] Statements leaks when using JPA
 StoredProcedureQuery API
In-Reply-To: <CAFdSV9sxopnxNUQyZrL6h3aM2N8ViBb+5dz6c_txRP2AkTANYw@mail.gmail.com>
References: <575ba814-1873-2be5-f8ad-a00296e94efa@marcanoonline.com>
	<CAFdSV9s0USQ-eoFxGq1WrUVA2xMeOPeZ3PVh9gTTeCDPUddAvA@mail.gmail.com>
	<099f1ccb-3bc5-b711-04eb-2edf82f731ca@marcanoonline.com>
	<CAFdSV9sxopnxNUQyZrL6h3aM2N8ViBb+5dz6c_txRP2AkTANYw@mail.gmail.com>
Message-ID: <33e02d45-2d47-9912-386f-0fc8c104b294@marcanoonline.com>

On 10/16/2017 10:13 AM, Steve Ebersole wrote:
> On Mon, Oct 16, 2017 at 9:00 AM Robert Marcano <robert at marcanoonline.com 
> <mailto:robert at marcanoonline.com>> wrote:
> 
>     No, I know implicitly closing the JDBC statement is not possible with
>     only the current CallableStatement API. There is no way to know if the
>     client code needs or read all possible outputs from the stored
>     procedure. My previous email mentioned making CallableStatement an
>     AutoCloseable but that will make the API too different from the other
>     kind of queries, that you explained better than me, are stateless.
> 
>     Maybe exposing Hibernate ProcedureOutputs to JPA or StoredProcedureQuery
>     implementing some kind of prepareCall() method that return a stateful
>     object that implement AutoCloseable.
> 
> 
> "Exposing?Hibernate ProcedureOutputs to JPA" how?? Something beyond the
> `storedProcedureQuery.unwrap( ProcedureOutputs.class )` I mentioned earlier?
> 

Yes, I think there should be a way to close a StoredProcedureQuery 
internal statement without the need to unwrap to a JPA implementation class.

An equivalent to ProcedureOutputs added to the JPA spec implementing 
AutoCloseable sounds fine to me.

From steve at hibernate.org  Mon Oct 16 12:09:06 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 16 Oct 2017 16:09:06 +0000
Subject: [hibernate-dev] Statements leaks when using JPA
 StoredProcedureQuery API
In-Reply-To: <6b9c95c2-dd62-afdb-e010-b23390887ad9@marcanoonline.com>
References: <575ba814-1873-2be5-f8ad-a00296e94efa@marcanoonline.com>
	<CA+gWKMB_1jXwDUj=ziyobd6xiiYDLSHAo6w5+nXznfSGJmcojQ@mail.gmail.com>
	<6b9c95c2-dd62-afdb-e010-b23390887ad9@marcanoonline.com>
Message-ID: <CAFdSV9t82y=74wF=XNxqtRCc+iRNS+nm8TyNhf+gLN5uSMYjBA@mail.gmail.com>

Sweet, thanks

On Mon, Oct 16, 2017 at 10:59 AM Robert Marcano <robert at marcanoonline.com>
wrote:

> On 10/11/2017 03:15 PM, Vlad Mihalcea wrote:
> > You can open a GitHub issue for JPA. Meanwhile, you can work around it
> > as you suggested.
>
> Opened an issue on JPA spec https://github.com/javaee/jpa-spec/issues/162
>
> >
> > On 11 Oct 2017 9:08 pm, "Robert Marcano" <robert at marcanoonline.com
> > <mailto:robert at marcanoonline.com>> wrote:
> >
> >     Migrating code from the Hibernate API to JPA, I found a stored
> procedure
> >     being called on a loop that was generating DB2 errors [1] on tests.
> This
> >     error is caused in this case for having a lot of not closed
> statements.
> >
> >     The problem didn't happen using ProcedureCall Hibernate API because
> the
> >     method getOutputs() and release() from the Outputs instance are
> >     available.
> >
> >     StoredProcedureQuery JPA API doesn't have any way to "close" the
> query
> >     and by that, the statement. Reusing the same instance of
> >     StoredProcedureQuery trying to only leak an unclosed statement but
> that
> >     doesn't help either, ProcedureCallImpl is creating a new statement
> for
> >     every call [2].
> >
> >     The only option is to unwrap the StoredProcedureQuery to an
> >     StoredProcedureQuery and release the Outputs instance.
> >
> >     I don't think there is a way to avoid this without enhancing the JPA
> >     API. Client code can call an store procedure and in some cases not
> >     caring about all the results, so there is no way for a JPA
> >     implementation to know when to close the statement.
> >
> >     Making StoredProcedureQuery an AutoCloseable may help, but it will
> >     contrast with other Query types that don't need to be closed.
> >
> >     Note: It is not frequent to call many store procedures on a loop, I
> >     would have preferred to just create a new procedure with the loop,
> but
> >     for this application the conditions about when to call the procedure
> for
> >     each iteration are outside the database.
> >
> >     [1] http://www-01.ibm.com/support/docview.wss?uid=swg21504334
> >     <http://www-01.ibm.com/support/docview.wss?uid=swg21504334>
> >     [2]
> >
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/procedure/internal/ProcedureCallImpl.java#L437
> >     <
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/procedure/internal/ProcedureCallImpl.java#L437
> >
> >
> >
> >     _______________________________________________
> >     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
> >     <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 Oct 16 15:04:36 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 16 Oct 2017 19:04:36 +0000
Subject: [hibernate-dev] Statements leaks when using JPA
 StoredProcedureQuery API
In-Reply-To: <33e02d45-2d47-9912-386f-0fc8c104b294@marcanoonline.com>
References: <575ba814-1873-2be5-f8ad-a00296e94efa@marcanoonline.com>
	<CAFdSV9s0USQ-eoFxGq1WrUVA2xMeOPeZ3PVh9gTTeCDPUddAvA@mail.gmail.com>
	<099f1ccb-3bc5-b711-04eb-2edf82f731ca@marcanoonline.com>
	<CAFdSV9sxopnxNUQyZrL6h3aM2N8ViBb+5dz6c_txRP2AkTANYw@mail.gmail.com>
	<33e02d45-2d47-9912-386f-0fc8c104b294@marcanoonline.com>
Message-ID: <CAFdSV9tcAiCcgkZ23Q5MN5vESG3udvT1YJ5syaFPqQ0WDVbEww@mail.gmail.com>

If only.  I seriously doubt we can get that approach as the solution
through the EG, but we'll see

On Mon, Oct 16, 2017, 1:12 PM Robert Marcano <robert at marcanoonline.com>
wrote:

> On 10/16/2017 10:13 AM, Steve Ebersole wrote:
> > On Mon, Oct 16, 2017 at 9:00 AM Robert Marcano <robert at marcanoonline.com
> > <mailto:robert at marcanoonline.com>> wrote:
> >
> >     No, I know implicitly closing the JDBC statement is not possible with
> >     only the current CallableStatement API. There is no way to know if
> the
> >     client code needs or read all possible outputs from the stored
> >     procedure. My previous email mentioned making CallableStatement an
> >     AutoCloseable but that will make the API too different from the other
> >     kind of queries, that you explained better than me, are stateless.
> >
> >     Maybe exposing Hibernate ProcedureOutputs to JPA or
> StoredProcedureQuery
> >     implementing some kind of prepareCall() method that return a stateful
> >     object that implement AutoCloseable.
> >
> >
> > "Exposing Hibernate ProcedureOutputs to JPA" how?  Something beyond the
> > `storedProcedureQuery.unwrap( ProcedureOutputs.class )` I mentioned
> earlier?
> >
>
> Yes, I think there should be a way to close a StoredProcedureQuery
> internal statement without the need to unwrap to a JPA implementation
> class.
>
> An equivalent to ProcedureOutputs added to the JPA spec implementing
> AutoCloseable sounds fine to me.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Tue Oct 17 01:55:47 2017
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 16 Oct 2017 22:55:47 -0700
Subject: [hibernate-dev] Question..
In-Reply-To: <CAFdSV9sEYQnU0t9pfKRitu4knaBtwnD02zdW3M1S_EP2cctBcw@mail.gmail.com>
References: <CAFdSV9sCuXkss+hwHtp8hXJnFY3NpYdf1Es-gRg+ttX3ObJMFQ@mail.gmail.com>
	<CAFDzhiTN8s1tWd1NnRzMRjjTzy_ucO4RFJ=nnOGpEXZSJBXS4g@mail.gmail.com>
	<CAFdSV9sVf1V2FAGLcYV1+AbcsQYWdKyj+gX8d_=6pPueebfg-Q@mail.gmail.com>
	<CAFDzhiT7a46YtOmHD1XsOJAHFiaoKsnL720F13VkS2ZDnYWhRg@mail.gmail.com>
	<CAFdSV9sEYQnU0t9pfKRitu4knaBtwnD02zdW3M1S_EP2cctBcw@mail.gmail.com>
Message-ID: <CAFDzhiSbgeUH1Cv3x7B6aTjd=3hO0GRfBT-HsZC=_aqPNCQHCA@mail.gmail.com>

On Sun, Oct 15, 2017 at 10:46 AM, Steve Ebersole <steve at hibernate.org> wrote:
> On Fri, Oct 13, 2017, 3:35 PM Gail Badner <gbadner at redhat.com> wrote:
>>
>> Hi Steve,
>>
>> I'm circling back to this. Please see below...
>>
>> On Sat, Sep 2, 2017 at 8:47 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> > I don't have the original email to reply to.  So I'll reply here.
>> >
>> > Overall, I had not really considered the primitive attribute case, but
>> > yeah
>> > that's clearly an issue.  My mistake.
>> >
>> > A) I agree that the con here is huge.  Not the best option
>> >
>> > B) Is close to better.  We could certainly check this and throw an
>> > error.
>>
>> Throwing an exception is option A.
>
>
> Your (A) and (B) are the exact same thing (same underlying condition check)
> except in (A) you throw an exception and in (B) you log a warning and
> disregard an explicit user setting.

Correct.

>
> WRT to the condition check, you suggest to "compare a primitive value in a
> composite with the default for the primitive type  (e.g, comparing an int
> value with 0 instead of null)".  That's not the best condition check.  I was
> pointing out that we already have better handling for this for ids and
> versions and that we ought to follow that paradigm, mainly on startup we
> would instantiate an instance of said component and check the initial values
> for its attributes.  E.g., consider:
>
> @Embeddable
> public class MyEmbeddable {
>     private int someInt;
>     private int anotherInt = -1;
> }
>
> Here, comparison of `#anotherInt` to 0 is not really correct.  The proper
> comparison is to -1.  Again, this is exactly what we do for ids and
> versions.
>
> So because your (A) and (B) check the same condition I was pointing out that
> they actually are based on the incorrect condition check (0 versus -1), so
> we should correct that assumption.  But even then we have  and further that
> we should update the check and that we still have the different outcome
> between (A) and (B) to decide between.

I have already implemented something that does the check that you
suggested, and I decided against it for a couple of reasons:
1) Any initialized values can be "real" values.
2) Suppose an instantiated embedded value includes something like:
    Date created = new Date();
    double random = Math.random();
For 2), an embedded value would never be considered empty, and its
values would always be persisted instead of null.

I think that it should be up to the `EmptyCompositeStrategy` to decide
if a primitive that has the default value, or something like `created`
or `random` should be ignored when determining if an embedded value is
empty.

>
> The downside I was trying to point out (and it is the same for issue for
> some of the other parts of the discussion) is that we currently do not have
> a singular place where we keep "embeddable" metadata - again, CompositeType
> describes the embedded, not the embeddable.  But maybe it is ok to duplicate
> this "instantiate and check" for each CompositeType.  A alternative is to
> keep a mapping of this information as part of the bootstrap data structures
> to help do that just once for every embedded of that embeddable.
>
> Further, in discussing these various options it is important to make the
> distinction between the best solution in terms of
>
> short-term - how do we handle this for 5.x
> longer-term - how do we address this in 6.0+ because here we have some more
> flexibility.
>
> Longer term, I ultimately think the following is the best solution:
>
> correct the condition as discussed above

As I mention, I don't think correcting the condition is the right thing to do.

> slightly modified version of (C) - see below
> slightly modified version of (D) - see below
>
> The change I'd make to `EmptyCompositeStrategy` is specifically the
> signatures and (slightly) the intent to work with (D).  Best case scenario,
> again for 6.0+) I'd pass in
> `org.hibernate.metamodel.model.domain.spi.EmbeddedTypeDescriptor` whose
> intent is kind of, sort of the same as `ComponentMetamodel`[1].  Worst case
> we'd pass in this `org.hibernate.metamodel.model.domain.NavigableRole` you
> can see exposed here.  NavigableRoles can be resolved to their Navigable via
> the TypeConfiguration (the Navigable here would be the
> EmbeddedTypeDescriptor).  Additionally, these roles are nice in terms of
> configuration as we will see below.
>
> In terms of (D), I think configuration here is a good idea especially in
> combination with (C).  In fact I can see the following settings:
>
> hibernate.empty_composite_creation
>
> enable - enable creation & throw exceptions when we deem we cannot create
> them (condition check discussion).  This is basically (A)
> warn - same as "enable", but warn when we cannot create them - basically (B)
> disable (default) - "opt out"
> strategy - consult the configured EmptyCompositeStrategy
>
> hibernate.empty_composite_strategy - names a `EmptyCompositeStrategy` to use
>

I like what you describe above.

Currently the property is named `hibernate.create_empty_composites.enabled`.

Are you suggesting we rename the property in 6.0+?

For 5.x, these would be options for hibernate.create_empty_composites.enabled:

true - enable creation & throw exceptions when we deem we cannot
create them (condition check discussion).  This is basically (A)
warn - same as "enable", but warn when we cannot create them - basically (B)
false - disable (default) - "opt out"
strategy - consult the configured EmptyCompositeStrategy

>
> Additionally, I think it would be awesome to allow configuring (1) per role,
> e.g. (assuming Person#name as a composite):
>
> hibernate.empty_composite_creation = strategy
>  hibernate.empty_composite_creation.com.acme.Person.name = disable
>
> So for all composites we will use the configured strategy, except for
> Person#name, which we have explicitly disabled / opted-out-of.
>

I like this as well.

For 5.x, I guess we'd have something like this to opt out:

hibernate.create_empty_composites.enabled=strategy
hibernate.create_empty_composites.enabled.com.acme.Person.name=false

Should we also allow to disable in general, then opt-in for Person.name, as in:

hibernate.create_empty_composites.enabled=false
hibernate.create_empty_composites.enabled.com.acme.Person.name=true
(this would fail like case (A) if the newly instantiated value has
initialized values)

Also, allow a strategy to be used for the opted-in value:

hibernate.create_empty_composites.enabled=false
hibernate.create_empty_composites.enabled.com.acme.Person.name=strategy

>
>
>
>>
>> >  A better logical option is to do similar to what we do for ids and
>> > versions...
>> > on startup instantiate one of these and grab/store its initial state
>> > when
>> > freshly instantiated.  We can later use those values to perform the
>> > empty
>> > check.  This is more logical, but not sure how "practical" it is given
>> > that
>> > we do not really have a good place to keep this relative to an
>> > embeddable,
>> > nor relative to an embedded, aside from CompositeType, but that does not
>> > feel right.
>>
>> Is this what you refer to as (B) (expanded)?
>>
>>
>> My first email in the thread (which I told you to disregard) basically
>> suggests doing this. I told you to disregard it because I realized
>> that it would have serious issues.
>
>
> I'm not seeing where that first email suggests checking based on the actual
> initialized value rather than the "primitive type default".  But if it did,
> then yes that is a better check as discussed above.
>
>
>
>> Please see an example of the consequences when the embedded represents
>> an ID:
>> https://github.com/hibernate/hibernate-orm/pull/1993/commits/329354bfa4bd86190252f1d5a7019f8b06c21b17
>
>
> Ids should be excluded from this completely.  Hibernate does not support any
> part of a PK to be nullable - ergo this entire discussion is completely
> irrelevant for composite PKs.
>

My example involves a nullable property that happens to be a composite ID.

Please take a look at the mapping in my example:
https://github.com/hibernate/hibernate-orm/pull/1993/commits/329354bfa4bd86190252f1d5a7019f8b06c21b17#diff-a16e0cd57dc44a1cabeed67869babacfR162

IMO, it's a really bad idea for Hibernate to assume, by default, that
initialized values in a newly instantiated embedded value would be
considered empty.

>
>
>>
>> If I'm understanding what you mean by (B) (expanded), then I don't
>> think that's is a good idea.
>
>
> As I said in my initial reply and above, I am not a fan of (B) - I think it
> is, generally speaking, a bad option to ignore settings that the user has
> explicitly set.  But again, we need to keep short/long term in mind because
> short-term I think every other option has some significant drawbacks.
>
> And long-term it comes down to what we allow for configuration.  E.g. if we
> do not allow the full breath of config options I mentioned, then that
> changes things.
>
>
>
>> I think C is a good starting point in H5, preferably using role (if
>> that can be done).
>
>
> For 5.x, (C) may be the best option aside from the argument discussion.
> Like I said, in terms of 6 the best argument to pass would be
> EmbeddedTypeDescriptor.  Or, depending on the timing (boot model versus
> runtime model) `org.hibernate.boot.model.domain.EmbeddedMapping` /
> `org.hibernate.boot.model.domain.EmbeddedValueMapping`.
>
> We *could* pass in this role as a String, but I really hate passing Strings.
> Another option would be to back-port NavigableRole and expose these from
> EntityPersister/EntityType, CollectionPersister/CollectionType and
> ComponentType.

I'll have to look at NavigableRole to see what you mean. We are hoping
to backport to 5.1. I don't think I can make changes to
EntityPersister/CollectionPersister in 5.1, since we can't use default
methods.

>
> I'm trying to get something that will work in both 5 and 6 to minimize
> changes for users as they migrate.  Assuming we back-port NavigableRole,
> something like:
>
>
> public interface EmptyCompositeStrategy {
>     /**
>      * Should a composite/embeddable be instantiated all of
>      * its composed attribute values are null?
>      */
>     boolean supportsEmptyComposite(NavigableRole compositeRole);
>
>     /**
>      * Is the given composite value considered "empty"?
>      */
>     boolean isEmptyComposite(
>             NavigableRole compositeRole,
>             Object value,
>             Object component,
>             SessionFactoryImplementor factory);
> }

I mentioned in my previous email that there was an extra argument and
corrected it there. With your change it should be:

>     boolean isEmptyComposite(
>             NavigableRole compositeRole,
>             Object value,
>             SessionFactoryImplementor factory);

>
> Although, tbh I am not really understanding the intent of your second
> method.  Are you asking the strategy to check each individual sub-attribute
> for emptiness?  Also, are you thinking this gets called when reading the
> values?  Or when writing the values?
>

It is intended to determine if a particular composite value should be
considered empty. It will be needed by ComponentType#isEqual,
#compare, #isDirty, #isModified to determine if 2 values are both
considered empty.

In the case that an embeddable has an indeterminate sub-attribute, the
2 values could have a different sub-attribute value, but
EmptyCompositeStrategy#isEmptyComposite could ignore that
sub-attribute in its determination.

>
> [1]
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/metamodel/model/domain/spi/EmbeddedTypeDescriptor.java
>
>

From davide at hibernate.org  Tue Oct 17 08:26:06 2017
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 17 Oct 2017 13:26:06 +0100
Subject: [hibernate-dev] Hibernate OGM 5.2 Beta1 Release
Message-ID: <CANoTJYPK1iLK+fbQPxNmi3bDpBTZwOwcnEQ_NHokQ7jr-_uxfw@mail.gmail.com>

HIbernate OGM 5.2 Beta1 is ready!

This version is compatible with Infinispan 9.1 and it makes it
possible to create caches when they are missing on the remote server

All the details in the blog post:
http://in.relation.to/2017/10/17/hibernate-ogm-5-2-Beta1-released/

Thanks,
Davide

From steve at hibernate.org  Tue Oct 17 10:42:19 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 17 Oct 2017 14:42:19 +0000
Subject: [hibernate-dev] Question..
In-Reply-To: <CAFDzhiSbgeUH1Cv3x7B6aTjd=3hO0GRfBT-HsZC=_aqPNCQHCA@mail.gmail.com>
References: <CAFdSV9sCuXkss+hwHtp8hXJnFY3NpYdf1Es-gRg+ttX3ObJMFQ@mail.gmail.com>
	<CAFDzhiTN8s1tWd1NnRzMRjjTzy_ucO4RFJ=nnOGpEXZSJBXS4g@mail.gmail.com>
	<CAFdSV9sVf1V2FAGLcYV1+AbcsQYWdKyj+gX8d_=6pPueebfg-Q@mail.gmail.com>
	<CAFDzhiT7a46YtOmHD1XsOJAHFiaoKsnL720F13VkS2ZDnYWhRg@mail.gmail.com>
	<CAFdSV9sEYQnU0t9pfKRitu4knaBtwnD02zdW3M1S_EP2cctBcw@mail.gmail.com>
	<CAFDzhiSbgeUH1Cv3x7B6aTjd=3hO0GRfBT-HsZC=_aqPNCQHCA@mail.gmail.com>
Message-ID: <CAFdSV9uTYDepDqaUK2QbBQmfKwCvZkzdK+dv-iTP_=Onf_kTsA@mail.gmail.com>

On Tue, Oct 17, 2017 at 12:55 AM Gail Badner <gbadner at redhat.com> wrote:

> >
> > WRT to the condition check, you suggest to "compare a primitive value in
> a
> > composite with the default for the primitive type  (e.g, comparing an int
> > value with 0 instead of null)".  That's not the best condition check.  I
> was
> > pointing out that we already have better handling for this for ids and
> > versions and that we ought to follow that paradigm, mainly on startup we
> > would instantiate an instance of said component and check the initial
> values
> > for its attributes.  E.g., consider:
> >
> > @Embeddable
> > public class MyEmbeddable {
> >     private int someInt;
> >     private int anotherInt = -1;
> > }
> >
> > Here, comparison of `#anotherInt` to 0 is not really correct.  The proper
> > comparison is to -1.  Again, this is exactly what we do for ids and
> > versions.
> >
> > So because your (A) and (B) check the same condition I was pointing out
> that
> > they actually are based on the incorrect condition check (0 versus -1),
> so
> > we should correct that assumption.  But even then we have  and further
> that
> > we should update the check and that we still have the different outcome
> > between (A) and (B) to decide between.
>
> I have already implemented something that does the check that you
> suggested, and I decided against it for a couple of reasons:
> 1) Any initialized values can be "real" values.
> 2) Suppose an instantiated embedded value includes something like:
>     Date created = new Date();
>     double random = Math.random();
> For 2), an embedded value would never be considered empty, and its
> values would always be persisted instead of null.
>

I'm sorry but I completely disagree here.

The Date one is interesting but ultimately can be handled somewhat easily.
I'll discuss why/how below.

And the "random" is completely a fabricated case I'm guessing.  Can you
show me a user reporting that as a real use case?  Regardless I think
you'll agree that this is very less-than-common use-case.  And anyway, it
too can be mitigated by the same handling I hinted at with Date.  Consider:

@Embeddable
class MyEmbeddable {
    Date created = new Date();
    double random = Math.random();
}

...

final MyEmbeddable e1 = new MyEmbeddable();
final MyEmbeddable e2 = new MyEmbeddable();
if ( theCompositeType.isEqual( e1, e2 ) ) {
    // we can recognize and leverage initial values
    ...
}
else {
    // we can't (your date/random examples)
    //    - this branch requires that either:
    //        - a strategy is supplied, or
    //        - creation of empty is disabled
    ...
}

These kind of decisions are all about covering common cases and then
allowing config or SPI to cover the less-common ones.  It boils down to
what you think is more common:

    double someNumber = -1;

or:

    double someNumber = Math.random();

Clearly initializing to a set (magic) number is far more common.

Also, I think you have to ask yourself about the likelihood that such a
component with its values initialized as such will ever be empty.  At least
for those specific values, I think it is HIGHLY unlikely.



> I think that it should be up to the `EmptyCompositeStrategy` to decide
> if a primitive that has the default value, or something like `created`
> or `random` should be ignored when determining if an embedded value is
> empty.
>

While I do not disagree that  EmptyCompositeStrategy is the most flexible
solution (which is why I included it as part of my "ideal" solution), the
majority of users do not want flexibility when that flexibility requires
writing some code to achieve it.  They want something that JustWorks.  Most
will be ok with configuration settings as well.  For the most part, it is
the "power users" who are going to implement such an SPI.

So while EmptyCompositeStrategy is certainly a good idea as part of a
complete solution, it is just that - a part.


I like what you describe above.
>
> Currently the property is named
> `hibernate.create_empty_composites.enabled`.
>
> Are you suggesting we rename the property in 6.0+?


For 5.x, I guess we'd have something like this to opt out:
>
> hibernate.create_empty_composites.enabled=strategy
> hibernate.create_empty_composites.enabled.com.acme.Person.name=false
>
> Should we also allow to disable in general, then opt-in for Person.name,
> as in:
>
> hibernate.create_empty_composites.enabled=false
> hibernate.create_empty_composites.enabled.com.acme.Person.name=true
> (this would fail like case (A) if the newly instantiated value has
> initialized values)
>
> Also, allow a strategy to be used for the opted-in value:
>
> hibernate.create_empty_composites.enabled=false
> hibernate.create_empty_composites.enabled.com.acme.Person.name=strategy
>


I would do what I described in the earlier email for 5.x.  This is a case
where the "long term solution" causes no API/SPI conflicts, and so is
perfectly fine for the short term as well.  And not only that, but the only
SPI change here is what you already propose - adding a new SPI extension
contract (EmptyCompositeStrategy).  In other words,  you are already
proposing the only thing that would normally be a blocker to doing
something in a maintenance branch - adding new settings is cake compared to
that.

The new settings have different names so there is no collision.  We'll
consider `hibernate.create_empty_composites.enabled` deprecated.  We will
use it when no `hibernate.create_empty_composites.enabled` has been
specified to determine the value for `hibernate.empty_composite_creation`
(just like we do for other deprecated settings).  For existing apps, the
old setting (`hibernate.create_empty_composites.enabled`) would continue to
have the same effect; these apps would not have the new settings,
so `hibernate.create_empty_composites.enabled` would define the default
for `hibernate.empty_composite_creation`.

BTW, I am thinking we may do a 5.3 specifically for the new JPA MR.  So we
could decide to do this work there rather than 5.2 - but honestly, adding
new settings is perfectly fine for 5.2 as already discussed.

From steve at hibernate.org  Tue Oct 17 11:04:57 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 17 Oct 2017 15:04:57 +0000
Subject: [hibernate-dev] Question..
In-Reply-To: <CAFdSV9uTYDepDqaUK2QbBQmfKwCvZkzdK+dv-iTP_=Onf_kTsA@mail.gmail.com>
References: <CAFdSV9sCuXkss+hwHtp8hXJnFY3NpYdf1Es-gRg+ttX3ObJMFQ@mail.gmail.com>
	<CAFDzhiTN8s1tWd1NnRzMRjjTzy_ucO4RFJ=nnOGpEXZSJBXS4g@mail.gmail.com>
	<CAFdSV9sVf1V2FAGLcYV1+AbcsQYWdKyj+gX8d_=6pPueebfg-Q@mail.gmail.com>
	<CAFDzhiT7a46YtOmHD1XsOJAHFiaoKsnL720F13VkS2ZDnYWhRg@mail.gmail.com>
	<CAFdSV9sEYQnU0t9pfKRitu4knaBtwnD02zdW3M1S_EP2cctBcw@mail.gmail.com>
	<CAFDzhiSbgeUH1Cv3x7B6aTjd=3hO0GRfBT-HsZC=_aqPNCQHCA@mail.gmail.com>
	<CAFdSV9uTYDepDqaUK2QbBQmfKwCvZkzdK+dv-iTP_=Onf_kTsA@mail.gmail.com>
Message-ID: <CAFdSV9vHrAR4HrdWLbopbC7YqOtTJPTRT-2h+G8z_A5K5aWfUg@mail.gmail.com>

My one concern with doing this in 5.x is that we'd almost certainly change
the signature of EmptyCompositeStrategy as we transition to 6.  6.0 has a
real encapsulation of the embeddable in addition to the embedded.  5.x only
really keeps the embedded (CompositeType).

Anotger aspect that we have not decided is whether this empty-creation
applies to the embeddable or the embedded.  The checks would all be
embeddable specific  - the state initialization is part of the embeddable
(the Class) so it would not change between embedded usages. We would have
to decide if it makes sense to allow different empty-creation decisions for
each embedded usage of that embeddable.

On Tue, Oct 17, 2017, 9:42 AM Steve Ebersole <steve at hibernate.org> wrote:

> On Tue, Oct 17, 2017 at 12:55 AM Gail Badner <gbadner at redhat.com> wrote:
>
>> >
>> > WRT to the condition check, you suggest to "compare a primitive value
>> in a
>> > composite with the default for the primitive type  (e.g, comparing an
>> int
>> > value with 0 instead of null)".  That's not the best condition check.
>> I was
>> > pointing out that we already have better handling for this for ids and
>> > versions and that we ought to follow that paradigm, mainly on startup we
>> > would instantiate an instance of said component and check the initial
>> values
>> > for its attributes.  E.g., consider:
>> >
>> > @Embeddable
>> > public class MyEmbeddable {
>> >     private int someInt;
>> >     private int anotherInt = -1;
>> > }
>> >
>> > Here, comparison of `#anotherInt` to 0 is not really correct.  The
>> proper
>> > comparison is to -1.  Again, this is exactly what we do for ids and
>> > versions.
>> >
>> > So because your (A) and (B) check the same condition I was pointing out
>> that
>> > they actually are based on the incorrect condition check (0 versus -1),
>> so
>> > we should correct that assumption.  But even then we have  and further
>> that
>> > we should update the check and that we still have the different outcome
>> > between (A) and (B) to decide between.
>>
>> I have already implemented something that does the check that you
>> suggested, and I decided against it for a couple of reasons:
>> 1) Any initialized values can be "real" values.
>> 2) Suppose an instantiated embedded value includes something like:
>>     Date created = new Date();
>>     double random = Math.random();
>> For 2), an embedded value would never be considered empty, and its
>> values would always be persisted instead of null.
>>
>
> I'm sorry but I completely disagree here.
>
> The Date one is interesting but ultimately can be handled somewhat
> easily.  I'll discuss why/how below.
>
> And the "random" is completely a fabricated case I'm guessing.  Can you
> show me a user reporting that as a real use case?  Regardless I think
> you'll agree that this is very less-than-common use-case.  And anyway, it
> too can be mitigated by the same handling I hinted at with Date.  Consider:
>
> @Embeddable
> class MyEmbeddable {
>     Date created = new Date();
>     double random = Math.random();
> }
>
> ...
>
> final MyEmbeddable e1 = new MyEmbeddable();
> final MyEmbeddable e2 = new MyEmbeddable();
> if ( theCompositeType.isEqual( e1, e2 ) ) {
>     // we can recognize and leverage initial values
>     ...
> }
> else {
>     // we can't (your date/random examples)
>     //    - this branch requires that either:
>     //        - a strategy is supplied, or
>     //        - creation of empty is disabled
>     ...
> }
>
> These kind of decisions are all about covering common cases and then
> allowing config or SPI to cover the less-common ones.  It boils down to
> what you think is more common:
>
>     double someNumber = -1;
>
> or:
>
>     double someNumber = Math.random();
>
> Clearly initializing to a set (magic) number is far more common.
>
> Also, I think you have to ask yourself about the likelihood that such a
> component with its values initialized as such will ever be empty.  At least
> for those specific values, I think it is HIGHLY unlikely.
>
>
>
>> I think that it should be up to the `EmptyCompositeStrategy` to decide
>> if a primitive that has the default value, or something like `created`
>> or `random` should be ignored when determining if an embedded value is
>> empty.
>>
>
> While I do not disagree that  EmptyCompositeStrategy is the most flexible
> solution (which is why I included it as part of my "ideal" solution), the
> majority of users do not want flexibility when that flexibility requires
> writing some code to achieve it.  They want something that JustWorks.  Most
> will be ok with configuration settings as well.  For the most part, it is
> the "power users" who are going to implement such an SPI.
>
> So while EmptyCompositeStrategy is certainly a good idea as part of a
> complete solution, it is just that - a part.
>
>
> I like what you describe above.
>>
>> Currently the property is named
>> `hibernate.create_empty_composites.enabled`.
>>
>> Are you suggesting we rename the property in 6.0+?
>
>
> For 5.x, I guess we'd have something like this to opt out:
>>
>> hibernate.create_empty_composites.enabled=strategy
>> hibernate.create_empty_composites.enabled.com.acme.Person.name=false
>>
>> Should we also allow to disable in general, then opt-in for Person.name,
>> as in:
>>
>> hibernate.create_empty_composites.enabled=false
>> hibernate.create_empty_composites.enabled.com.acme.Person.name=true
>> (this would fail like case (A) if the newly instantiated value has
>> initialized values)
>>
>> Also, allow a strategy to be used for the opted-in value:
>>
>> hibernate.create_empty_composites.enabled=false
>> hibernate.create_empty_composites.enabled.com.acme.Person.name=strategy
>>
>
>
> I would do what I described in the earlier email for 5.x.  This is a case
> where the "long term solution" causes no API/SPI conflicts, and so is
> perfectly fine for the short term as well.  And not only that, but the only
> SPI change here is what you already propose - adding a new SPI extension
> contract (EmptyCompositeStrategy).  In other words,  you are already
> proposing the only thing that would normally be a blocker to doing
> something in a maintenance branch - adding new settings is cake compared to
> that.
>
> The new settings have different names so there is no collision.  We'll
> consider `hibernate.create_empty_composites.enabled` deprecated.  We will
> use it when no `hibernate.create_empty_composites.enabled` has been
> specified to determine the value for `hibernate.empty_composite_creation`
> (just like we do for other deprecated settings).  For existing apps, the
> old setting (`hibernate.create_empty_composites.enabled`) would continue to
> have the same effect; these apps would not have the new settings,
> so `hibernate.create_empty_composites.enabled` would define the default
> for `hibernate.empty_composite_creation`.
>
> BTW, I am thinking we may do a 5.3 specifically for the new JPA MR.  So we
> could decide to do this work there rather than 5.2 - but honestly, adding
> new settings is perfectly fine for 5.2 as already discussed.
>
>
>

From sanne at hibernate.org  Thu Oct 19 06:10:32 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 19 Oct 2017 11:10:32 +0100
Subject: [hibernate-dev] <join ... fetch="select"/>
In-Reply-To: <CAFdSV9tp1FLd=2GxoCBbdZwaHoWOvJZOgAe6nF6DcVJfK_bAqw@mail.gmail.com>
References: <CAFdSV9tJmSt_PCYuuRCjY2BuimV=0c33tYuKg6EcmzoBDaCUNw@mail.gmail.com>
	<CAFm4XO3e4N8hOTNnxOtw8tFSLFQ688L6g97f7T1RQi5Akj0Afg@mail.gmail.com>
	<CAFdSV9tp1FLd=2GxoCBbdZwaHoWOvJZOgAe6nF6DcVJfK_bAqw@mail.gmail.com>
Message-ID: <CAFm4XO0zX_-3Ha049wo_E9m5R6B7EZrzK=39BOz8zV+EYsHxRw@mail.gmail.com>

On 15 October 2017 at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
> It sounds like you may be confused - like you are talking about
> associations.  I am talking about "secondary tables".

Right, I was confused. Sorry about that.

So indeed I never found myself needing this. I guess one might have a
reason among the same lines of reducing cardinality in a single SQL
statement (similar to my case with associations) but that seems far
fetched, and there are alternative options to mitigate the problem:
that problem is speficially with having "too many" joins and needing
to trim some one could trim the joins triggered by associations first.
People having an excess of secondary tables have other problems to fix
first :)

+1 to simplify this

Thanks,
Sanne

>
> On Sat, Oct 14, 2017 at 8:07 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> I remember finding secondary fetch options very useful when there's
>> good chances that the second fetch is prevented by 2nd level caching.
>>
>> Even when 2nd level caching wasn't an option, we had plenty of very
>> complex objects so loading one would imly many joins; this would
>> reduce the number of joins per statement to something the RDBMS would
>> handle more reasonably in terms of performance. The performance
>> penalty for having many joins was both a metter of complexity but also
>> of cardinality of the size of results.
>>
>> Both these cases were "joined" though at entity level, just tuning the
>> fetch option, so maybe it's not related to your question?
>>
>> Thanks,
>> Sanne
>>
>>
>>
>> On 13 October 2017 at 14:31, Steve Ebersole <steve at hibernate.org> wrote:
>> > Hibernate mappings define a feature to allow a secondary table
>> > (`<join/>`
>> > in hbm terms) to be defined as not joined via : `<join ...
>> > fetch="select"/>`.  This actually creates a subsequent select to load
>> > the
>> > data from the secondary table.
>> >
>> > I am trying to figure out how to best incorporate this into the paradigm
>> > for JDBC statement execution in 6.0.  My first thought was "do we need
>> > to
>> > keep this?".  Does anyone know of a real usage of this feature?  In
>> > theory
>> > it could be useful to some degree along with bytecode enhanced
>> > interception
>> > for lazy-loading individual attributes.  But even then, I'm not sure how
>> > practically useful that is.
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

From andrea at hibernate.org  Thu Oct 19 07:26:14 2017
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 19 Oct 2017 12:26:14 +0100
Subject: [hibernate-dev] Starting 5.2.12 release
Message-ID: <CAL00eSRSRvyogcV4bdnAJJv6KUDwE1XLuRaR2TC46w9uhHz6Bg@mail.gmail.com>

Please do not push anything to master branch.

Thanks,

Andrea

From guillaume.smet at hibernate.org  Thu Oct 19 12:17:50 2017
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Thu, 19 Oct 2017 18:17:50 +0200
Subject: [hibernate-dev] Hibernate Validator 6.0.3.Final released
Message-ID: <CALt0+o-QS5wJmzXsTzx-dpQwzuFgOu6WZ_OCvx4qUybjczdvaA@mail.gmail.com>

Hi,

We just released Hibernate Validator 6.0.3.Final. It fixes a few
issues reported by our users, adds a new SPI for providing a custom
ScriptEvaluatorFactory, introduces a new @CodePointLength constraint
and is faster than ever.

It is a recommended upgrade for everyone already using 6.0.x.

For more information, read the announcement here:
http://in.relation.to/2017/10/19/hibernate-validator-603-final-out/ .

We also released maintenance releases for the 5.3 and 5.4 branches but
we recommend that all users should upgrade to 6.0 now.

Have a nice day!

-- 
Guillaume

From andrea at hibernate.org  Thu Oct 19 19:01:39 2017
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 20 Oct 2017 00:01:39 +0100
Subject: [hibernate-dev] Hibernate ORM 5.2.12.Final has been released
Message-ID: <CAL00eSR_NPuuisKeVOYE3Lv5c-W=Y0SjW5pqxzhN_MR8Z9f8Sg@mail.gmail.com>

For details:

http://in.relation.to/2017/10/19/hibernate-orm-5212-final-release

From gbadner at redhat.com  Fri Oct 20 15:56:29 2017
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 20 Oct 2017 12:56:29 -0700
Subject: [hibernate-dev] Question..
In-Reply-To: <CAFdSV9vHrAR4HrdWLbopbC7YqOtTJPTRT-2h+G8z_A5K5aWfUg@mail.gmail.com>
References: <CAFdSV9sCuXkss+hwHtp8hXJnFY3NpYdf1Es-gRg+ttX3ObJMFQ@mail.gmail.com>
	<CAFDzhiTN8s1tWd1NnRzMRjjTzy_ucO4RFJ=nnOGpEXZSJBXS4g@mail.gmail.com>
	<CAFdSV9sVf1V2FAGLcYV1+AbcsQYWdKyj+gX8d_=6pPueebfg-Q@mail.gmail.com>
	<CAFDzhiT7a46YtOmHD1XsOJAHFiaoKsnL720F13VkS2ZDnYWhRg@mail.gmail.com>
	<CAFdSV9sEYQnU0t9pfKRitu4knaBtwnD02zdW3M1S_EP2cctBcw@mail.gmail.com>
	<CAFDzhiSbgeUH1Cv3x7B6aTjd=3hO0GRfBT-HsZC=_aqPNCQHCA@mail.gmail.com>
	<CAFdSV9uTYDepDqaUK2QbBQmfKwCvZkzdK+dv-iTP_=Onf_kTsA@mail.gmail.com>
	<CAFdSV9vHrAR4HrdWLbopbC7YqOtTJPTRT-2h+G8z_A5K5aWfUg@mail.gmail.com>
Message-ID: <CAFDzhiRPuK+2kUfpXJErpx9T_P8nnmyBfSF4nFZKtzfBGOyzSQ@mail.gmail.com>

Won't there be many breaking changes moving to 6.0 anyhow? I can see
keeping the signatures the same in 5.x, but I, personally, am not as
concerned about keeping them the same moving to 6.0. I would certainly
try to make the migration as painless as possible.

I'm on the fence about whether empty-creation configuration should
apply per embedded vs embeddable.

I'm going to create a gist to summarize what we've discussed, and we
can discuss further there.

On Tue, Oct 17, 2017 at 8:04 AM, Steve Ebersole <steve at hibernate.org> wrote:
> My one concern with doing this in 5.x is that we'd almost certainly change
> the signature of EmptyCompositeStrategy as we transition to 6.  6.0 has a
> real encapsulation of the embeddable in addition to the embedded.  5.x only
> really keeps the embedded (CompositeType).
>
> Anotger aspect that we have not decided is whether this empty-creation
> applies to the embeddable or the embedded.  The checks would all be
> embeddable specific  - the state initialization is part of the embeddable
> (the Class) so it would not change between embedded usages. We would have to
> decide if it makes sense to allow different empty-creation decisions for
> each embedded usage of that embeddable.
>
>
> On Tue, Oct 17, 2017, 9:42 AM Steve Ebersole <steve at hibernate.org> wrote:
>>
>> On Tue, Oct 17, 2017 at 12:55 AM Gail Badner <gbadner at redhat.com> wrote:
>>>
>>> >
>>> > WRT to the condition check, you suggest to "compare a primitive value
>>> > in a
>>> > composite with the default for the primitive type  (e.g, comparing an
>>> > int
>>> > value with 0 instead of null)".  That's not the best condition check.
>>> > I was
>>> > pointing out that we already have better handling for this for ids and
>>> > versions and that we ought to follow that paradigm, mainly on startup
>>> > we
>>> > would instantiate an instance of said component and check the initial
>>> > values
>>> > for its attributes.  E.g., consider:
>>> >
>>> > @Embeddable
>>> > public class MyEmbeddable {
>>> >     private int someInt;
>>> >     private int anotherInt = -1;
>>> > }
>>> >
>>> > Here, comparison of `#anotherInt` to 0 is not really correct.  The
>>> > proper
>>> > comparison is to -1.  Again, this is exactly what we do for ids and
>>> > versions.
>>> >
>>> > So because your (A) and (B) check the same condition I was pointing out
>>> > that
>>> > they actually are based on the incorrect condition check (0 versus -1),
>>> > so
>>> > we should correct that assumption.  But even then we have  and further
>>> > that
>>> > we should update the check and that we still have the different outcome
>>> > between (A) and (B) to decide between.
>>>
>>> I have already implemented something that does the check that you
>>> suggested, and I decided against it for a couple of reasons:
>>> 1) Any initialized values can be "real" values.
>>> 2) Suppose an instantiated embedded value includes something like:
>>>     Date created = new Date();
>>>     double random = Math.random();
>>> For 2), an embedded value would never be considered empty, and its
>>> values would always be persisted instead of null.
>>
>>
>> I'm sorry but I completely disagree here.
>>
>> The Date one is interesting but ultimately can be handled somewhat easily.
>> I'll discuss why/how below.
>>
>> And the "random" is completely a fabricated case I'm guessing.  Can you
>> show me a user reporting that as a real use case?  Regardless I think you'll
>> agree that this is very less-than-common use-case.  And anyway, it too can
>> be mitigated by the same handling I hinted at with Date.  Consider:
>>
>> @Embeddable
>> class MyEmbeddable {
>>     Date created = new Date();
>>     double random = Math.random();
>> }
>>
>> ...
>>
>> final MyEmbeddable e1 = new MyEmbeddable();
>> final MyEmbeddable e2 = new MyEmbeddable();
>> if ( theCompositeType.isEqual( e1, e2 ) ) {
>>     // we can recognize and leverage initial values
>>     ...
>> }
>> else {
>>     // we can't (your date/random examples)
>>     //    - this branch requires that either:
>>     //        - a strategy is supplied, or
>>     //        - creation of empty is disabled
>>     ...
>> }
>>
>> These kind of decisions are all about covering common cases and then
>> allowing config or SPI to cover the less-common ones.  It boils down to what
>> you think is more common:
>>
>>     double someNumber = -1;
>>
>> or:
>>
>>     double someNumber = Math.random();
>>
>> Clearly initializing to a set (magic) number is far more common.
>>
>> Also, I think you have to ask yourself about the likelihood that such a
>> component with its values initialized as such will ever be empty.  At least
>> for those specific values, I think it is HIGHLY unlikely.
>>
>>
>>>
>>> I think that it should be up to the `EmptyCompositeStrategy` to decide
>>> if a primitive that has the default value, or something like `created`
>>> or `random` should be ignored when determining if an embedded value is
>>> empty.
>>
>>
>> While I do not disagree that  EmptyCompositeStrategy is the most flexible
>> solution (which is why I included it as part of my "ideal" solution), the
>> majority of users do not want flexibility when that flexibility requires
>> writing some code to achieve it.  They want something that JustWorks.  Most
>> will be ok with configuration settings as well.  For the most part, it is
>> the "power users" who are going to implement such an SPI.
>>
>> So while EmptyCompositeStrategy is certainly a good idea as part of a
>> complete solution, it is just that - a part.
>>
>>
>>> I like what you describe above.
>>>
>>> Currently the property is named
>>> `hibernate.create_empty_composites.enabled`.
>>>
>>> Are you suggesting we rename the property in 6.0+?
>>
>>
>>> For 5.x, I guess we'd have something like this to opt out:
>>>
>>> hibernate.create_empty_composites.enabled=strategy
>>> hibernate.create_empty_composites.enabled.com.acme.Person.name=false
>>>
>>> Should we also allow to disable in general, then opt-in for Person.name,
>>> as in:
>>>
>>> hibernate.create_empty_composites.enabled=false
>>> hibernate.create_empty_composites.enabled.com.acme.Person.name=true
>>> (this would fail like case (A) if the newly instantiated value has
>>> initialized values)
>>>
>>> Also, allow a strategy to be used for the opted-in value:
>>>
>>> hibernate.create_empty_composites.enabled=false
>>> hibernate.create_empty_composites.enabled.com.acme.Person.name=strategy
>>
>>
>>
>> I would do what I described in the earlier email for 5.x.  This is a case
>> where the "long term solution" causes no API/SPI conflicts, and so is
>> perfectly fine for the short term as well.  And not only that, but the only
>> SPI change here is what you already propose - adding a new SPI extension
>> contract (EmptyCompositeStrategy).  In other words,  you are already
>> proposing the only thing that would normally be a blocker to doing something
>> in a maintenance branch - adding new settings is cake compared to that.
>>
>> The new settings have different names so there is no collision.  We'll
>> consider `hibernate.create_empty_composites.enabled` deprecated.  We will
>> use it when no `hibernate.create_empty_composites.enabled` has been
>> specified to determine the value for `hibernate.empty_composite_creation`
>> (just like we do for other deprecated settings).  For existing apps, the old
>> setting (`hibernate.create_empty_composites.enabled`) would continue to have
>> the same effect; these apps would not have the new settings, so
>> `hibernate.create_empty_composites.enabled` would define the default for
>> `hibernate.empty_composite_creation`.
>>
>> BTW, I am thinking we may do a 5.3 specifically for the new JPA MR.  So we
>> could decide to do this work there rather than 5.2 - but honestly, adding
>> new settings is perfectly fine for 5.2 as already discussed.
>>
>>

From gunnar at hibernate.org  Tue Oct 24 05:40:12 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 24 Oct 2017 11:40:12 +0200
Subject: [hibernate-dev] Programmatic entity mapping API
In-Reply-To: <CADGJaX-94Zypr_HxJkEbirNuX7p2PTbGwLCOMUxzNOQdPSjw+A@mail.gmail.com>
References: <CADGJaX-94Zypr_HxJkEbirNuX7p2PTbGwLCOMUxzNOQdPSjw+A@mail.gmail.com>
Message-ID: <CADGJaX9XGaRLCKZfcmKWaA+4k5bLY2Q+mXXfnkk4wBUJCxDWOQ@mail.gmail.com>

Anyone with thoughts on this? To elaborate, here's what I have in mind:

    EntityMapping mapping = session.addEntityMapping();
    mapping.entity( Person.class )
        .table( "PERSONS" )
        .property( "personId" )
            .id()
                .strategy( Strategy.IDENTITY )
        .property( "phoneNumbers" )
            .oneToMany()
                .mappedBy( "person" )
        .property( "favouriteColor" )
            .converter( ColorConverter.class );

I'm curious whether others think that'd be useful or not.

Vlad, perhaps you have any insights from the field?

Cheers,

--Gunnar




2017-10-13 21:21 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> Hi all,
>
> This has crossed my mind for a few times: should we provide a programmatic
> API in Hibernate ORM for mapping entities, as an alternative mapping
> definition source to annotations and XML? I.e. something similar to the
> programmatic mapping APIs we have in Hibernate Validator and Search.
>
> It'd probably be a fair bit of work (though giving lots of fun with API
> design), but I can see how it could be appealing to folks preferring
> API-style ways of configuring their stack, which seems more and more en
> vogue these days. Using lambda expressions would be attractive especially
> when it comes to plugging in custom behaviours, e.g. for value generators.
>
> Any thoughts?
>
> --Gunnar
>
>

From alessiostalla at gmail.com  Tue Oct 24 06:30:13 2017
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Tue, 24 Oct 2017 12:30:13 +0200
Subject: [hibernate-dev] Programmatic entity mapping API
In-Reply-To: <CADGJaX9XGaRLCKZfcmKWaA+4k5bLY2Q+mXXfnkk4wBUJCxDWOQ@mail.gmail.com>
References: <CADGJaX-94Zypr_HxJkEbirNuX7p2PTbGwLCOMUxzNOQdPSjw+A@mail.gmail.com>
	<CADGJaX9XGaRLCKZfcmKWaA+4k5bLY2Q+mXXfnkk4wBUJCxDWOQ@mail.gmail.com>
Message-ID: <CAL2Kp+imFdxVS7iCR8O776M+VD4Wf5ynaTsTgJ0_yNQQ+eGy-w@mail.gmail.com>

That would be great for framework developers as well.

Il 24 ott 2017 12:01, "Gunnar Morling" <gunnar at hibernate.org> ha scritto:

> Anyone with thoughts on this? To elaborate, here's what I have in mind:
>
>     EntityMapping mapping = session.addEntityMapping();
>     mapping.entity( Person.class )
>         .table( "PERSONS" )
>         .property( "personId" )
>             .id()
>                 .strategy( Strategy.IDENTITY )
>         .property( "phoneNumbers" )
>             .oneToMany()
>                 .mappedBy( "person" )
>         .property( "favouriteColor" )
>             .converter( ColorConverter.class );
>
> I'm curious whether others think that'd be useful or not.
>
> Vlad, perhaps you have any insights from the field?
>
> Cheers,
>
> --Gunnar
>
>
>
>
> 2017-10-13 21:21 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>
> > Hi all,
> >
> > This has crossed my mind for a few times: should we provide a
> programmatic
> > API in Hibernate ORM for mapping entities, as an alternative mapping
> > definition source to annotations and XML? I.e. something similar to the
> > programmatic mapping APIs we have in Hibernate Validator and Search.
> >
> > It'd probably be a fair bit of work (though giving lots of fun with API
> > design), but I can see how it could be appealing to folks preferring
> > API-style ways of configuring their stack, which seems more and more en
> > vogue these days. Using lambda expressions would be attractive especially
> > when it comes to plugging in custom behaviours, e.g. for value
> generators.
> >
> > Any thoughts?
> >
> > --Gunnar
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Oct 24 09:08:11 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 24 Oct 2017 13:08:11 +0000
Subject: [hibernate-dev] Programmatic entity mapping API
In-Reply-To: <CAL2Kp+imFdxVS7iCR8O776M+VD4Wf5ynaTsTgJ0_yNQQ+eGy-w@mail.gmail.com>
References: <CADGJaX-94Zypr_HxJkEbirNuX7p2PTbGwLCOMUxzNOQdPSjw+A@mail.gmail.com>
	<CADGJaX9XGaRLCKZfcmKWaA+4k5bLY2Q+mXXfnkk4wBUJCxDWOQ@mail.gmail.com>
	<CAL2Kp+imFdxVS7iCR8O776M+VD4Wf5ynaTsTgJ0_yNQQ+eGy-w@mail.gmail.com>
Message-ID: <CAFdSV9v7xgpr=bAKaw90E64wkB0X-ynARcUHsrkdrPJ-O7rDEA@mail.gmail.com>

Of course you pick the easy case to illustrate :)  A single entity with
nothing but basic attributes or self-referential associations is going to
be relatively simple.  The trickier stuff is adding 2 entities with
association between them, "property-ref" FKs, etc.  Then your fluent API is
not so fluent.

Overall I can see the utility of this but:

   1. I'm not sure your intention here with exposing this from Session, but
   a huge -1 to in any way allowing this even after the SessionFactory is
   built.
   2. Related to this, I can definitely see exposing this to build the
   boot-time model as in the org.hibernate.mapping package - but not so much
   the runtime model.  Ultimately as we move to Jandex for describing the
   boot-time model specifically I can see this API building those structures.
   3. Not a high priority for me.  In fact between 6 and then the Jandex
   work I mentioned, I do not foresee having time to work on this


On Tue, Oct 24, 2017 at 6:36 AM Alessio Stalla <alessiostalla at gmail.com>
wrote:

> That would be great for framework developers as well.
>
> Il 24 ott 2017 12:01, "Gunnar Morling" <gunnar at hibernate.org> ha scritto:
>
> > Anyone with thoughts on this? To elaborate, here's what I have in mind:
> >
> >     EntityMapping mapping = session.addEntityMapping();
> >     mapping.entity( Person.class )
> >         .table( "PERSONS" )
> >         .property( "personId" )
> >             .id()
> >                 .strategy( Strategy.IDENTITY )
> >         .property( "phoneNumbers" )
> >             .oneToMany()
> >                 .mappedBy( "person" )
> >         .property( "favouriteColor" )
> >             .converter( ColorConverter.class );
> >
> > I'm curious whether others think that'd be useful or not.
> >
> > Vlad, perhaps you have any insights from the field?
> >
> > Cheers,
> >
> > --Gunnar
> >
> >
> >
> >
> > 2017-10-13 21:21 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
> >
> > > Hi all,
> > >
> > > This has crossed my mind for a few times: should we provide a
> > programmatic
> > > API in Hibernate ORM for mapping entities, as an alternative mapping
> > > definition source to annotations and XML? I.e. something similar to the
> > > programmatic mapping APIs we have in Hibernate Validator and Search.
> > >
> > > It'd probably be a fair bit of work (though giving lots of fun with API
> > > design), but I can see how it could be appealing to folks preferring
> > > API-style ways of configuring their stack, which seems more and more en
> > > vogue these days. Using lambda expressions would be attractive
> especially
> > > when it comes to plugging in custom behaviours, e.g. for value
> > generators.
> > >
> > > Any thoughts?
> > >
> > > --Gunnar
> > >
> > >
> > _______________________________________________
> > 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 Oct 24 09:38:05 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 24 Oct 2017 15:38:05 +0200
Subject: [hibernate-dev] Programmatic entity mapping API
In-Reply-To: <CAFdSV9v7xgpr=bAKaw90E64wkB0X-ynARcUHsrkdrPJ-O7rDEA@mail.gmail.com>
References: <CADGJaX-94Zypr_HxJkEbirNuX7p2PTbGwLCOMUxzNOQdPSjw+A@mail.gmail.com>
	<CADGJaX9XGaRLCKZfcmKWaA+4k5bLY2Q+mXXfnkk4wBUJCxDWOQ@mail.gmail.com>
	<CAL2Kp+imFdxVS7iCR8O776M+VD4Wf5ynaTsTgJ0_yNQQ+eGy-w@mail.gmail.com>
	<CAFdSV9v7xgpr=bAKaw90E64wkB0X-ynARcUHsrkdrPJ-O7rDEA@mail.gmail.com>
Message-ID: <CADGJaX_eX-nKMb2TinHYg=fKKqAOd1QNMLmqq=W4KrCikZOg5A@mail.gmail.com>

2017-10-24 15:08 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Of course you pick the easy case to illustrate :)  A single entity with
> nothing but basic attributes or self-referential associations is going to
> be relatively simple.  The trickier stuff is adding 2 entities with
> association between them, "property-ref" FKs, etc.  Then your fluent API is
> not so fluent.
>

Yeah, I just made up something quickly to ignite the discussion. I also
expect it to be more complex when done completely.


>
> Overall I can see the utility of this but:
>
>    1. I'm not sure your intention here with exposing this from Session,
>    but a huge -1 to in any way allowing this even after the SessionFactory is
>    built.
>
> Ah, I knew I'd get that wrong ;)

I just meant to illustrate there's *some* entry point into the API, full
ack it should be on the SF/EMF level of course.

>
>    1. Related to this, I can definitely see exposing this to build the
>    boot-time model as in the org.hibernate.mapping package - but not so much
>    the runtime model.  Ultimately as we move to Jandex for describing the
>    boot-time model specifically I can see this API building those structures.
>    2. Not a high priority for me.  In fact between 6 and then the Jandex
>    work I mentioned, I do not foresee having time to work on this
>
> Sure. But it's great to know that you'd find it useful and can imagine
adding it. Thanks!


>
> On Tue, Oct 24, 2017 at 6:36 AM Alessio Stalla <alessiostalla at gmail.com>
> wrote:
>
>> That would be great for framework developers as well.
>>
>> Il 24 ott 2017 12:01, "Gunnar Morling" <gunnar at hibernate.org> ha scritto:
>>
>> > Anyone with thoughts on this? To elaborate, here's what I have in mind:
>> >
>> >     EntityMapping mapping = session.addEntityMapping();
>> >     mapping.entity( Person.class )
>> >         .table( "PERSONS" )
>> >         .property( "personId" )
>> >             .id()
>> >                 .strategy( Strategy.IDENTITY )
>> >         .property( "phoneNumbers" )
>> >             .oneToMany()
>> >                 .mappedBy( "person" )
>> >         .property( "favouriteColor" )
>> >             .converter( ColorConverter.class );
>> >
>> > I'm curious whether others think that'd be useful or not.
>> >
>> > Vlad, perhaps you have any insights from the field?
>> >
>> > Cheers,
>> >
>> > --Gunnar
>> >
>> >
>> >
>> >
>> > 2017-10-13 21:21 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>> >
>> > > Hi all,
>> > >
>> > > This has crossed my mind for a few times: should we provide a
>> > programmatic
>> > > API in Hibernate ORM for mapping entities, as an alternative mapping
>> > > definition source to annotations and XML? I.e. something similar to
>> the
>> > > programmatic mapping APIs we have in Hibernate Validator and Search.
>> > >
>> > > It'd probably be a fair bit of work (though giving lots of fun with
>> API
>> > > design), but I can see how it could be appealing to folks preferring
>> > > API-style ways of configuring their stack, which seems more and more
>> en
>> > > vogue these days. Using lambda expressions would be attractive
>> especially
>> > > when it comes to plugging in custom behaviours, e.g. for value
>> > generators.
>> > >
>> > > Any thoughts?
>> > >
>> > > --Gunnar
>> > >
>> > >
>> > _______________________________________________
>> > 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 guillaume.smet at hibernate.org  Tue Oct 24 10:07:23 2017
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Tue, 24 Oct 2017 16:07:23 +0200
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o8yeQjKRTJTTKqQOZH25qyUJ5FPzE3WJkikxRY=4xHciw@mail.gmail.com>

Hi!

Here are the minutes of this week's NoORM IRC meeting:
16:05 < jbott> Meeting ended Tue Oct 24 14:05:39 2017 UTC.
Information about MeetBot at http://wiki.debian.org/MeetBot . (v
0.1.4)
16:05 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-10-24-13.00.html
16:05 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-10-24-13.00.txt
16:05 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-10-24-13.00.log.html

Have a nice day.

-- 
Guillaume

From steve at hibernate.org  Tue Oct 24 10:21:29 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 24 Oct 2017 14:21:29 +0000
Subject: [hibernate-dev] Programmatic entity mapping API
In-Reply-To: <CADGJaX_eX-nKMb2TinHYg=fKKqAOd1QNMLmqq=W4KrCikZOg5A@mail.gmail.com>
References: <CADGJaX-94Zypr_HxJkEbirNuX7p2PTbGwLCOMUxzNOQdPSjw+A@mail.gmail.com>
	<CADGJaX9XGaRLCKZfcmKWaA+4k5bLY2Q+mXXfnkk4wBUJCxDWOQ@mail.gmail.com>
	<CAL2Kp+imFdxVS7iCR8O776M+VD4Wf5ynaTsTgJ0_yNQQ+eGy-w@mail.gmail.com>
	<CAFdSV9v7xgpr=bAKaw90E64wkB0X-ynARcUHsrkdrPJ-O7rDEA@mail.gmail.com>
	<CADGJaX_eX-nKMb2TinHYg=fKKqAOd1QNMLmqq=W4KrCikZOg5A@mail.gmail.com>
Message-ID: <CAFdSV9s1MHYjLi-cx31W8x5dzer90a-uWfd-h5XMt79QPh1biw@mail.gmail.com>

On Tue, Oct 24, 2017 at 8:38 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Sure. But it's great to know that you'd find it useful and can imagine
> adding it. Thanks!
>

In fact we have similar requirement in ORM itself for hibernate-envers,
 but again the initial expectation is supporting this at the boot-model
level, not the runtime-model level.  Ultimately I'd like to use Jandex as
the thing that is built - for many reasons.

From steve at hibernate.org  Tue Oct 24 14:34:05 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 24 Oct 2017 18:34:05 +0000
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
Message-ID: <CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>

I've signed up for a "test drive" account on Atlassian's Stride server.
Stride is their replacement for HipChat.

---------- Forwarded message ---------
From: Stride by Atlassian <help at stride.com>
Date: Tue, Oct 24, 2017, 1:32 PM
Subject: You're on the Stride waitlist!
To: <steve at hibernate.org>



[image: Stride by Atlassian]

Nice! You're on the list!
[image: Stride waitlist]
Thanks for your interest in Stride!
What is Stride?
Stride is a complete communication solution that empowers teams to talk
less and do more. Stride provides teams with group messaging, video
meetings & built-in collaboration tools. We are rolling Stride out during
our Early Access Program and very excited for you and your team to try it!
When will I get on Stride?
When it's your turn, we'll reach out again to get your team started. You'll
be able to create a new team or upgrade an existing HipChat team. Get
answers to most of your questions on our FAQs
<https://confluence.atlassian.com/display/STRIDE/Stride+documentation?&utm_source=prefinery&utm_medium=email&utm_campaign=waitlist-confirmation>
.
Thanks for your support! We can't wait to see your team hit its stride.
Cheers,
The Stride Team

Copyright 2017 Atlassian Pty Ltd. All rights reserved. We are located at 341
George Street, Sydney, NSW, 2000, Australia
<https://maps.google.com/?q=341+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g>


Don't want to receive amazing emails from us? Unsubscribe
<https://i.prefinery.com/projects/ykmtf4f9/users/be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe>

From sanne at hibernate.org  Wed Oct 25 09:32:35 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 25 Oct 2017 14:32:35 +0100
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
	operations?
Message-ID: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>

Hi Steve,

do you think it would be sensible for me to explore introducing some
kind of synchronization lookup method on
org.hibernate.resource.transaction.spi.SynchronizationRegistry ?

Today it only exposes a `registerSynchronization` method, which we use
extensively, but then we also have quite some complexity in the Search
code caused by the fact that we can't look the synchronizations up in
a later phase.
Essentially our Synchronization is stateful and we need to update it later.

I'd love to propose a change for ORM6 so allow registering such things
under some kind of id (a string?) so that one can look them back.

current SPI:

    public void registerSynchronization(Synchronization synchronization)

temptative proposal (didn't try it yet..):

   public void registerSynchronization(String id, Synchronization
synchronization);

   public void Synchronization getSynchronization(String id);


does it sound reasonable in principle?

This would imply other users should make up an id unique for their use
case. Alternatively I could live with a Class used as an id, or we
could have the new methods in addition to the existing method for
people not interested in looking things up.

thanks,
Sanne

From guillaume.smet at hibernate.org  Wed Oct 25 10:29:43 2017
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Wed, 25 Oct 2017 16:29:43 +0200
Subject: [hibernate-dev] Hibernate Validator 6.0.4.Final released
Message-ID: <CALt0+o-3ZztrLYf7rOwZSU6gh2uferdmEzKs51Nd4Pc53zEFsg@mail.gmail.com>

Hi,

We just released Hibernate Validator 6.0.4.Final.

The main point of this release is to provide a patch file for WildFly
11 Final but we also included some nice performance improvements and
bugfixes.

It is a recommended upgrade for everyone already using 6.0.x.

For more information, read the announcement here:
http://in.relation.to/2017/10/25/hibernate-validator-604-final-out/

Have a nice day!

--
Guillaume

From jonathan.halliday at redhat.com  Wed Oct 25 10:37:20 2017
From: jonathan.halliday at redhat.com (Jonathan Halliday)
Date: Wed, 25 Oct 2017 15:37:20 +0100
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
 operations?
In-Reply-To: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
Message-ID: <24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>


The javax.transaction version of that interface already functions as a 
per-transaction hashmap, with put/get operations available. If you can 
use it directly, then just pick a suitable lookup key - FQCN or even the 
sync impl .class itself, since the key is Object type. If not then at 
least retain the method signatures and just delegate them down through 
the spi.

https://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html

Jonathan.

On 25/10/17 14:32, Sanne Grinovero wrote:
> Hi Steve,
> 
> do you think it would be sensible for me to explore introducing some
> kind of synchronization lookup method on
> org.hibernate.resource.transaction.spi.SynchronizationRegistry ?
> 
> Today it only exposes a `registerSynchronization` method, which we use
> extensively, but then we also have quite some complexity in the Search
> code caused by the fact that we can't look the synchronizations up in
> a later phase.
> Essentially our Synchronization is stateful and we need to update it later.
> 
> I'd love to propose a change for ORM6 so allow registering such things
> under some kind of id (a string?) so that one can look them back.
> 
> current SPI:
> 
>      public void registerSynchronization(Synchronization synchronization)
> 
> temptative proposal (didn't try it yet..):
> 
>     public void registerSynchronization(String id, Synchronization
> synchronization);
> 
>     public void Synchronization getSynchronization(String id);
> 
> 
> does it sound reasonable in principle?
> 
> This would imply other users should make up an id unique for their use
> case. Alternatively I could live with a Class used as an id, or we
> could have the new methods in addition to the existing method for
> people not interested in looking things up.
> 
> thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From rvansa at redhat.com  Wed Oct 25 10:38:20 2017
From: rvansa at redhat.com (Radim Vansa)
Date: Wed, 25 Oct 2017 16:38:20 +0200
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
 operations?
In-Reply-To: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
Message-ID: <d330639c-dfa8-b111-9363-30c4579c7b3b@redhat.com>

I had the same issue in 2LC and we ended up passing 
CacheTransactionContext to all SPI calls (for ORM6). In case of 
Infinispan impl this will be a stateful object, probably implementing 
the Synchronization iface as well (to reduce object count), and 2LC will 
store all the beforeCompletion/afterCompletion work in there.

Currently we can workaround by registering multiple synchronizations but 
as the RPCs can be done asynchronously doing it in parallel will reduce 
the latency.

The only drawback is that JTA's suspend and resume cannot be honored 
properly but I've been told that the rest of ORM is not working 
perfectly either when you try to run two concurrent transactions using 
single Session.

Radim

On 10/25/2017 03:32 PM, Sanne Grinovero wrote:
> Hi Steve,
>
> do you think it would be sensible for me to explore introducing some
> kind of synchronization lookup method on
> org.hibernate.resource.transaction.spi.SynchronizationRegistry ?
>
> Today it only exposes a `registerSynchronization` method, which we use
> extensively, but then we also have quite some complexity in the Search
> code caused by the fact that we can't look the synchronizations up in
> a later phase.
> Essentially our Synchronization is stateful and we need to update it later.
>
> I'd love to propose a change for ORM6 so allow registering such things
> under some kind of id (a string?) so that one can look them back.
>
> current SPI:
>
>      public void registerSynchronization(Synchronization synchronization)
>
> temptative proposal (didn't try it yet..):
>
>     public void registerSynchronization(String id, Synchronization
> synchronization);
>
>     public void Synchronization getSynchronization(String id);
>
>
> does it sound reasonable in principle?
>
> This would imply other users should make up an id unique for their use
> case. Alternatively I could live with a Class used as an id, or we
> could have the new methods in addition to the existing method for
> people not interested in looking things up.
>
> thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From sanne at hibernate.org  Wed Oct 25 11:02:29 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 25 Oct 2017 16:02:29 +0100
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
	operations?
In-Reply-To: <24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
	<24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
Message-ID: <CAFm4XO0AUO8J=LB5bkHLDC7H7you4fzcS=Dwu+5hUpGojqqn5Q@mail.gmail.com>

Hi Jonathan!

So I have multiple options, but fundamentally I have an ORM
SynchronizationRegistry today. We could either follow the example of
the javax.transaction API in evolving the ORM SPI, or apparently I
could explore making our Synchronization stateless and store the state
in this other map instead, or maybe I try refactor it all to stick to
the standard APIs - however I wonder if it will still work for a JDBC
transaction.

Either way I'll take the fact that the standard API exposes such a
functionality as a sign that this could be sensible to expose.

Thanks,
Sanne

On 25 October 2017 at 15:37, Jonathan Halliday
<jonathan.halliday at redhat.com> wrote:
>
> The javax.transaction version of that interface already functions as a
> per-transaction hashmap, with put/get operations available. If you can use
> it directly, then just pick a suitable lookup key - FQCN or even the sync
> impl .class itself, since the key is Object type. If not then at least
> retain the method signatures and just delegate them down through the spi.
>
> https://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html
>
> Jonathan.
>
>
> On 25/10/17 14:32, Sanne Grinovero wrote:
>>
>> Hi Steve,
>>
>> do you think it would be sensible for me to explore introducing some
>> kind of synchronization lookup method on
>> org.hibernate.resource.transaction.spi.SynchronizationRegistry ?
>>
>> Today it only exposes a `registerSynchronization` method, which we use
>> extensively, but then we also have quite some complexity in the Search
>> code caused by the fact that we can't look the synchronizations up in
>> a later phase.
>> Essentially our Synchronization is stateful and we need to update it
>> later.
>>
>> I'd love to propose a change for ORM6 so allow registering such things
>> under some kind of id (a string?) so that one can look them back.
>>
>> current SPI:
>>
>>      public void registerSynchronization(Synchronization synchronization)
>>
>> temptative proposal (didn't try it yet..):
>>
>>     public void registerSynchronization(String id, Synchronization
>> synchronization);
>>
>>     public void Synchronization getSynchronization(String id);
>>
>>
>> does it sound reasonable in principle?
>>
>> This would imply other users should make up an id unique for their use
>> case. Alternatively I could live with a Class used as an id, or we
>> could have the new methods in addition to the existing method for
>> people not interested in looking things up.
>>
>> thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> --
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From steve at hibernate.org  Wed Oct 25 11:05:20 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 Oct 2017 15:05:20 +0000
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
	operations?
In-Reply-To: <24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
	<24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
Message-ID: <CAFdSV9t2z27OShUjcx6B3WD0_V2c_g4Nvv2Dy-qCx3PEPBbP6w@mail.gmail.com>

Yes, but that is only available in JTA environments.  Ours is available no
matter what kind of transaction environment we are executing in.

Sanne, how about instead a separate registration method accepting a
"registration key"?  E.g.:

public interface SynchronizationRegistry extends Serializable {
    // ~~~~~~~~~~~~~~~
    // current api
    void registerSynchronization(Synchronization synchronization);

    // ~~~~~~~~~~~~~~~
    // additional api
    void registerSynchronization(Object key, Synchronization
synchronization);
    Synchronization findSynchronization(Object key);
}

or:

public interface KeyableSynchronization extends Synchronization {
    Object getKey();
}

which can be used during #registerSynchronization(Synchronization)
processing to add to a Map as well?



On Wed, Oct 25, 2017 at 9:37 AM Jonathan Halliday <
jonathan.halliday at redhat.com> wrote:

>
> The javax.transaction version of that interface already functions as a
> per-transaction hashmap, with put/get operations available. If you can
> use it directly, then just pick a suitable lookup key - FQCN or even the
> sync impl .class itself, since the key is Object type. If not then at
> least retain the method signatures and just delegate them down through
> the spi.
>
>
> https://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html
>
> Jonathan.
>
> On 25/10/17 14:32, Sanne Grinovero wrote:
> > Hi Steve,
> >
> > do you think it would be sensible for me to explore introducing some
> > kind of synchronization lookup method on
> > org.hibernate.resource.transaction.spi.SynchronizationRegistry ?
> >
> > Today it only exposes a `registerSynchronization` method, which we use
> > extensively, but then we also have quite some complexity in the Search
> > code caused by the fact that we can't look the synchronizations up in
> > a later phase.
> > Essentially our Synchronization is stateful and we need to update it
> later.
> >
> > I'd love to propose a change for ORM6 so allow registering such things
> > under some kind of id (a string?) so that one can look them back.
> >
> > current SPI:
> >
> >      public void registerSynchronization(Synchronization synchronization)
> >
> > temptative proposal (didn't try it yet..):
> >
> >     public void registerSynchronization(String id, Synchronization
> > synchronization);
> >
> >     public void Synchronization getSynchronization(String id);
> >
> >
> > does it sound reasonable in principle?
> >
> > This would imply other users should make up an id unique for their use
> > case. Alternatively I could live with a Class used as an id, or we
> > could have the new methods in addition to the existing method for
> > people not interested in looking things up.
> >
> > thanks,
> > Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
> --
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>

From sanne at hibernate.org  Wed Oct 25 11:14:23 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 25 Oct 2017 16:14:23 +0100
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
	operations?
In-Reply-To: <CAFdSV9t2z27OShUjcx6B3WD0_V2c_g4Nvv2Dy-qCx3PEPBbP6w@mail.gmail.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
	<24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
	<CAFdSV9t2z27OShUjcx6B3WD0_V2c_g4Nvv2Dy-qCx3PEPBbP6w@mail.gmail.com>
Message-ID: <CAFm4XO3LkXx9LVEA7b-JNaCRy2U8PFCRaqjRBOmxSjhQYOBZiA@mail.gmail.com>

On 25 October 2017 at 16:05, Steve Ebersole <steve at hibernate.org> wrote:
> Yes, but that is only available in JTA environments.  Ours is available no
> matter what kind of transaction environment we are executing in.
>
> Sanne, how about instead a separate registration method accepting a
> "registration key"?  E.g.:
>
> public interface SynchronizationRegistry extends Serializable {
>     // ~~~~~~~~~~~~~~~
>     // current api
>     void registerSynchronization(Synchronization synchronization);
>
>     // ~~~~~~~~~~~~~~~
>     // additional api
>     void registerSynchronization(Object key, Synchronization
> synchronization);
>     Synchronization findSynchronization(Object key);
> }
>
> or:
>
> public interface KeyableSynchronization extends Synchronization {
>     Object getKey();
> }
>
> which can be used during #registerSynchronization(Synchronization)
> processing to add to a Map as well?

Yes that would work for me, but thinking about the implementation it
implies you'd need to hold on to both a Set and a Map, and then we'd
be exposed to silly usage like people adding the same synchronization
twice in two different ways?

I'd rather expose a single consistent way: having to make up an id
doesn't seem too inconvenient considering it's an SPI.

Thanks,
Sanne



>
>
> On Wed, Oct 25, 2017 at 9:37 AM Jonathan Halliday
> <jonathan.halliday at redhat.com> wrote:
>>
>>
>> The javax.transaction version of that interface already functions as a
>> per-transaction hashmap, with put/get operations available. If you can
>> use it directly, then just pick a suitable lookup key - FQCN or even the
>> sync impl .class itself, since the key is Object type. If not then at
>> least retain the method signatures and just delegate them down through
>> the spi.
>>
>>
>> https://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html
>>
>> Jonathan.
>>
>> On 25/10/17 14:32, Sanne Grinovero wrote:
>> > Hi Steve,
>> >
>> > do you think it would be sensible for me to explore introducing some
>> > kind of synchronization lookup method on
>> > org.hibernate.resource.transaction.spi.SynchronizationRegistry ?
>> >
>> > Today it only exposes a `registerSynchronization` method, which we use
>> > extensively, but then we also have quite some complexity in the Search
>> > code caused by the fact that we can't look the synchronizations up in
>> > a later phase.
>> > Essentially our Synchronization is stateful and we need to update it
>> > later.
>> >
>> > I'd love to propose a change for ORM6 so allow registering such things
>> > under some kind of id (a string?) so that one can look them back.
>> >
>> > current SPI:
>> >
>> >      public void registerSynchronization(Synchronization
>> > synchronization)
>> >
>> > temptative proposal (didn't try it yet..):
>> >
>> >     public void registerSynchronization(String id, Synchronization
>> > synchronization);
>> >
>> >     public void Synchronization getSynchronization(String id);
>> >
>> >
>> > does it sound reasonable in principle?
>> >
>> > This would imply other users should make up an id unique for their use
>> > case. Alternatively I could live with a Class used as an id, or we
>> > could have the new methods in addition to the existing method for
>> > people not interested in looking things up.
>> >
>> > thanks,
>> > Sanne
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>>
>> --
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From jonathan.halliday at redhat.com  Wed Oct 25 11:21:05 2017
From: jonathan.halliday at redhat.com (Jonathan Halliday)
Date: Wed, 25 Oct 2017 16:21:05 +0100
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
 operations?
In-Reply-To: <CAFm4XO0AUO8J=LB5bkHLDC7H7you4fzcS=Dwu+5hUpGojqqn5Q@mail.gmail.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
	<24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
	<CAFm4XO0AUO8J=LB5bkHLDC7H7you4fzcS=Dwu+5hUpGojqqn5Q@mail.gmail.com>
Message-ID: <248b77df-1482-6f6f-a558-3f9fd360e0dd@redhat.com>


sure, though I was thinking in terms of storing the stateful sync 
directly into the registry, not separating out the state first. Your api 
proposal made that storage a side effect of the registration call, but 
with the javax.transaction api it's an additional call, roughly

tsr.registerSync(statefulThing);
tsr.put(org.hibernate.specialkey, statefulThing);

less elegant, but more flexible in that you can stick things other than 
Synchronizations in there too if you ever need to.

Direct use in a JDBC transaction would need a dummy 
javax.transaction.TransactionSynchronizationRegistry API impl I guess, 
which does seem rather silly if you already got an spi to avoid that, 
but OTOH would not require interface changes.

Ultimately you need a tx context to tie it back to though, since the 
underlying map is per-tx. IIRC in the narayana impl the TSR actually 
delegates to the tx object, which is where the map storage resides. 
Adding the TSR to the JTA spec api was kind of a kludge to avoid 
interfaces changes in the days before defender methods (or whatever they 
would up being called). Most of the TSR methods logically belong to 
Transaction or TransactionManager. If you're keeping map put/get 
semantics decoupled from registerSync semantics, then there is no 
requirement for them to belong on the SynchronizationRegistry rather 
than some other api.

Jonathan.

On 25/10/17 16:02, Sanne Grinovero wrote:
> Hi Jonathan!
> 
> So I have multiple options, but fundamentally I have an ORM
> SynchronizationRegistry today. We could either follow the example of
> the javax.transaction API in evolving the ORM SPI, or apparently I
> could explore making our Synchronization stateless and store the state
> in this other map instead, or maybe I try refactor it all to stick to
> the standard APIs - however I wonder if it will still work for a JDBC
> transaction.
> 
> Either way I'll take the fact that the standard API exposes such a
> functionality as a sign that this could be sensible to expose.
> 
> Thanks,
> Sanne
> 
> On 25 October 2017 at 15:37, Jonathan Halliday
> <jonathan.halliday at redhat.com> wrote:
>>
>> The javax.transaction version of that interface already functions as a
>> per-transaction hashmap, with put/get operations available. If you can use
>> it directly, then just pick a suitable lookup key - FQCN or even the sync
>> impl .class itself, since the key is Object type. If not then at least
>> retain the method signatures and just delegate them down through the spi.
>>
>> https://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html
>>
>> Jonathan.
>>
>>
>> On 25/10/17 14:32, Sanne Grinovero wrote:
>>>
>>> Hi Steve,
>>>
>>> do you think it would be sensible for me to explore introducing some
>>> kind of synchronization lookup method on
>>> org.hibernate.resource.transaction.spi.SynchronizationRegistry ?
>>>
>>> Today it only exposes a `registerSynchronization` method, which we use
>>> extensively, but then we also have quite some complexity in the Search
>>> code caused by the fact that we can't look the synchronizations up in
>>> a later phase.
>>> Essentially our Synchronization is stateful and we need to update it
>>> later.
>>>
>>> I'd love to propose a change for ORM6 so allow registering such things
>>> under some kind of id (a string?) so that one can look them back.
>>>
>>> current SPI:
>>>
>>>       public void registerSynchronization(Synchronization synchronization)
>>>
>>> temptative proposal (didn't try it yet..):
>>>
>>>      public void registerSynchronization(String id, Synchronization
>>> synchronization);
>>>
>>>      public void Synchronization getSynchronization(String id);
>>>
>>>
>>> does it sound reasonable in principle?
>>>
>>> This would imply other users should make up an id unique for their use
>>> case. Alternatively I could live with a Class used as an id, or we
>>> could have the new methods in addition to the existing method for
>>> people not interested in looking things up.
>>>
>>> thanks,
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>> --
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 

-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From steve at hibernate.org  Wed Oct 25 11:22:06 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 Oct 2017 15:22:06 +0000
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
	operations?
In-Reply-To: <CAFm4XO3LkXx9LVEA7b-JNaCRy2U8PFCRaqjRBOmxSjhQYOBZiA@mail.gmail.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
	<24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
	<CAFdSV9t2z27OShUjcx6B3WD0_V2c_g4Nvv2Dy-qCx3PEPBbP6w@mail.gmail.com>
	<CAFm4XO3LkXx9LVEA7b-JNaCRy2U8PFCRaqjRBOmxSjhQYOBZiA@mail.gmail.com>
Message-ID: <CAFdSV9uve0rZVoDOQ2kQT6MVvZjZ4QvQD7PH+B4AM4iOk8PHmg@mail.gmail.com>

> Yes that would work for me, but thinking about the implementation it
> implies you'd need to hold on to both a Set and a Map, and then we'd
> be exposed to silly usage like people adding the same synchronization
> twice in two different ways?
>

Does it?  Nothing in the SPI requires us to store things in any specific
way.  E.g. we can keep just a Map - when we are passed
a KeyableSynchronization we'd use that key, when we are passed a
non-KeyableSynchronization Synchronization we'd generate one ourselves.

And we cant stop people from every conceivable "silly usage".  At some
point we are professional developers and should be able to do the non-silly
things ;)

And as far as your "register the thing twice" worry... rhetorically, what
stops them from calling:

reg.register( "abc", MySync.INSTANCE )
reg.register( "123", MySync.INSTANCE )

Nothing.


I'd rather expose a single consistent way: having to make up an id
> doesn't seem too inconvenient considering it's an SPI.
>

Well, again, I don't see how KeyableSynchronization is a "inconsistent"
approach.  In fact out of the 2, it is my preferance.

From steve at hibernate.org  Wed Oct 25 11:24:00 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 Oct 2017 15:24:00 +0000
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
	operations?
In-Reply-To: <CAFdSV9uve0rZVoDOQ2kQT6MVvZjZ4QvQD7PH+B4AM4iOk8PHmg@mail.gmail.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
	<24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
	<CAFdSV9t2z27OShUjcx6B3WD0_V2c_g4Nvv2Dy-qCx3PEPBbP6w@mail.gmail.com>
	<CAFm4XO3LkXx9LVEA7b-JNaCRy2U8PFCRaqjRBOmxSjhQYOBZiA@mail.gmail.com>
	<CAFdSV9uve0rZVoDOQ2kQT6MVvZjZ4QvQD7PH+B4AM4iOk8PHmg@mail.gmail.com>
Message-ID: <CAFdSV9tfnSdy1Vgrs3uGf2Z5da_MDuCMSD26Gqy8foA6E1BqFA@mail.gmail.com>

Jonathan, we aren't going to be exposing this or using this
via TransactionSynchronizationRegistry.  Your comment about a "dummy" in
the JDBC txn case is exactly why.  We already have such an abstraction :
SynchronizationRegistry

On Wed, Oct 25, 2017 at 10:22 AM Steve Ebersole <steve at hibernate.org> wrote:

> Yes that would work for me, but thinking about the implementation it
>> implies you'd need to hold on to both a Set and a Map, and then we'd
>> be exposed to silly usage like people adding the same synchronization
>> twice in two different ways?
>>
>
> Does it?  Nothing in the SPI requires us to store things in any specific
> way.  E.g. we can keep just a Map - when we are passed
> a KeyableSynchronization we'd use that key, when we are passed a
> non-KeyableSynchronization Synchronization we'd generate one ourselves.
>
> And we cant stop people from every conceivable "silly usage".  At some
> point we are professional developers and should be able to do the non-silly
> things ;)
>
> And as far as your "register the thing twice" worry... rhetorically, what
> stops them from calling:
>
> reg.register( "abc", MySync.INSTANCE )
> reg.register( "123", MySync.INSTANCE )
>
> Nothing.
>
>
> I'd rather expose a single consistent way: having to make up an id
>> doesn't seem too inconvenient considering it's an SPI.
>>
>
> Well, again, I don't see how KeyableSynchronization is a "inconsistent"
> approach.  In fact out of the 2, it is my preferance.
>
>

From steve at hibernate.org  Wed Oct 25 11:25:37 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 Oct 2017 15:25:37 +0000
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
	operations?
In-Reply-To: <CAFdSV9tfnSdy1Vgrs3uGf2Z5da_MDuCMSD26Gqy8foA6E1BqFA@mail.gmail.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
	<24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
	<CAFdSV9t2z27OShUjcx6B3WD0_V2c_g4Nvv2Dy-qCx3PEPBbP6w@mail.gmail.com>
	<CAFm4XO3LkXx9LVEA7b-JNaCRy2U8PFCRaqjRBOmxSjhQYOBZiA@mail.gmail.com>
	<CAFdSV9uve0rZVoDOQ2kQT6MVvZjZ4QvQD7PH+B4AM4iOk8PHmg@mail.gmail.com>
	<CAFdSV9tfnSdy1Vgrs3uGf2Z5da_MDuCMSD26Gqy8foA6E1BqFA@mail.gmail.com>
Message-ID: <CAFdSV9vCU2RKG_=db-7od35fNNFYeQxnRKTW1yym4Lr5+hE=1Q@mail.gmail.com>

Also, unless I am mistaken `TransactionSynchronizationRegistry#put` works
on the principle that the "current transaction" is associated with the
current thread.  I absolutely want to stay away from that as an assumption
here.  It simply does not hold true in the JDBC txn case.

On Wed, Oct 25, 2017 at 10:24 AM Steve Ebersole <steve at hibernate.org> wrote:

> Jonathan, we aren't going to be exposing this or using this
> via TransactionSynchronizationRegistry.  Your comment about a "dummy" in
> the JDBC txn case is exactly why.  We already have such an abstraction :
> SynchronizationRegistry
>
> On Wed, Oct 25, 2017 at 10:22 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Yes that would work for me, but thinking about the implementation it
>>> implies you'd need to hold on to both a Set and a Map, and then we'd
>>> be exposed to silly usage like people adding the same synchronization
>>> twice in two different ways?
>>>
>>
>> Does it?  Nothing in the SPI requires us to store things in any specific
>> way.  E.g. we can keep just a Map - when we are passed
>> a KeyableSynchronization we'd use that key, when we are passed a
>> non-KeyableSynchronization Synchronization we'd generate one ourselves.
>>
>> And we cant stop people from every conceivable "silly usage".  At some
>> point we are professional developers and should be able to do the non-silly
>> things ;)
>>
>> And as far as your "register the thing twice" worry... rhetorically, what
>> stops them from calling:
>>
>> reg.register( "abc", MySync.INSTANCE )
>> reg.register( "123", MySync.INSTANCE )
>>
>> Nothing.
>>
>>
>> I'd rather expose a single consistent way: having to make up an id
>>> doesn't seem too inconvenient considering it's an SPI.
>>>
>>
>> Well, again, I don't see how KeyableSynchronization is a "inconsistent"
>> approach.  In fact out of the 2, it is my preferance.
>>
>>

From jonathan.halliday at redhat.com  Wed Oct 25 11:37:52 2017
From: jonathan.halliday at redhat.com (Jonathan Halliday)
Date: Wed, 25 Oct 2017 16:37:52 +0100
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
 operations?
In-Reply-To: <CAFdSV9vCU2RKG_=db-7od35fNNFYeQxnRKTW1yym4Lr5+hE=1Q@mail.gmail.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
	<24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
	<CAFdSV9t2z27OShUjcx6B3WD0_V2c_g4Nvv2Dy-qCx3PEPBbP6w@mail.gmail.com>
	<CAFm4XO3LkXx9LVEA7b-JNaCRy2U8PFCRaqjRBOmxSjhQYOBZiA@mail.gmail.com>
	<CAFdSV9uve0rZVoDOQ2kQT6MVvZjZ4QvQD7PH+B4AM4iOk8PHmg@mail.gmail.com>
	<CAFdSV9tfnSdy1Vgrs3uGf2Z5da_MDuCMSD26Gqy8foA6E1BqFA@mail.gmail.com>
	<CAFdSV9vCU2RKG_=db-7od35fNNFYeQxnRKTW1yym4Lr5+hE=1Q@mail.gmail.com>
Message-ID: <3ed27217-d3f7-ca76-3e1e-7b659701d7d5@redhat.com>


right, a lot of JTA works on the 'tx bound to thread' approach and it's 
a right pain in async I/O thread pooled environments like vert.x  That's 
one of the reasons why sticking a get/put api on the Transaction 
instance abstraction instead may make more sense, though I'm guessing 
your SynchronizationRegistry is instance per tx rather than a singleton 
like the JTA one is, so it may not make much difference which object 
carries the functionality for your case?

Jonathan.

On 25/10/17 16:25, Steve Ebersole wrote:
> Also, unless I am mistaken `TransactionSynchronizationRegistry#put` 
> works on the principle that the "current transaction" is associated with 
> the current thread.? I absolutely want to stay away from that as an 
> assumption here.? It simply does not hold true in the JDBC txn case.
> 
> On Wed, Oct 25, 2017 at 10:24 AM Steve Ebersole <steve at hibernate.org 
> <mailto:steve at hibernate.org>> wrote:
> 
>     Jonathan, we aren't going to be exposing this or using this
>     via?TransactionSynchronizationRegistry.? Your comment about a
>     "dummy" in the JDBC txn case is exactly why.? We already have such
>     an abstraction : SynchronizationRegistry
> 
>     On Wed, Oct 25, 2017 at 10:22 AM Steve Ebersole <steve at hibernate.org
>     <mailto:steve at hibernate.org>> wrote:
> 
>             Yes that would work for me, but thinking about the
>             implementation it
>             implies you'd need to hold on to both a Set and a Map, and
>             then we'd
>             be exposed to silly usage like people adding the same
>             synchronization
>             twice in two different ways?
> 
> 
>         Does it?? Nothing in the SPI requires us to store things in any
>         specific way.? E.g. we can keep just a Map - when we are passed
>         a?KeyableSynchronization we'd use that key, when we are passed a
>         non-KeyableSynchronization Synchronization we'd generate one
>         ourselves.
> 
>         And we cant stop people from every conceivable "silly usage". 
>         At some point we are professional developers and should be able
>         to do the non-silly things ;)
> 
>         And as far as your "register the thing twice" worry...
>         rhetorically, what stops them from calling:
> 
>         reg.register( "abc", MySync.INSTANCE )
>         reg.register( "123", MySync.INSTANCE )
> 
>         Nothing.
> 
> 
>             I'd rather expose a single consistent way: having to make up
>             an id
>             doesn't seem too inconvenient considering it's an SPI.
> 
> 
>         Well, again, I don't see how KeyableSynchronization is a
>         "inconsistent" approach.? In fact out of the 2, it is my preferance.
> 

-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From steve at hibernate.org  Wed Oct 25 11:39:48 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 Oct 2017 15:39:48 +0000
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
	operations?
In-Reply-To: <3ed27217-d3f7-ca76-3e1e-7b659701d7d5@redhat.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
	<24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
	<CAFdSV9t2z27OShUjcx6B3WD0_V2c_g4Nvv2Dy-qCx3PEPBbP6w@mail.gmail.com>
	<CAFm4XO3LkXx9LVEA7b-JNaCRy2U8PFCRaqjRBOmxSjhQYOBZiA@mail.gmail.com>
	<CAFdSV9uve0rZVoDOQ2kQT6MVvZjZ4QvQD7PH+B4AM4iOk8PHmg@mail.gmail.com>
	<CAFdSV9tfnSdy1Vgrs3uGf2Z5da_MDuCMSD26Gqy8foA6E1BqFA@mail.gmail.com>
	<CAFdSV9vCU2RKG_=db-7od35fNNFYeQxnRKTW1yym4Lr5+hE=1Q@mail.gmail.com>
	<3ed27217-d3f7-ca76-3e1e-7b659701d7d5@redhat.com>
Message-ID: <CAFdSV9tyStwrFW0zSijaMt=GRWP56ksVkeG5Kstq-Hp+irMx7w@mail.gmail.com>

The SynchronizationRegistry is kept per-LogicalConncection which might span
multiple physical transactions.

On Wed, Oct 25, 2017 at 10:37 AM Jonathan Halliday <
jonathan.halliday at redhat.com> wrote:

>
> right, a lot of JTA works on the 'tx bound to thread' approach and it's
> a right pain in async I/O thread pooled environments like vert.x  That's
> one of the reasons why sticking a get/put api on the Transaction
> instance abstraction instead may make more sense, though I'm guessing
> your SynchronizationRegistry is instance per tx rather than a singleton
> like the JTA one is, so it may not make much difference which object
> carries the functionality for your case?
>
> Jonathan.
>
> On 25/10/17 16:25, Steve Ebersole wrote:
> > Also, unless I am mistaken `TransactionSynchronizationRegistry#put`
> > works on the principle that the "current transaction" is associated with
> > the current thread.  I absolutely want to stay away from that as an
> > assumption here.  It simply does not hold true in the JDBC txn case.
> >
> > On Wed, Oct 25, 2017 at 10:24 AM Steve Ebersole <steve at hibernate.org
> > <mailto:steve at hibernate.org>> wrote:
> >
> >     Jonathan, we aren't going to be exposing this or using this
> >     via TransactionSynchronizationRegistry.  Your comment about a
> >     "dummy" in the JDBC txn case is exactly why.  We already have such
> >     an abstraction : SynchronizationRegistry
> >
> >     On Wed, Oct 25, 2017 at 10:22 AM Steve Ebersole <steve at hibernate.org
> >     <mailto:steve at hibernate.org>> wrote:
> >
> >             Yes that would work for me, but thinking about the
> >             implementation it
> >             implies you'd need to hold on to both a Set and a Map, and
> >             then we'd
> >             be exposed to silly usage like people adding the same
> >             synchronization
> >             twice in two different ways?
> >
> >
> >         Does it?  Nothing in the SPI requires us to store things in any
> >         specific way.  E.g. we can keep just a Map - when we are passed
> >         a KeyableSynchronization we'd use that key, when we are passed a
> >         non-KeyableSynchronization Synchronization we'd generate one
> >         ourselves.
> >
> >         And we cant stop people from every conceivable "silly usage".
> >         At some point we are professional developers and should be able
> >         to do the non-silly things ;)
> >
> >         And as far as your "register the thing twice" worry...
> >         rhetorically, what stops them from calling:
> >
> >         reg.register( "abc", MySync.INSTANCE )
> >         reg.register( "123", MySync.INSTANCE )
> >
> >         Nothing.
> >
> >
> >             I'd rather expose a single consistent way: having to make up
> >             an id
> >             doesn't seem too inconvenient considering it's an SPI.
> >
> >
> >         Well, again, I don't see how KeyableSynchronization is a
> >         "inconsistent" approach.  In fact out of the 2, it is my
> preferance.
> >
>
> --
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>

From jonathan.halliday at redhat.com  Wed Oct 25 12:13:03 2017
From: jonathan.halliday at redhat.com (Jonathan Halliday)
Date: Wed, 25 Oct 2017 17:13:03 +0100
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
 operations?
In-Reply-To: <CAFdSV9tyStwrFW0zSijaMt=GRWP56ksVkeG5Kstq-Hp+irMx7w@mail.gmail.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
	<24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
	<CAFdSV9t2z27OShUjcx6B3WD0_V2c_g4Nvv2Dy-qCx3PEPBbP6w@mail.gmail.com>
	<CAFm4XO3LkXx9LVEA7b-JNaCRy2U8PFCRaqjRBOmxSjhQYOBZiA@mail.gmail.com>
	<CAFdSV9uve0rZVoDOQ2kQT6MVvZjZ4QvQD7PH+B4AM4iOk8PHmg@mail.gmail.com>
	<CAFdSV9tfnSdy1Vgrs3uGf2Z5da_MDuCMSD26Gqy8foA6E1BqFA@mail.gmail.com>
	<CAFdSV9vCU2RKG_=db-7od35fNNFYeQxnRKTW1yym4Lr5+hE=1Q@mail.gmail.com>
	<3ed27217-d3f7-ca76-3e1e-7b659701d7d5@redhat.com>
	<CAFdSV9tyStwrFW0zSijaMt=GRWP56ksVkeG5Kstq-Hp+irMx7w@mail.gmail.com>
Message-ID: <15bc7d94-3d02-44c7-550b-474a98fc219e@redhat.com>


so you have some form of implicit cleanup that de-registers 
Synchronizations when the transaction finishes, or do they stay 
registered and re-fire for each tx on the connection?

As to the multiple registration semantics, IIRC the arjuna code allows 
the same Synchronization to be registered multiple times and in such 
case it will be called multiple times too. No reason you need to follow 
that model unless you're delegating to the tx engine though. If you go 
for 'we always generate the key for you', then calling

String id = sr.register(sync)

twice could just give you back the same id. Downside is you need to 
store that id someplace, which misses the point of allowing a fixed 
constant as the key. I'm rather assuming that's the requirement here, 
since if you're needing to keep and pass around a uniq key then you may 
as well just pass around the sync object itself? Anyhow, is a key of any 
form necessary for that use case? Could retrieval just be

sr.getSynchronizationsOfType(thing.class)

to match on class/interface, which should be all that's needed to find 
e.g. the cache/search/whatever synchronization.  Not having a key means 
saves having to define how it behaves. Lookup maybe slower if you're 
going to support polymorphism though, but the number of Synchronizations 
per tx should be small.

Jonathan.

On 25/10/17 16:39, Steve Ebersole wrote:
> The SynchronizationRegistry is kept per-LogicalConncection which might 
> span multiple physical transactions.
> 
> On Wed, Oct 25, 2017 at 10:37 AM Jonathan Halliday 
> <jonathan.halliday at redhat.com <mailto:jonathan.halliday at redhat.com>> wrote:
> 
> 
>     right, a lot of JTA works on the 'tx bound to thread' approach and it's
>     a right pain in async I/O thread pooled environments like vert.x? That's
>     one of the reasons why sticking a get/put api on the Transaction
>     instance abstraction instead may make more sense, though I'm guessing
>     your SynchronizationRegistry is instance per tx rather than a singleton
>     like the JTA one is, so it may not make much difference which object
>     carries the functionality for your case?
> 
>     Jonathan.
> 
>     On 25/10/17 16:25, Steve Ebersole wrote:
>      > Also, unless I am mistaken `TransactionSynchronizationRegistry#put`
>      > works on the principle that the "current transaction" is
>     associated with
>      > the current thread.? I absolutely want to stay away from that as an
>      > assumption here.? It simply does not hold true in the JDBC txn case.
>      >
>      > On Wed, Oct 25, 2017 at 10:24 AM Steve Ebersole
>     <steve at hibernate.org <mailto:steve at hibernate.org>
>      > <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>> wrote:
>      >
>      >? ? ?Jonathan, we aren't going to be exposing this or using this
>      >? ? ?via?TransactionSynchronizationRegistry.? Your comment about a
>      >? ? ?"dummy" in the JDBC txn case is exactly why.? We already have
>     such
>      >? ? ?an abstraction : SynchronizationRegistry
>      >
>      >? ? ?On Wed, Oct 25, 2017 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:
>      >
>      >? ? ? ? ? ? ?Yes that would work for me, but thinking about the
>      >? ? ? ? ? ? ?implementation it
>      >? ? ? ? ? ? ?implies you'd need to hold on to both a Set and a
>     Map, and
>      >? ? ? ? ? ? ?then we'd
>      >? ? ? ? ? ? ?be exposed to silly usage like people adding the same
>      >? ? ? ? ? ? ?synchronization
>      >? ? ? ? ? ? ?twice in two different ways?
>      >
>      >
>      >? ? ? ? ?Does it?? Nothing in the SPI requires us to store things
>     in any
>      >? ? ? ? ?specific way.? E.g. we can keep just a Map - when we are
>     passed
>      >? ? ? ? ?a?KeyableSynchronization we'd use that key, when we are
>     passed a
>      >? ? ? ? ?non-KeyableSynchronization Synchronization we'd generate one
>      >? ? ? ? ?ourselves.
>      >
>      >? ? ? ? ?And we cant stop people from every conceivable "silly usage".
>      >? ? ? ? ?At some point we are professional developers and should
>     be able
>      >? ? ? ? ?to do the non-silly things ;)
>      >
>      >? ? ? ? ?And as far as your "register the thing twice" worry...
>      >? ? ? ? ?rhetorically, what stops them from calling:
>      >
>      >? ? ? ? ?reg.register( "abc", MySync.INSTANCE )
>      >? ? ? ? ?reg.register( "123", MySync.INSTANCE )
>      >
>      >? ? ? ? ?Nothing.
>      >
>      >
>      >? ? ? ? ? ? ?I'd rather expose a single consistent way: having to
>     make up
>      >? ? ? ? ? ? ?an id
>      >? ? ? ? ? ? ?doesn't seem too inconvenient considering it's an SPI.
>      >
>      >
>      >? ? ? ? ?Well, again, I don't see how KeyableSynchronization is a
>      >? ? ? ? ?"inconsistent" approach.? In fact out of the 2, it is my
>     preferance.
>      >
> 
>     --
>     Registered in England and Wales under Company Registration No. 03798903
>     Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 

-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From sanne at hibernate.org  Wed Oct 25 19:15:28 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Oct 2017 00:15:28 +0100
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
	operations?
In-Reply-To: <CAFdSV9uve0rZVoDOQ2kQT6MVvZjZ4QvQD7PH+B4AM4iOk8PHmg@mail.gmail.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
	<24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
	<CAFdSV9t2z27OShUjcx6B3WD0_V2c_g4Nvv2Dy-qCx3PEPBbP6w@mail.gmail.com>
	<CAFm4XO3LkXx9LVEA7b-JNaCRy2U8PFCRaqjRBOmxSjhQYOBZiA@mail.gmail.com>
	<CAFdSV9uve0rZVoDOQ2kQT6MVvZjZ4QvQD7PH+B4AM4iOk8PHmg@mail.gmail.com>
Message-ID: <CAFm4XO3YFH8tfp7f-5ap3qGyH_u_2wU1D1CFb9R-ZMNJ__CKvA@mail.gmail.com>

On 25 October 2017 at 16:22, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Yes that would work for me, but thinking about the implementation it
>> implies you'd need to hold on to both a Set and a Map, and then we'd
>> be exposed to silly usage like people adding the same synchronization
>> twice in two different ways?
>
>
> Does it?  Nothing in the SPI requires us to store things in any specific
> way.  E.g. we can keep just a Map - when we are passed a
> KeyableSynchronization we'd use that key, when we are passed a
> non-KeyableSynchronization Synchronization we'd generate one ourselves.

Sure it's possible but it introduces complexity; considering this is
an SPI I'd assume we can just enforce a different contract and keep it
simple.

>
> And we cant stop people from every conceivable "silly usage".  At some point
> we are professional developers and should be able to do the non-silly things
> ;)
>
> And as far as your "register the thing twice" worry... rhetorically, what
> stops them from calling:
>
> reg.register( "abc", MySync.INSTANCE )
> reg.register( "123", MySync.INSTANCE )
>
> Nothing.

No doubt, but also if I write such code it's self-explanatory what I get.

Some less trivial example gets me in undefined places:

reg.register( "abc", MySync.INSTANCE )
Synchronization instance = reg.get("abc");
reg.register(instance);

quiz:
 - will my Syncrhonization instance get all notifications twice?

Just thinking that it would be better to avoid undefined expectations.

Are you aiming at backwards compatibility?
In that case I'm happy to explore non-breaking alternatives, I was
merely assuming that SPIs would be wildfly different anyway so no big
deal in breaking one more.

Thanks,
Sanne


>
>
>> I'd rather expose a single consistent way: having to make up an id
>> doesn't seem too inconvenient considering it's an SPI.
>
>
> Well, again, I don't see how KeyableSynchronization is a "inconsistent"
> approach.  In fact out of the 2, it is my preferance.
>

From sanne at hibernate.org  Wed Oct 25 19:23:45 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Oct 2017 00:23:45 +0100
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
	operations?
In-Reply-To: <15bc7d94-3d02-44c7-550b-474a98fc219e@redhat.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
	<24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
	<CAFdSV9t2z27OShUjcx6B3WD0_V2c_g4Nvv2Dy-qCx3PEPBbP6w@mail.gmail.com>
	<CAFm4XO3LkXx9LVEA7b-JNaCRy2U8PFCRaqjRBOmxSjhQYOBZiA@mail.gmail.com>
	<CAFdSV9uve0rZVoDOQ2kQT6MVvZjZ4QvQD7PH+B4AM4iOk8PHmg@mail.gmail.com>
	<CAFdSV9tfnSdy1Vgrs3uGf2Z5da_MDuCMSD26Gqy8foA6E1BqFA@mail.gmail.com>
	<CAFdSV9vCU2RKG_=db-7od35fNNFYeQxnRKTW1yym4Lr5+hE=1Q@mail.gmail.com>
	<3ed27217-d3f7-ca76-3e1e-7b659701d7d5@redhat.com>
	<CAFdSV9tyStwrFW0zSijaMt=GRWP56ksVkeG5Kstq-Hp+irMx7w@mail.gmail.com>
	<15bc7d94-3d02-44c7-550b-474a98fc219e@redhat.com>
Message-ID: <CAFm4XO1GKuaWDB=nQZ+c_0z--GJ-GuRMQ9jB=K53R3+22Pgu6A@mail.gmail.com>

On 25 October 2017 at 17:13, Jonathan Halliday
<jonathan.halliday at redhat.com> wrote:
>
> so you have some form of implicit cleanup that de-registers Synchronizations
> when the transaction finishes, or do they stay registered and re-fire for
> each tx on the connection?
>
> As to the multiple registration semantics, IIRC the arjuna code allows the
> same Synchronization to be registered multiple times and in such case it
> will be called multiple times too. No reason you need to follow that model
> unless you're delegating to the tx engine though. If you go for 'we always
> generate the key for you', then calling
>
> String id = sr.register(sync)
>
> twice could just give you back the same id. Downside is you need to store
> that id someplace, which misses the point of allowing a fixed constant as
> the key. I'm rather assuming that's the requirement here, since if you're
> needing to keep and pass around a uniq key then you may as well just pass
> around the sync object itself?

I agree, that's what I'd want to avoid - at least in the Hibernate Search case.

> Anyhow, is a key of any form necessary for
> that use case? Could retrieval just be
>
> sr.getSynchronizationsOfType(thing.class)
>
> to match on class/interface, which should be all that's needed to find e.g.
> the cache/search/whatever synchronization.  Not having a key means saves
> having to define how it behaves. Lookup maybe slower if you're going to
> support polymorphism though, but the number of Synchronizations per tx
> should be small.

That would work for me, and I wouldn't need polymorphism. Exact class
will do just fine.

So this approach might allow to keep the registration API as-is, but
if we allow to register
multiple instances of the same class the retrieval would return a
random instance.

That's not a problem for my use case and could be addressed with javadoc,
probably a nice compromise.
Incidentally maps keyed by Class are very efficient so that's nice too.

Would it suffice for you too Radim? Since noone else ever asked for
such a feature I think the two of us represent the users population :)

Thanks,
Sanne


>
> Jonathan.
>
> On 25/10/17 16:39, Steve Ebersole wrote:
>>
>> The SynchronizationRegistry is kept per-LogicalConncection which might
>> span multiple physical transactions.
>>
>> On Wed, Oct 25, 2017 at 10:37 AM Jonathan Halliday
>> <jonathan.halliday at redhat.com <mailto:jonathan.halliday at redhat.com>> wrote:
>>
>>
>>     right, a lot of JTA works on the 'tx bound to thread' approach and
>> it's
>>     a right pain in async I/O thread pooled environments like vert.x
>> That's
>>     one of the reasons why sticking a get/put api on the Transaction
>>     instance abstraction instead may make more sense, though I'm guessing
>>     your SynchronizationRegistry is instance per tx rather than a
>> singleton
>>     like the JTA one is, so it may not make much difference which object
>>     carries the functionality for your case?
>>
>>     Jonathan.
>>
>>     On 25/10/17 16:25, Steve Ebersole wrote:
>>      > Also, unless I am mistaken `TransactionSynchronizationRegistry#put`
>>      > works on the principle that the "current transaction" is
>>     associated with
>>      > the current thread.  I absolutely want to stay away from that as an
>>      > assumption here.  It simply does not hold true in the JDBC txn
>> case.
>>      >
>>      > On Wed, Oct 25, 2017 at 10:24 AM Steve Ebersole
>>     <steve at hibernate.org <mailto:steve at hibernate.org>
>>      > <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>> wrote:
>>      >
>>      >     Jonathan, we aren't going to be exposing this or using this
>>      >     via TransactionSynchronizationRegistry.  Your comment about a
>>      >     "dummy" in the JDBC txn case is exactly why.  We already have
>>     such
>>      >     an abstraction : SynchronizationRegistry
>>      >
>>      >     On Wed, Oct 25, 2017 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:
>>      >
>>      >             Yes that would work for me, but thinking about the
>>      >             implementation it
>>      >             implies you'd need to hold on to both a Set and a
>>     Map, and
>>      >             then we'd
>>      >             be exposed to silly usage like people adding the same
>>      >             synchronization
>>      >             twice in two different ways?
>>      >
>>      >
>>      >         Does it?  Nothing in the SPI requires us to store things
>>     in any
>>      >         specific way.  E.g. we can keep just a Map - when we are
>>     passed
>>      >         a KeyableSynchronization we'd use that key, when we are
>>     passed a
>>      >         non-KeyableSynchronization Synchronization we'd generate
>> one
>>      >         ourselves.
>>      >
>>      >         And we cant stop people from every conceivable "silly
>> usage".
>>      >         At some point we are professional developers and should
>>     be able
>>      >         to do the non-silly things ;)
>>      >
>>      >         And as far as your "register the thing twice" worry...
>>      >         rhetorically, what stops them from calling:
>>      >
>>      >         reg.register( "abc", MySync.INSTANCE )
>>      >         reg.register( "123", MySync.INSTANCE )
>>      >
>>      >         Nothing.
>>      >
>>      >
>>      >             I'd rather expose a single consistent way: having to
>>     make up
>>      >             an id
>>      >             doesn't seem too inconvenient considering it's an SPI.
>>      >
>>      >
>>      >         Well, again, I don't see how KeyableSynchronization is a
>>      >         "inconsistent" approach.  In fact out of the 2, it is my
>>     preferance.
>>      >
>>
>>     --
>>     Registered in England and Wales under Company Registration No.
>> 03798903
>>     Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>>
>
> --
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From rvansa at redhat.com  Thu Oct 26 04:11:01 2017
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 26 Oct 2017 10:11:01 +0200
Subject: [hibernate-dev] SynchronizationRegistry: expose read (lookup)
 operations?
In-Reply-To: <CAFm4XO1GKuaWDB=nQZ+c_0z--GJ-GuRMQ9jB=K53R3+22Pgu6A@mail.gmail.com>
References: <CAFm4XO2cr_5tggCujOC9pUV+gufOBhvihARTo58pQ=1CNYaFAQ@mail.gmail.com>
	<24154d8a-af1e-2882-8280-2571ca8383e3@redhat.com>
	<CAFdSV9t2z27OShUjcx6B3WD0_V2c_g4Nvv2Dy-qCx3PEPBbP6w@mail.gmail.com>
	<CAFm4XO3LkXx9LVEA7b-JNaCRy2U8PFCRaqjRBOmxSjhQYOBZiA@mail.gmail.com>
	<CAFdSV9uve0rZVoDOQ2kQT6MVvZjZ4QvQD7PH+B4AM4iOk8PHmg@mail.gmail.com>
	<CAFdSV9tfnSdy1Vgrs3uGf2Z5da_MDuCMSD26Gqy8foA6E1BqFA@mail.gmail.com>
	<CAFdSV9vCU2RKG_=db-7od35fNNFYeQxnRKTW1yym4Lr5+hE=1Q@mail.gmail.com>
	<3ed27217-d3f7-ca76-3e1e-7b659701d7d5@redhat.com>
	<CAFdSV9tyStwrFW0zSijaMt=GRWP56ksVkeG5Kstq-Hp+irMx7w@mail.gmail.com>
	<15bc7d94-3d02-44c7-550b-474a98fc219e@redhat.com>
	<CAFm4XO1GKuaWDB=nQZ+c_0z--GJ-GuRMQ9jB=K53R3+22Pgu6A@mail.gmail.com>
Message-ID: <21e0a6ab-fea9-ebf7-3730-7110f82dcdfb@redhat.com>

On 10/26/2017 01:23 AM, Sanne Grinovero wrote:
> On 25 October 2017 at 17:13, Jonathan Halliday
> <jonathan.halliday at redhat.com> wrote:
>> so you have some form of implicit cleanup that de-registers Synchronizations
>> when the transaction finishes, or do they stay registered and re-fire for
>> each tx on the connection?
>>
>> As to the multiple registration semantics, IIRC the arjuna code allows the
>> same Synchronization to be registered multiple times and in such case it
>> will be called multiple times too. No reason you need to follow that model
>> unless you're delegating to the tx engine though. If you go for 'we always
>> generate the key for you', then calling
>>
>> String id = sr.register(sync)
>>
>> twice could just give you back the same id. Downside is you need to store
>> that id someplace, which misses the point of allowing a fixed constant as
>> the key. I'm rather assuming that's the requirement here, since if you're
>> needing to keep and pass around a uniq key then you may as well just pass
>> around the sync object itself?
> I agree, that's what I'd want to avoid - at least in the Hibernate Search case.
>
>> Anyhow, is a key of any form necessary for
>> that use case? Could retrieval just be
>>
>> sr.getSynchronizationsOfType(thing.class)
>>
>> to match on class/interface, which should be all that's needed to find e.g.
>> the cache/search/whatever synchronization.  Not having a key means saves
>> having to define how it behaves. Lookup maybe slower if you're going to
>> support polymorphism though, but the number of Synchronizations per tx
>> should be small.
> That would work for me, and I wouldn't need polymorphism. Exact class
> will do just fine.
>
> So this approach might allow to keep the registration API as-is, but
> if we allow to register
> multiple instances of the same class the retrieval would return a
> random instance.
>
> That's not a problem for my use case and could be addressed with javadoc,
> probably a nice compromise.
> Incidentally maps keyed by Class are very efficient so that's nice too.
>
> Would it suffice for you too Radim? Since noone else ever asked for
> such a feature I think the two of us represent the users population :)

My case was already solved by the CacheTransactionContext, and it seems 
more convenient than doing any lookups. But for general use I find 
by-class lookup more appealing than registering with a custom key. The 
registrar can always use some private class; it's not like unrelated 
components would do lookup of others' synchronizations.

Radim

>
> Thanks,
> Sanne
>
>
>> Jonathan.
>>
>> On 25/10/17 16:39, Steve Ebersole wrote:
>>> The SynchronizationRegistry is kept per-LogicalConncection which might
>>> span multiple physical transactions.
>>>
>>> On Wed, Oct 25, 2017 at 10:37 AM Jonathan Halliday
>>> <jonathan.halliday at redhat.com <mailto:jonathan.halliday at redhat.com>> wrote:
>>>
>>>
>>>      right, a lot of JTA works on the 'tx bound to thread' approach and
>>> it's
>>>      a right pain in async I/O thread pooled environments like vert.x
>>> That's
>>>      one of the reasons why sticking a get/put api on the Transaction
>>>      instance abstraction instead may make more sense, though I'm guessing
>>>      your SynchronizationRegistry is instance per tx rather than a
>>> singleton
>>>      like the JTA one is, so it may not make much difference which object
>>>      carries the functionality for your case?
>>>
>>>      Jonathan.
>>>
>>>      On 25/10/17 16:25, Steve Ebersole wrote:
>>>       > Also, unless I am mistaken `TransactionSynchronizationRegistry#put`
>>>       > works on the principle that the "current transaction" is
>>>      associated with
>>>       > the current thread.  I absolutely want to stay away from that as an
>>>       > assumption here.  It simply does not hold true in the JDBC txn
>>> case.
>>>       >
>>>       > On Wed, Oct 25, 2017 at 10:24 AM Steve Ebersole
>>>      <steve at hibernate.org <mailto:steve at hibernate.org>
>>>       > <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>> wrote:
>>>       >
>>>       >     Jonathan, we aren't going to be exposing this or using this
>>>       >     via TransactionSynchronizationRegistry.  Your comment about a
>>>       >     "dummy" in the JDBC txn case is exactly why.  We already have
>>>      such
>>>       >     an abstraction : SynchronizationRegistry
>>>       >
>>>       >     On Wed, Oct 25, 2017 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:
>>>       >
>>>       >             Yes that would work for me, but thinking about the
>>>       >             implementation it
>>>       >             implies you'd need to hold on to both a Set and a
>>>      Map, and
>>>       >             then we'd
>>>       >             be exposed to silly usage like people adding the same
>>>       >             synchronization
>>>       >             twice in two different ways?
>>>       >
>>>       >
>>>       >         Does it?  Nothing in the SPI requires us to store things
>>>      in any
>>>       >         specific way.  E.g. we can keep just a Map - when we are
>>>      passed
>>>       >         a KeyableSynchronization we'd use that key, when we are
>>>      passed a
>>>       >         non-KeyableSynchronization Synchronization we'd generate
>>> one
>>>       >         ourselves.
>>>       >
>>>       >         And we cant stop people from every conceivable "silly
>>> usage".
>>>       >         At some point we are professional developers and should
>>>      be able
>>>       >         to do the non-silly things ;)
>>>       >
>>>       >         And as far as your "register the thing twice" worry...
>>>       >         rhetorically, what stops them from calling:
>>>       >
>>>       >         reg.register( "abc", MySync.INSTANCE )
>>>       >         reg.register( "123", MySync.INSTANCE )
>>>       >
>>>       >         Nothing.
>>>       >
>>>       >
>>>       >             I'd rather expose a single consistent way: having to
>>>      make up
>>>       >             an id
>>>       >             doesn't seem too inconvenient considering it's an SPI.
>>>       >
>>>       >
>>>       >         Well, again, I don't see how KeyableSynchronization is a
>>>       >         "inconsistent" approach.  In fact out of the 2, it is my
>>>      preferance.
>>>       >
>>>
>>>      --
>>>      Registered in England and Wales under Company Registration No.
>>> 03798903
>>>      Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>>>
>> --
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From yoann at hibernate.org  Thu Oct 26 09:06:25 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Thu, 26 Oct 2017 15:06:25 +0200
Subject: [hibernate-dev] Bugfix releases for Hibernate Search 5.6,
	5.7 and 5.8
Message-ID: <CAEqagppyMiq-nK3ZKWv2Rugno5tsZKX8kYik4ibWUpd0ihWRUA@mail.gmail.com>

Hi all,

We just published three bugfix releases of Hibernate Search: 5.6.4.Final
and 5.7.3.Final and 5.8.2.Final.

Please see the blog for more details: http://in.relation.
to/2017/10/26/hibernate-search-5-6-4-and-5-7-3-and-5-8-2/

Thanks,

Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org

From sanne at hibernate.org  Thu Oct 26 09:22:50 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Oct 2017 14:22:50 +0100
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
Message-ID: <CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>

Thanks, I had the same on my TODO list. Are you going to convert the
HipChat team?

That way we *could* all try it out, on the other hand since we have no
choice we don't really need to evaluate it :D

On 24 October 2017 at 19:34, Steve Ebersole <steve at hibernate.org> wrote:
> I've signed up for a "test drive" account on Atlassian's Stride server.
> Stride is their replacement for HipChat.
>
> ---------- Forwarded message ---------
> From: Stride by Atlassian <help at stride.com>
> Date: Tue, Oct 24, 2017, 1:32 PM
> Subject: You're on the Stride waitlist!
> To: <steve at hibernate.org>
>
>
>
> [image: Stride by Atlassian]
>
> Nice! You're on the list!
> [image: Stride waitlist]
> Thanks for your interest in Stride!
> What is Stride?
> Stride is a complete communication solution that empowers teams to talk
> less and do more. Stride provides teams with group messaging, video
> meetings & built-in collaboration tools. We are rolling Stride out during
> our Early Access Program and very excited for you and your team to try it!
> When will I get on Stride?
> When it's your turn, we'll reach out again to get your team started. You'll
> be able to create a new team or upgrade an existing HipChat team. Get
> answers to most of your questions on our FAQs
> <https://confluence.atlassian.com/display/STRIDE/Stride+documentation?&utm_source=prefinery&utm_medium=email&utm_campaign=waitlist-confirmation>
> .
> Thanks for your support! We can't wait to see your team hit its stride.
> Cheers,
> The Stride Team
>
> Copyright 2017 Atlassian Pty Ltd. All rights reserved. We are located at 341
> George Street, Sydney, NSW, 2000, Australia
> <https://maps.google.com/?q=341+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g>
>
>
> Don't want to receive amazing emails from us? Unsubscribe
> <https://i.prefinery.com/projects/ykmtf4f9/users/be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Oct 26 09:45:25 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 26 Oct 2017 13:45:25 +0000
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
Message-ID: <CAFdSV9tbSa1BmUP18uz4H4iF=167uWM2oEBgoHm6nbFeLdfuTw@mail.gmail.com>

Right, ultimately we won't have a choice.. they will simply be moving all
HipChat cloud instances to Stride Cloud.

I signed up for the EAP so that we can get involved in providing any
feedback we deem important prior to that launch.  After we are moved off
waitlist ofc.

On Thu, Oct 26, 2017 at 8:23 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Thanks, I had the same on my TODO list. Are you going to convert the
> HipChat team?
>
> That way we *could* all try it out, on the other hand since we have no
> choice we don't really need to evaluate it :D
>
> On 24 October 2017 at 19:34, Steve Ebersole <steve at hibernate.org> wrote:
> > I've signed up for a "test drive" account on Atlassian's Stride server.
> > Stride is their replacement for HipChat.
> >
> > ---------- Forwarded message ---------
> > From: Stride by Atlassian <help at stride.com>
> > Date: Tue, Oct 24, 2017, 1:32 PM
> > Subject: You're on the Stride waitlist!
> > To: <steve at hibernate.org>
> >
> >
> >
> > [image: Stride by Atlassian]
> >
> > Nice! You're on the list!
> > [image: Stride waitlist]
> > Thanks for your interest in Stride!
> > What is Stride?
> > Stride is a complete communication solution that empowers teams to talk
> > less and do more. Stride provides teams with group messaging, video
> > meetings & built-in collaboration tools. We are rolling Stride out during
> > our Early Access Program and very excited for you and your team to try
> it!
> > When will I get on Stride?
> > When it's your turn, we'll reach out again to get your team started.
> You'll
> > be able to create a new team or upgrade an existing HipChat team. Get
> > answers to most of your questions on our FAQs
> > <
> https://confluence.atlassian.com/display/STRIDE/Stride+documentation?&utm_source=prefinery&utm_medium=email&utm_campaign=waitlist-confirmation
> >
> > .
> > Thanks for your support! We can't wait to see your team hit its stride.
> > Cheers,
> > The Stride Team
> >
> > Copyright 2017 Atlassian Pty Ltd. All rights reserved. We are located
> <https://maps.google.com/?q=ian+Pty+Ltd.+All+rights+reserved.+We+are+located&entry=gmail&source=g>
> at 341
> > George Street, Sydney, NSW, 2000, Australia
> > <
> https://maps.google.com/?q=341+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g
> >
> >
> >
> > Don't want to receive amazing emails from us? Unsubscribe
> > <
> https://i.prefinery.com/projects/ykmtf4f9/users/be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Oct 26 09:55:16 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Oct 2017 14:55:16 +0100
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <CAFdSV9tbSa1BmUP18uz4H4iF=167uWM2oEBgoHm6nbFeLdfuTw@mail.gmail.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<CAFdSV9tbSa1BmUP18uz4H4iF=167uWM2oEBgoHm6nbFeLdfuTw@mail.gmail.com>
Message-ID: <CAFm4XO3EkrrADNDBpc0ShJsWd09WegvnBd9v8jzRs3ES3wKyEA@mail.gmail.com>

On 26 October 2017 at 14:45, Steve Ebersole <steve at hibernate.org> wrote:
> Right, ultimately we won't have a choice.. they will simply be moving all
> HipChat cloud instances to Stride Cloud.
>
> I signed up for the EAP so that we can get involved in providing any
> feedback we deem important prior to that launch.  After we are moved off
> waitlist ofc.

Ah, I missed we were still on some wait list. I assume when it's our
turn you'll convert the group so we can all have some fun with it?

Thanks

>
> On Thu, Oct 26, 2017 at 8:23 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Thanks, I had the same on my TODO list. Are you going to convert the
>> HipChat team?
>>
>> That way we *could* all try it out, on the other hand since we have no
>> choice we don't really need to evaluate it :D
>>
>> On 24 October 2017 at 19:34, Steve Ebersole <steve at hibernate.org> wrote:
>> > I've signed up for a "test drive" account on Atlassian's Stride server.
>> > Stride is their replacement for HipChat.
>> >
>> > ---------- Forwarded message ---------
>> > From: Stride by Atlassian <help at stride.com>
>> > Date: Tue, Oct 24, 2017, 1:32 PM
>> > Subject: You're on the Stride waitlist!
>> > To: <steve at hibernate.org>
>> >
>> >
>> >
>> > [image: Stride by Atlassian]
>> >
>> > Nice! You're on the list!
>> > [image: Stride waitlist]
>> > Thanks for your interest in Stride!
>> > What is Stride?
>> > Stride is a complete communication solution that empowers teams to talk
>> > less and do more. Stride provides teams with group messaging, video
>> > meetings & built-in collaboration tools. We are rolling Stride out
>> > during
>> > our Early Access Program and very excited for you and your team to try
>> > it!
>> > When will I get on Stride?
>> > When it's your turn, we'll reach out again to get your team started.
>> > You'll
>> > be able to create a new team or upgrade an existing HipChat team. Get
>> > answers to most of your questions on our FAQs
>> >
>> > <https://confluence.atlassian.com/display/STRIDE/Stride+documentation?&utm_source=prefinery&utm_medium=email&utm_campaign=waitlist-confirmation>
>> > .
>> > Thanks for your support! We can't wait to see your team hit its stride.
>> > Cheers,
>> > The Stride Team
>> >
>> > Copyright 2017 Atlassian Pty Ltd. All rights reserved. We are located at
>> > 341
>> > George Street, Sydney, NSW, 2000, Australia
>> >
>> > <https://maps.google.com/?q=341+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g>
>> >
>> >
>> > Don't want to receive amazing emails from us? Unsubscribe
>> >
>> > <https://i.prefinery.com/projects/ykmtf4f9/users/be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Oct 26 10:02:51 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 26 Oct 2017 14:02:51 +0000
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <CAFm4XO3EkrrADNDBpc0ShJsWd09WegvnBd9v8jzRs3ES3wKyEA@mail.gmail.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<CAFdSV9tbSa1BmUP18uz4H4iF=167uWM2oEBgoHm6nbFeLdfuTw@mail.gmail.com>
	<CAFm4XO3EkrrADNDBpc0ShJsWd09WegvnBd9v8jzRs3ES3wKyEA@mail.gmail.com>
Message-ID: <CAFdSV9tR988OU9Tb0Wqu=0to+Gg0MX9KvQ7A_wnUCyUXNq4Zng@mail.gmail.com>

The wait list here specifically is for access to an EAP instance that is
essentially a sandbox.  It will not import our existing messages, etc.  It
will be an empty instance we can play with.  I am not sure how teams work
there, but the email I got implies that we ought to be able to somehow
replicate the team there.  But again, nothing here is permanent.

This is in contrast to the "wait list" we are all on where Atlassian will
begin migrating HipChat Cloud teams over to Stride.  That *will* migrate
our history, teams, etc.  The email said that will happen within the next 6
months.

HTH

On Thu, Oct 26, 2017 at 8:56 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 26 October 2017 at 14:45, Steve Ebersole <steve at hibernate.org> wrote:
> > Right, ultimately we won't have a choice.. they will simply be moving all
> > HipChat cloud instances to Stride Cloud.
> >
> > I signed up for the EAP so that we can get involved in providing any
> > feedback we deem important prior to that launch.  After we are moved off
> > waitlist ofc.
>
> Ah, I missed we were still on some wait list. I assume when it's our
> turn you'll convert the group so we can all have some fun with it?
>
> Thanks
>
> >
> > On Thu, Oct 26, 2017 at 8:23 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> Thanks, I had the same on my TODO list. Are you going to convert the
> >> HipChat team?
> >>
> >> That way we *could* all try it out, on the other hand since we have no
> >> choice we don't really need to evaluate it :D
> >>
> >> On 24 October 2017 at 19:34, Steve Ebersole <steve at hibernate.org>
> wrote:
> >> > I've signed up for a "test drive" account on Atlassian's Stride
> server.
> >> > Stride is their replacement for HipChat.
> >> >
> >> > ---------- Forwarded message ---------
> >> > From: Stride by Atlassian <help at stride.com>
> >> > Date: Tue, Oct 24, 2017, 1:32 PM
> >> > Subject: You're on the Stride waitlist!
> >> > To: <steve at hibernate.org>
> >> >
> >> >
> >> >
> >> > [image: Stride by Atlassian]
> >> >
> >> > Nice! You're on the list!
> >> > [image: Stride waitlist]
> >> > Thanks for your interest in Stride!
> >> > What is Stride?
> >> > Stride is a complete communication solution that empowers teams to
> talk
> >> > less and do more. Stride provides teams with group messaging, video
> >> > meetings & built-in collaboration tools. We are rolling Stride out
> >> > during
> >> > our Early Access Program and very excited for you and your team to try
> >> > it!
> >> > When will I get on Stride?
> >> > When it's your turn, we'll reach out again to get your team started.
> >> > You'll
> >> > be able to create a new team or upgrade an existing HipChat team. Get
> >> > answers to most of your questions on our FAQs
> >> >
> >> > <
> https://confluence.atlassian.com/display/STRIDE/Stride+documentation?&utm_source=prefinery&utm_medium=email&utm_campaign=waitlist-confirmation
> >
> >> > .
> >> > Thanks for your support! We can't wait to see you
> <https://maps.google.com/?q=hanks+for+your+support!+We+can't+wait+to+see+you&entry=gmail&source=g>r
> team hit its stride.
> >> > Cheers,
> >> > The Stride Team
> >> >
> >> > Copyright 2017 Atlassian Pty Ltd. All rights reserved. We are located
> at
> >> > 341
> >> > George Street, Sydney, NSW, 2000, Australia
> >> >
> >> > <
> https://maps.google.com/?q=341+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g
> >
> >> >
> >> >
> >> > Don't want to receive amazing emails from us? Unsubscribe
> >> >
> >> > <
> https://i.prefinery.com/projects/ykmtf4f9/users/be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe
> >
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From robert at marcanoonline.com  Thu Oct 26 10:40:07 2017
From: robert at marcanoonline.com (Robert Marcano)
Date: Thu, 26 Oct 2017 10:40:07 -0400
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
Message-ID: <e610bde9-86e6-5313-4808-82e510f93dc6@marcanoonline.com>

On 10/26/2017 09:22 AM, Sanne Grinovero wrote:
> Thanks, I had the same on my TODO list. Are you going to convert the
> HipChat team?

Just out of curiosity from someone that has just 2 weeks subscribed to 
this mailing list. Why not try Riot/Matrix http://riot.im/ ?

> 
> That way we *could* all try it out, on the other hand since we have no
> choice we don't really need to evaluate it :D
> 
> On 24 October 2017 at 19:34, Steve Ebersole <steve at hibernate.org> wrote:
>> I've signed up for a "test drive" account on Atlassian's Stride server.
>> Stride is their replacement for HipChat.
>>
>> ---------- Forwarded message ---------
>> From: Stride by Atlassian <help at stride.com>
>> Date: Tue, Oct 24, 2017, 1:32 PM
>> Subject: You're on the Stride waitlist!
>> To: <steve at hibernate.org>
>>
>>
>>
>> [image: Stride by Atlassian]
>>
>> Nice! You're on the list!
>> [image: Stride waitlist]
>> Thanks for your interest in Stride!
>> What is Stride?
>> Stride is a complete communication solution that empowers teams to talk
>> less and do more. Stride provides teams with group messaging, video
>> meetings & built-in collaboration tools. We are rolling Stride out during
>> our Early Access Program and very excited for you and your team to try it!
>> When will I get on Stride?
>> When it's your turn, we'll reach out again to get your team started. You'll
>> be able to create a new team or upgrade an existing HipChat team. Get
>> answers to most of your questions on our FAQs
>> <https://confluence.atlassian.com/display/STRIDE/Stride+documentation?&utm_source=prefinery&utm_medium=email&utm_campaign=waitlist-confirmation>
>> .
>> Thanks for your support! We can't wait to see your team hit its stride.
>> Cheers,
>> The Stride Team
>>
>> Copyright 2017 Atlassian Pty Ltd. All rights reserved. We are located at 341
>> George Street, Sydney, NSW, 2000, Australia
>> <https://maps.google.com/?q=341+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g>
>>
>>
>> Don't want to receive amazing emails from us? Unsubscribe
>> <https://i.prefinery.com/projects/ykmtf4f9/users/be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe>
>> _______________________________________________
>> 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 Oct 26 10:52:25 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 26 Oct 2017 16:52:25 +0200
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <CAFdSV9tbSa1BmUP18uz4H4iF=167uWM2oEBgoHm6nbFeLdfuTw@mail.gmail.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<CAFdSV9tbSa1BmUP18uz4H4iF=167uWM2oEBgoHm6nbFeLdfuTw@mail.gmail.com>
Message-ID: <CADGJaX9r9hdBG3MLEB8b61reX_Sfq9aZDYGR9q8PYz0ckhn2yg@mail.gmail.com>

Does anyone know whether our chat histories will be transferred?

I remember we got upgraded to some pro plan on HipChat at some point,
allowing for unlimited history access (unlike with the basis plan). Will we
have the same on Stride?

2017-10-26 15:45 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Right, ultimately we won't have a choice.. they will simply be moving all
> HipChat cloud instances to Stride Cloud.
>
> I signed up for the EAP so that we can get involved in providing any
> feedback we deem important prior to that launch.  After we are moved off
> waitlist ofc.
>
> On Thu, Oct 26, 2017 at 8:23 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > Thanks, I had the same on my TODO list. Are you going to convert the
> > HipChat team?
> >
> > That way we *could* all try it out, on the other hand since we have no
> > choice we don't really need to evaluate it :D
> >
> > On 24 October 2017 at 19:34, Steve Ebersole <steve at hibernate.org> wrote:
> > > I've signed up for a "test drive" account on Atlassian's Stride server.
> > > Stride is their replacement for HipChat.
> > >
> > > ---------- Forwarded message ---------
> > > From: Stride by Atlassian <help at stride.com>
> > > Date: Tue, Oct 24, 2017, 1:32 PM
> > > Subject: You're on the Stride waitlist!
> > > To: <steve at hibernate.org>
> > >
> > >
> > >
> > > [image: Stride by Atlassian]
> > >
> > > Nice! You're on the list!
> > > [image: Stride waitlist]
> > > Thanks for your interest in Stride!
> > > What is Stride?
> > > Stride is a complete communication solution that empowers teams to talk
> > > less and do more. Stride provides teams with group messaging, video
> > > meetings & built-in collaboration tools. We are rolling Stride out
> during
> > > our Early Access Program and very excited for you and your team to try
> > it!
> > > When will I get on Stride?
> > > When it's your turn, we'll reach out again to get your team started.
> > You'll
> > > be able to create a new team or upgrade an existing HipChat team. Get
> > > answers to most of your questions on our FAQs
> > > <
> > https://confluence.atlassian.com/display/STRIDE/Stride+
> documentation?&utm_source=prefinery&utm_medium=email&
> utm_campaign=waitlist-confirmation
> > >
> > > .
> > > Thanks for your support! We can't wait to see your team hit its stride.
> > > Cheers,
> > > The Stride Team
> > >
> > > Copyright 2017 Atlassian Pty Ltd. All rights reserved. We are located
> > <https://maps.google.com/?q=ian+Pty+Ltd.+All+rights+
> reserved.+We+are+located&entry=gmail&source=g>
> > at 341
> > > George Street, Sydney, NSW, 2000, Australia
> > > <
> > https://maps.google.com/?q=341+George+Street,+Sydney,+
> NSW,+2000,+Australia&entry=gmail&source=g
> > >
> > >
> > >
> > > Don't want to receive amazing emails from us? Unsubscribe
> > > <
> > https://i.prefinery.com/projects/ykmtf4f9/users/be9ecc46-2b3d-4352-a542-
> 57add9ca10c7/unsubscribe
> > >
> > > _______________________________________________
> > > 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  Thu Oct 26 10:54:20 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Oct 2017 15:54:20 +0100
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <CADGJaX9r9hdBG3MLEB8b61reX_Sfq9aZDYGR9q8PYz0ckhn2yg@mail.gmail.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<CAFdSV9tbSa1BmUP18uz4H4iF=167uWM2oEBgoHm6nbFeLdfuTw@mail.gmail.com>
	<CADGJaX9r9hdBG3MLEB8b61reX_Sfq9aZDYGR9q8PYz0ckhn2yg@mail.gmail.com>
Message-ID: <CAFm4XO24J1PrfbAb=gJzUvzX1AwSWJ+kDoC3jrL=4X_aoMta9g@mail.gmail.com>

On 26 October 2017 at 15:52, Gunnar Morling <gunnar at hibernate.org> wrote:
> Does anyone know whether our chat histories will be transferred?

Their FAQ states they will stransfer everything, so I'm crossing fingers..

From steve at hibernate.org  Thu Oct 26 11:48:31 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 26 Oct 2017 15:48:31 +0000
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <CAFm4XO24J1PrfbAb=gJzUvzX1AwSWJ+kDoC3jrL=4X_aoMta9g@mail.gmail.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<CAFdSV9tbSa1BmUP18uz4H4iF=167uWM2oEBgoHm6nbFeLdfuTw@mail.gmail.com>
	<CADGJaX9r9hdBG3MLEB8b61reX_Sfq9aZDYGR9q8PYz0ckhn2yg@mail.gmail.com>
	<CAFm4XO24J1PrfbAb=gJzUvzX1AwSWJ+kDoC3jrL=4X_aoMta9g@mail.gmail.com>
Message-ID: <CAFdSV9seYNQ2vO_K7HmH577QGomp7BOea0Kh49d0qvkJVjg8MQ@mail.gmail.com>

Again, for the EAP no.

For the real migration (~6 months) yes

On Thu, Oct 26, 2017 at 9:54 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 26 October 2017 at 15:52, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Does anyone know whether our chat histories will be transferred?
>
> Their FAQ states they will stransfer everything, so I'm crossing fingers..
>

From steve at hibernate.org  Thu Oct 26 12:03:41 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 26 Oct 2017 16:03:41 +0000
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <e610bde9-86e6-5313-4808-82e510f93dc6@marcanoonline.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<e610bde9-86e6-5313-4808-82e510f93dc6@marcanoonline.com>
Message-ID: <CAFdSV9twQx9fRvHTkFjxSWH1TkGa46jXE-Awd8sdSobsF8j4xw@mail.gmail.com>

Why would we?  What's the benefit over what we have?



On Thu, Oct 26, 2017 at 10:52 AM Robert Marcano <robert at marcanoonline.com>
wrote:

> On 10/26/2017 09:22 AM, Sanne Grinovero wrote:
> > Thanks, I had the same on my TODO list. Are you going to convert the
> > HipChat team?
>
> Just out of curiosity from someone that has just 2 weeks subscribed to
> this mailing list. Why not try Riot/Matrix http://riot.im/ ?
>
> >
> > That way we *could* all try it out, on the other hand since we have no
> > choice we don't really need to evaluate it :D
> >
> > On 24 October 2017 at 19:34, Steve Ebersole <steve at hibernate.org> wrote:
> >> I've signed up for a "test drive" account on Atlassian's Stride server.
> >> Stride is their replacement for HipChat.
> >>
> >> ---------- Forwarded message ---------
> >> From: Stride by Atlassian <help at stride.com>
> >> Date: Tue, Oct 24, 2017, 1:32 PM
> >> Subject: You're on the Stride waitlist!
> >> To: <steve at hibernate.org>
> >>
> >>
> >>
> >> [image: Stride by Atlassian]
> >>
> >> Nice! You're on the list!
> >> [image: Stride waitlist]
> >> Thanks for your interest in Stride!
> >> What is Stride?
> >> Stride is a complete communication solution that empowers teams to talk
> >> less and do more. Stride provides teams with group messaging, video
> >> meetings & built-in collaboration tools. We are rolling Stride out
> during
> >> our Early Access Program and very excited for you and your team to try
> it!
> >> When will I get on Stride?
> >> When it's your turn, we'll reach out again to get your team started.
> You'll
> >> be able to create a new team or upgrade an existing HipChat team. Get
> >> answers to most of your questions on our FAQs
> >> <
> https://confluence.atlassian.com/display/STRIDE/Stride+documentation?&utm_source=prefinery&utm_medium=email&utm_campaign=waitlist-confirmation
> >
> >> .
> >> Thanks for your support! We can't wait to see your team hit its stride.
> >> Cheers,
> >> The Stride Team
> >>
> >> Copyright 2017 Atlassian Pty Ltd. All rights reserved. We are located
> at 341
> >> George Street, Sydney, NSW, 2000, Australia
> >> <
> https://maps.google.com/?q=341+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g
> >
> >>
> >>
> >> Don't want to receive amazing emails from us? Unsubscribe
> >> <
> https://i.prefinery.com/projects/ykmtf4f9/users/be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe
> >
> >> _______________________________________________
> >> 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  Thu Oct 26 12:06:19 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Oct 2017 17:06:19 +0100
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <e610bde9-86e6-5313-4808-82e510f93dc6@marcanoonline.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<e610bde9-86e6-5313-4808-82e510f93dc6@marcanoonline.com>
Message-ID: <CAFm4XO1tjYgGW0Wb2xP8nKrq0hHkD7wSXwdeT=j1Acb0gYYsGA@mail.gmail.com>

On 26 October 2017 at 15:40, Robert Marcano <robert at marcanoonline.com> wrote:
> On 10/26/2017 09:22 AM, Sanne Grinovero wrote:
>> Thanks, I had the same on my TODO list. Are you going to convert the
>> HipChat team?
>
> Just out of curiosity from someone that has just 2 weeks subscribed to
> this mailing list. Why not try Riot/Matrix http://riot.im/ ?

Hi Robert, welcome!

The main reason is we never heard of that until today :)
But also that we've already been using HipChat and quite like its
focus on developers; not surprising since we're also fans of JIRA.

So Atlassian is "upgrading" all HipChat users to Stride and we'll just
hope it wil be great. If it will be a disaster we'll keep Riot on the
list of alternative candidates.. thanks for the suggestion.

Sanne

>>
>> That way we *could* all try it out, on the other hand since we have no
>> choice we don't really need to evaluate it :D
>>
>> On 24 October 2017 at 19:34, Steve Ebersole <steve at hibernate.org> wrote:
>>> I've signed up for a "test drive" account on Atlassian's Stride server.
>>> Stride is their replacement for HipChat.
>>>
>>> ---------- Forwarded message ---------
>>> From: Stride by Atlassian <help at stride.com>
>>> Date: Tue, Oct 24, 2017, 1:32 PM
>>> Subject: You're on the Stride waitlist!
>>> To: <steve at hibernate.org>
>>>
>>>
>>>
>>> [image: Stride by Atlassian]
>>>
>>> Nice! You're on the list!
>>> [image: Stride waitlist]
>>> Thanks for your interest in Stride!
>>> What is Stride?
>>> Stride is a complete communication solution that empowers teams to talk
>>> less and do more. Stride provides teams with group messaging, video
>>> meetings & built-in collaboration tools. We are rolling Stride out during
>>> our Early Access Program and very excited for you and your team to try it!
>>> When will I get on Stride?
>>> When it's your turn, we'll reach out again to get your team started. You'll
>>> be able to create a new team or upgrade an existing HipChat team. Get
>>> answers to most of your questions on our FAQs
>>> <https://confluence.atlassian.com/display/STRIDE/Stride+documentation?&utm_source=prefinery&utm_medium=email&utm_campaign=waitlist-confirmation>
>>> .
>>> Thanks for your support! We can't wait to see your team hit its stride.
>>> Cheers,
>>> The Stride Team
>>>
>>> Copyright 2017 Atlassian Pty Ltd. All rights reserved. We are located at 341
>>> George Street, Sydney, NSW, 2000, Australia
>>> <https://maps.google.com/?q=341+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g>
>>>
>>>
>>> Don't want to receive amazing emails from us? Unsubscribe
>>> <https://i.prefinery.com/projects/ykmtf4f9/users/be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe>
>>> _______________________________________________
>>> 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 robert at marcanoonline.com  Thu Oct 26 12:20:30 2017
From: robert at marcanoonline.com (Robert Marcano)
Date: Thu, 26 Oct 2017 12:20:30 -0400
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <CAFdSV9twQx9fRvHTkFjxSWH1TkGa46jXE-Awd8sdSobsF8j4xw@mail.gmail.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<e610bde9-86e6-5313-4808-82e510f93dc6@marcanoonline.com>
	<CAFdSV9twQx9fRvHTkFjxSWH1TkGa46jXE-Awd8sdSobsF8j4xw@mail.gmail.com>
Message-ID: <c91404b2-6ebe-3ccd-b62c-fec845a858af@marcanoonline.com>

On 10/26/2017 12:03 PM, Steve Ebersole wrote:
> Why would we?? What's the benefit over what we have?
> 
> 

As someone that jumps from forums to forums when need to discuss bugs 
outside bug reports systems, the lack of anonymous access to HipChat 
discouraged me multiple times to join. Not because anonymity was 
important, just tired of creating accounts for a few days usage in 
another service. Just my 2 cents.

There are other advantages but are more "political" than practical (OSS, 
federated, etc).

> 
> On Thu, Oct 26, 2017 at 10:52 AM Robert Marcano 
> <robert at marcanoonline.com <mailto:robert at marcanoonline.com>> wrote:
> 
>     On 10/26/2017 09:22 AM, Sanne Grinovero wrote:
>      > Thanks, I had the same on my TODO list. Are you going to convert the
>      > HipChat team?
> 
>     Just out of curiosity from someone that has just 2 weeks subscribed to
>     this mailing list. Why not try Riot/Matrix http://riot.im/ ?
> 
>      >
>      > That way we *could* all try it out, on the other hand since we
>     have no
>      > choice we don't really need to evaluate it :D
>      >
>      > On 24 October 2017 at 19:34, Steve Ebersole <steve at hibernate.org
>     <mailto:steve at hibernate.org>> wrote:
>      >> I've signed up for a "test drive" account on Atlassian's Stride
>     server.
>      >> Stride is their replacement for HipChat.
>      >>
>      >> ---------- Forwarded message ---------
>      >> From: Stride by Atlassian <help at stride.com <mailto:help at stride.com>>
>      >> Date: Tue, Oct 24, 2017, 1:32 PM
>      >> Subject: You're on the Stride waitlist!
>      >> To: <steve at hibernate.org <mailto:steve at hibernate.org>>
>      >>
>      >>
>      >>
>      >> [image: Stride by Atlassian]
>      >>
>      >> Nice! You're on the list!
>      >> [image: Stride waitlist]
>      >> Thanks for your interest in Stride!
>      >> What is Stride?
>      >> Stride is a complete communication solution that empowers teams
>     to talk
>      >> less and do more. Stride provides teams with group messaging, video
>      >> meetings & built-in collaboration tools. We are rolling Stride
>     out during
>      >> our Early Access Program and very excited for you and your team
>     to try it!
>      >> When will I get on Stride?
>      >> When it's your turn, we'll reach out again to get your team
>     started. You'll
>      >> be able to create a new team or upgrade an existing HipChat
>     team. Get
>      >> answers to most of your questions on our FAQs
>      >>
>     <https://confluence.atlassian.com/display/STRIDE/Stride+documentation?&utm_source=prefinery&utm_medium=email&utm_campaign=waitlist-confirmation>
>      >> .
>      >> Thanks for your support! We can't wait to see your team hit its
>     stride.
>      >> Cheers,
>      >> The Stride Team
>      >>
>      >> Copyright 2017 Atlassian Pty Ltd. All rights reserved. We are
>     located at 341
>      >> George Street, Sydney, NSW, 2000, Australia
>      >>
>     <https://maps.google.com/?q=341+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g>
>      >>
>      >>
>      >> Don't want to receive amazing emails from us? Unsubscribe
>      >>
>     <https://i.prefinery.com/projects/ykmtf4f9/users/be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe>
>      >> _______________________________________________
>      >> 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
>      >
> 
>     _______________________________________________
>     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  Thu Oct 26 15:40:48 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 26 Oct 2017 19:40:48 +0000
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <c91404b2-6ebe-3ccd-b62c-fec845a858af@marcanoonline.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<e610bde9-86e6-5313-4808-82e510f93dc6@marcanoonline.com>
	<CAFdSV9twQx9fRvHTkFjxSWH1TkGa46jXE-Awd8sdSobsF8j4xw@mail.gmail.com>
	<c91404b2-6ebe-3ccd-b62c-fec845a858af@marcanoonline.com>
Message-ID: <CAFdSV9sM+ZVM3iev7TBSe5rOYx4_1rTxpZ94kZOAdQK5pDFNBw@mail.gmail.com>

I can understand that.

There is a room in our HipChat that we allow anonymous/guest access, no
need for an account.  The only thing you lose is the ability to see
history.  But I think that's a reasonable expectation.  Have you tried that
approach?  http://hibernate.hipchat.com/chat/room/3369275

On Thu, Oct 26, 2017 at 1:25 PM Robert Marcano <robert at marcanoonline.com>
wrote:

> On 10/26/2017 12:03 PM, Steve Ebersole wrote:
> > Why would we?  What's the benefit over what we have?
> >
> >
>
> As someone that jumps from forums to forums when need to discuss bugs
> outside bug reports systems, the lack of anonymous access to HipChat
> discouraged me multiple times to join. Not because anonymity was
> important, just tired of creating accounts for a few days usage in
> another service. Just my 2 cents.
>
> There are other advantages but are more "political" than practical (OSS,
> federated, etc).
>
> >
> > On Thu, Oct 26, 2017 at 10:52 AM Robert Marcano
> > <robert at marcanoonline.com <mailto:robert at marcanoonline.com>> wrote:
> >
> >     On 10/26/2017 09:22 AM, Sanne Grinovero wrote:
> >      > Thanks, I had the same on my TODO list. Are you going to convert
> the
> >      > HipChat team?
> >
> >     Just out of curiosity from someone that has just 2 weeks subscribed
> to
> >     this mailing list. Why not try Riot/Matrix http://riot.im/ ?
> >
> >      >
> >      > That way we *could* all try it out, on the other hand since we
> >     have no
> >      > choice we don't really need to evaluate it :D
> >      >
> >      > On 24 October 2017 at 19:34, Steve Ebersole <steve at hibernate.org
> >     <mailto:steve at hibernate.org>> wrote:
> >      >> I've signed up for a "test drive" account on Atlassian's Stride
> >     server.
> >      >> Stride is their replacement for HipChat.
> >      >>
> >      >> ---------- Forwarded message ---------
> >      >> From: Stride by Atlassian <help at stride.com <mailto:
> help at stride.com>>
> >      >> Date: Tue, Oct 24, 2017, 1:32 PM
> >      >> Subject: You're on the Stride waitlist!
> >      >> To: <steve at hibernate.org <mailto:steve at hibernate.org>>
> >      >>
> >      >>
> >      >>
> >      >> [image: Stride by Atlassian]
> >      >>
> >      >> Nice! You're on the list!
> >      >> [image: Stride waitlist]
> >      >> Thanks for your interest in Stride!
> >      >> What is Stride?
> >      >> Stride is a complete communication solution that empowers teams
> >     to talk
> >      >> less and do more. Stride provides teams with group messaging,
> video
> >      >> meetings & built-in collaboration tools. We are rolling Stride
> >     out during
> >      >> our Early Access Program and very excited for you and your team
> >     to try it!
> >      >> When will I get on Stride?
> >      >> When it's your turn, we'll reach out again to get your team
> >     started. You'll
> >      >> be able to create a new team or upgrade an existing HipChat
> >     team. Get
> >      >> answers to most of your questions on our FAQs
> >      >>
> >     <
> https://confluence.atlassian.com/display/STRIDE/Stride+documentation?&utm_source=prefinery&utm_medium=email&utm_campaign=waitlist-confirmation
> >
> >      >> .
> >      >> Thanks for your support! We can't wait to see your team hit its
> >     stride.
> >      >> Cheers,
> >      >> The Stride Team
> >      >>
> >      >> Copyright 2017 Atlassian Pty Ltd. All rights reserved. We are
> >     located at 341
> >      >> George Street, Sydney, NSW, 2000, Australia
> >      >>
> >     <
> https://maps.google.com/?q=341+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g
> >
> >      >>
> >      >>
> >      >> Don't want to receive amazing emails from us? Unsubscribe
> >      >>
> >     <
> https://i.prefinery.com/projects/ykmtf4f9/users/be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe
> >
> >      >> _______________________________________________
> >      >> 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
> >      >
> >
> >     _______________________________________________
> >     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
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From rory.odonnell at oracle.com  Fri Oct 27 04:52:48 2017
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 27 Oct 2017 09:52:48 +0100
Subject: [hibernate-dev] JDK 8u162 b01 Early Access is available on
	jdk.java.net
Message-ID: <a2553185-ac3d-e065-cc70-a66c2a6ba767@oracle.com>

Hi Sanne,

*JDK 8u162 Early Access*? build 01 is available at : - jdk.java.net/8/ 
<http://jdk.java.net/8/>

Information and schedules specific to OpenJDK 8u162 release are listed 
here <http://openjdk.java.net/projects/jdk8u/releases/8u162.html>


<http://openjdk.java.net/projects/jdk8u/releases/8u162.html>

*JRE and JDK Cryptographic Roadmap* has been updated the details are 
here <https://www.java.com/en/jre-jdk-cryptoroadmap.html>

**

*JavaOne2017* took place October 1 to 5, 2017 at San Francisco.

If you were unable to attend the event or missed some talks, below you 
will find links to keynotes from last week
that have been posted for on-demand replay:

  * JavaOne Opening Keynote (Monday, Oct. 2):
      o https://www.oracle.com/javaone/on-demand.html?bcid=5596229112001
  * Oracle Code Keynote (Tuesday, Oct. 3):
      o https://www.oracle.com/javaone/on-demand.html?bcid=5600354378001
  * JavaOne Community Keynote (Thursday, Oct. 5):
      o https://www.oracle.com/javaone/on-demand.html?bcid=5604479599001


Regards,
Rory

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


From sanne at hibernate.org  Fri Oct 27 04:59:26 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 27 Oct 2017 09:59:26 +0100
Subject: [hibernate-dev] JDK 8u162 b01 Early Access is available on
	jdk.java.net
In-Reply-To: <a2553185-ac3d-e065-cc70-a66c2a6ba767@oracle.com>
References: <a2553185-ac3d-e065-cc70-a66c2a6ba767@oracle.com>
Message-ID: <CAFm4XO3sDke0cZ6wXuND54TgvM0e9bzQqzdVCRw17x7EMndpFg@mail.gmail.com>

Thanks Rory,

we'll set this up for testing. I'm surprised the links actually don't
contain change details? That would be useful ..

Regards,
Sanne


On 27 October 2017 at 09:52, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
> Hi Sanne,
>
> *JDK 8u162 Early Access*  build 01 is available at : - jdk.java.net/8/
> <http://jdk.java.net/8/>
>
> Information and schedules specific to OpenJDK 8u162 release are listed
> here <http://openjdk.java.net/projects/jdk8u/releases/8u162.html>
>
>
> <http://openjdk.java.net/projects/jdk8u/releases/8u162.html>
>
> *JRE and JDK Cryptographic Roadmap* has been updated the details are
> here <https://www.java.com/en/jre-jdk-cryptoroadmap.html>
>
> **
>
> *JavaOne2017* took place October 1 to 5, 2017 at San Francisco.
>
> If you were unable to attend the event or missed some talks, below you
> will find links to keynotes from last week
> that have been posted for on-demand replay:
>
>   * JavaOne Opening Keynote (Monday, Oct. 2):
>       o https://www.oracle.com/javaone/on-demand.html?bcid=5596229112001
>   * Oracle Code Keynote (Tuesday, Oct. 3):
>       o https://www.oracle.com/javaone/on-demand.html?bcid=5600354378001
>   * JavaOne Community Keynote (Thursday, Oct. 5):
>       o https://www.oracle.com/javaone/on-demand.html?bcid=5604479599001
>
>
> Regards,
> Rory
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From rory.odonnell at oracle.com  Fri Oct 27 05:13:02 2017
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 27 Oct 2017 10:13:02 +0100
Subject: [hibernate-dev] JDK 8u162 b01 Early Access is available on
 jdk.java.net
In-Reply-To: <CAFm4XO3sDke0cZ6wXuND54TgvM0e9bzQqzdVCRw17x7EMndpFg@mail.gmail.com>
References: <a2553185-ac3d-e065-cc70-a66c2a6ba767@oracle.com>
	<CAFm4XO3sDke0cZ6wXuND54TgvM0e9bzQqzdVCRw17x7EMndpFg@mail.gmail.com>
Message-ID: <94ea7ac1-c343-5624-f8b8-12da8f9e2ede@oracle.com>

Hi Sanne,

This tends to be the case with build 01 for some reason, thanks.

Rgds,Rory


On 27/10/2017 09:59, Sanne Grinovero wrote:
> Thanks Rory,
>
> we'll set this up for testing. I'm surprised the links actually don't
> contain change details? That would be useful ..
>
> Regards,
> Sanne
>
>
> On 27 October 2017 at 09:52, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
>> Hi Sanne,
>>
>> *JDK 8u162 Early Access*  build 01 is available at : - jdk.java.net/8/
>> <http://jdk.java.net/8/>
>>
>> Information and schedules specific to OpenJDK 8u162 release are listed
>> here <http://openjdk.java.net/projects/jdk8u/releases/8u162.html>
>>
>>
>> <http://openjdk.java.net/projects/jdk8u/releases/8u162.html>
>>
>> *JRE and JDK Cryptographic Roadmap* has been updated the details are
>> here <https://www.java.com/en/jre-jdk-cryptoroadmap.html>
>>
>> **
>>
>> *JavaOne2017* took place October 1 to 5, 2017 at San Francisco.
>>
>> If you were unable to attend the event or missed some talks, below you
>> will find links to keynotes from last week
>> that have been posted for on-demand replay:
>>
>>    * JavaOne Opening Keynote (Monday, Oct. 2):
>>        o https://www.oracle.com/javaone/on-demand.html?bcid=5596229112001
>>    * Oracle Code Keynote (Tuesday, Oct. 3):
>>        o https://www.oracle.com/javaone/on-demand.html?bcid=5600354378001
>>    * JavaOne Community Keynote (Thursday, Oct. 5):
>>        o https://www.oracle.com/javaone/on-demand.html?bcid=5604479599001
>>
>>
>> Regards,
>> Rory
>>
>> --
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


From robert at marcanoonline.com  Fri Oct 27 09:10:07 2017
From: robert at marcanoonline.com (Robert Marcano)
Date: Fri, 27 Oct 2017 09:10:07 -0400
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <CAFdSV9sM+ZVM3iev7TBSe5rOYx4_1rTxpZ94kZOAdQK5pDFNBw@mail.gmail.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<e610bde9-86e6-5313-4808-82e510f93dc6@marcanoonline.com>
	<CAFdSV9twQx9fRvHTkFjxSWH1TkGa46jXE-Awd8sdSobsF8j4xw@mail.gmail.com>
	<c91404b2-6ebe-3ccd-b62c-fec845a858af@marcanoonline.com>
	<CAFdSV9sM+ZVM3iev7TBSe5rOYx4_1rTxpZ94kZOAdQK5pDFNBw@mail.gmail.com>
Message-ID: <84dd5012-d4ef-abdb-94e0-ea9c00699e8c@marcanoonline.com>

On 10/26/2017 03:40 PM, Steve Ebersole wrote:
> I can understand that.
> 
> There is a room in our HipChat that we allow?anonymous/guest access, no 
> need for an account.? The only thing you lose is the ability to see 
> history.? But I think that's a reasonable expectation.? Have you tried 
> that approach? http://hibernate.hipchat.com/chat/room/3369275

I don't see any options for anonymous logins there. It redirect to a 
login page with no options for a creating a new account either.

If I post an email address in order to check if it later allows to login 
anonymously or if it ask to create an account. It says:

"We don't recognize that email address"

> 
> On Thu, Oct 26, 2017 at 1:25 PM Robert Marcano <robert at marcanoonline.com 
> <mailto:robert at marcanoonline.com>> wrote:
> 
>     On 10/26/2017 12:03 PM, Steve Ebersole wrote:
>      > Why would we?? What's the benefit over what we have?
>      >
>      >
> 
>     As someone that jumps from forums to forums when need to discuss bugs
>     outside bug reports systems, the lack of anonymous access to HipChat
>     discouraged me multiple times to join. Not because anonymity was
>     important, just tired of creating accounts for a few days usage in
>     another service. Just my 2 cents.
> 
>     There are other advantages but are more "political" than practical (OSS,
>     federated, etc).
> 
>      >
>      > On Thu, Oct 26, 2017 at 10:52 AM Robert Marcano
>      > <robert at marcanoonline.com <mailto:robert at marcanoonline.com>
>     <mailto:robert at marcanoonline.com <mailto:robert at marcanoonline.com>>>
>     wrote:
>      >
>      >? ? ?On 10/26/2017 09:22 AM, Sanne Grinovero wrote:
>      >? ? ? > Thanks, I had the same on my TODO list. Are you going to
>     convert the
>      >? ? ? > HipChat team?
>      >
>      >? ? ?Just out of curiosity from someone that has just 2 weeks
>     subscribed to
>      >? ? ?this mailing list. Why not try Riot/Matrix http://riot.im/ ?
>      >
>      >? ? ? >
>      >? ? ? > That way we *could* all try it out, on the other hand since we
>      >? ? ?have no
>      >? ? ? > choice we don't really need to evaluate it :D
>      >? ? ? >
>      >? ? ? > On 24 October 2017 at 19:34, Steve Ebersole
>     <steve at hibernate.org <mailto:steve at hibernate.org>
>      >? ? ?<mailto:steve at hibernate.org <mailto:steve at hibernate.org>>> wrote:
>      >? ? ? >> I've signed up for a "test drive" account on Atlassian's
>     Stride
>      >? ? ?server.
>      >? ? ? >> Stride is their replacement for HipChat.
>      >? ? ? >>
>      >? ? ? >> ---------- Forwarded message ---------
>      >? ? ? >> From: Stride by Atlassian <help at stride.com
>     <mailto:help at stride.com> <mailto:help at stride.com
>     <mailto:help at stride.com>>>
>      >? ? ? >> Date: Tue, Oct 24, 2017, 1:32 PM
>      >? ? ? >> Subject: You're on the Stride waitlist!
>      >? ? ? >> To: <steve at hibernate.org <mailto:steve at hibernate.org>
>     <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>>
>      >? ? ? >>
>      >? ? ? >>
>      >? ? ? >>
>      >? ? ? >> [image: Stride by Atlassian]
>      >? ? ? >>
>      >? ? ? >> Nice! You're on the list!
>      >? ? ? >> [image: Stride waitlist]
>      >? ? ? >> Thanks for your interest in Stride!
>      >? ? ? >> What is Stride?
>      >? ? ? >> Stride is a complete communication solution that empowers
>     teams
>      >? ? ?to talk
>      >? ? ? >> less and do more. Stride provides teams with group
>     messaging, video
>      >? ? ? >> meetings & built-in collaboration tools. We are rolling
>     Stride
>      >? ? ?out during
>      >? ? ? >> our Early Access Program and very excited for you and
>     your team
>      >? ? ?to try it!
>      >? ? ? >> When will I get on Stride?
>      >? ? ? >> When it's your turn, we'll reach out again to get your team
>      >? ? ?started. You'll
>      >? ? ? >> be able to create a new team or upgrade an existing HipChat
>      >? ? ?team. Get
>      >? ? ? >> answers to most of your questions on our FAQs
>      >? ? ? >>
>      >   
>      ?<https://confluence.atlassian.com/display/STRIDE/Stride+documentation?&utm_source=prefinery&utm_medium=email&utm_campaign=waitlist-confirmation>
>      >? ? ? >> .
>      >? ? ? >> Thanks for your support! We can't wait to see your team
>     hit its
>      >? ? ?stride.
>      >? ? ? >> Cheers,
>      >? ? ? >> The Stride Team
>      >? ? ? >>
>      >? ? ? >> Copyright 2017 Atlassian Pty Ltd. All rights reserved. We are
>      >? ? ?located at 341
>      >? ? ? >> George Street, Sydney, NSW, 2000, Australia
>      >? ? ? >>
>      >   
>      ?<https://maps.google.com/?q=341+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g>
>      >? ? ? >>
>      >? ? ? >>
>      >? ? ? >> Don't want to receive amazing emails from us? Unsubscribe
>      >? ? ? >>
>      >   
>      ?<https://i.prefinery.com/projects/ykmtf4f9/users/be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe>
>      >? ? ? >> _______________________________________________
>      >? ? ? >> 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
>      >? ? ? > _______________________________________________
>      >? ? ? > 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
>      >? ? ? >
>      >
>      >? ? ?_______________________________________________
>      >? ? ?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
>      >
> 
>     _______________________________________________
>     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 yoann at hibernate.org  Fri Oct 27 09:41:47 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 27 Oct 2017 15:41:47 +0200
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <84dd5012-d4ef-abdb-94e0-ea9c00699e8c@marcanoonline.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<e610bde9-86e6-5313-4808-82e510f93dc6@marcanoonline.com>
	<CAFdSV9twQx9fRvHTkFjxSWH1TkGa46jXE-Awd8sdSobsF8j4xw@mail.gmail.com>
	<c91404b2-6ebe-3ccd-b62c-fec845a858af@marcanoonline.com>
	<CAFdSV9sM+ZVM3iev7TBSe5rOYx4_1rTxpZ94kZOAdQK5pDFNBw@mail.gmail.com>
	<84dd5012-d4ef-abdb-94e0-ea9c00699e8c@marcanoonline.com>
Message-ID: <CAEqagpohsYUsS_j2MeO8gYN_yZfW8kX+ZT6E2M028xqJJgD5iQ@mail.gmail.com>

Steve, Robert,

The link to the room is different for guests: https://www.hipchat.
com/gRRHYZZvB
I just tested it, it works.

It also tends to be re-generated each time there's a security breach at
Atlassian, but that's another story... :)


Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org

On 27 October 2017 at 15:10, Robert Marcano <robert at marcanoonline.com>
wrote:

> On 10/26/2017 03:40 PM, Steve Ebersole wrote:
> > I can understand that.
> >
> > There is a room in our HipChat that we allow anonymous/guest access, no
> > need for an account.  The only thing you lose is the ability to see
> > history.  But I think that's a reasonable expectation.  Have you tried
> > that approach? http://hibernate.hipchat.com/chat/room/3369275
>
> I don't see any options for anonymous logins there. It redirect to a
> login page with no options for a creating a new account either.
>
> If I post an email address in order to check if it later allows to login
> anonymously or if it ask to create an account. It says:
>
> "We don't recognize that email address"
>
> >
> > On Thu, Oct 26, 2017 at 1:25 PM Robert Marcano <robert at marcanoonline.com
> > <mailto:robert at marcanoonline.com>> wrote:
> >
> >     On 10/26/2017 12:03 PM, Steve Ebersole wrote:
> >      > Why would we?  What's the benefit over what we have?
> >      >
> >      >
> >
> >     As someone that jumps from forums to forums when need to discuss bugs
> >     outside bug reports systems, the lack of anonymous access to HipChat
> >     discouraged me multiple times to join. Not because anonymity was
> >     important, just tired of creating accounts for a few days usage in
> >     another service. Just my 2 cents.
> >
> >     There are other advantages but are more "political" than practical
> (OSS,
> >     federated, etc).
> >
> >      >
> >      > On Thu, Oct 26, 2017 at 10:52 AM Robert Marcano
> >      > <robert at marcanoonline.com <mailto:robert at marcanoonline.com>
> >     <mailto:robert at marcanoonline.com <mailto:robert at marcanoonline.com>>>
> >     wrote:
> >      >
> >      >     On 10/26/2017 09:22 AM, Sanne Grinovero wrote:
> >      >      > Thanks, I had the same on my TODO list. Are you going to
> >     convert the
> >      >      > HipChat team?
> >      >
> >      >     Just out of curiosity from someone that has just 2 weeks
> >     subscribed to
> >      >     this mailing list. Why not try Riot/Matrix http://riot.im/ ?
> >      >
> >      >      >
> >      >      > That way we *could* all try it out, on the other hand
> since we
> >      >     have no
> >      >      > choice we don't really need to evaluate it :D
> >      >      >
> >      >      > On 24 October 2017 at 19:34, Steve Ebersole
> >     <steve at hibernate.org <mailto:steve at hibernate.org>
> >      >     <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>>
> wrote:
> >      >      >> I've signed up for a "test drive" account on Atlassian's
> >     Stride
> >      >     server.
> >      >      >> Stride is their replacement for HipChat.
> >      >      >>
> >      >      >> ---------- Forwarded message ---------
> >      >      >> From: Stride by Atlassian <help at stride.com
> >     <mailto:help at stride.com> <mailto:help at stride.com
> >     <mailto:help at stride.com>>>
> >      >      >> Date: Tue, Oct 24, 2017, 1:32 PM
> >      >      >> Subject: You're on the Stride waitlist!
> >      >      >> To: <steve at hibernate.org <mailto:steve at hibernate.org>
> >     <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>>
> >      >      >>
> >      >      >>
> >      >      >>
> >      >      >> [image: Stride by Atlassian]
> >      >      >>
> >      >      >> Nice! You're on the list!
> >      >      >> [image: Stride waitlist]
> >      >      >> Thanks for your interest in Stride!
> >      >      >> What is Stride?
> >      >      >> Stride is a complete communication solution that empowers
> >     teams
> >      >     to talk
> >      >      >> less and do more. Stride provides teams with group
> >     messaging, video
> >      >      >> meetings & built-in collaboration tools. We are rolling
> >     Stride
> >      >     out during
> >      >      >> our Early Access Program and very excited for you and
> >     your team
> >      >     to try it!
> >      >      >> When will I get on Stride?
> >      >      >> When it's your turn, we'll reach out again to get your
> team
> >      >     started. You'll
> >      >      >> be able to create a new team or upgrade an existing
> HipChat
> >      >     team. Get
> >      >      >> answers to most of your questions on our FAQs
> >      >      >>
> >      >
> >       <https://confluence.atlassian.com/display/STRIDE/
> Stride+documentation?&utm_source=prefinery&utm_medium=
> email&utm_campaign=waitlist-confirmation>
> >      >      >> .
> >      >      >> Thanks for your support! We can't wait to see your team
> >     hit its
> >      >     stride.
> >      >      >> Cheers,
> >      >      >> The Stride Team
> >      >      >>
> >      >      >> Copyright 2017 Atlassian Pty Ltd. All rights reserved. We
> are
> >      >     located at 341
> >      >      >> George Street, Sydney, NSW, 2000, Australia
> >      >      >>
> >      >
> >       <https://maps.google.com/?q=341+George+Street,+Sydney,+
> NSW,+2000,+Australia&entry=gmail&source=g>
> >      >      >>
> >      >      >>
> >      >      >> Don't want to receive amazing emails from us? Unsubscribe
> >      >      >>
> >      >
> >       <https://i.prefinery.com/projects/ykmtf4f9/users/
> be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe>
> >      >      >> _______________________________________________
> >      >      >> 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
> >      >      > _______________________________________________
> >      >      > 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
> >      >      >
> >      >
> >      >     _______________________________________________
> >      >     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
> >      >
> >
> >     _______________________________________________
> >     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
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Oct 27 10:03:17 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 27 Oct 2017 14:03:17 +0000
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <CAEqagpohsYUsS_j2MeO8gYN_yZfW8kX+ZT6E2M028xqJJgD5iQ@mail.gmail.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<e610bde9-86e6-5313-4808-82e510f93dc6@marcanoonline.com>
	<CAFdSV9twQx9fRvHTkFjxSWH1TkGa46jXE-Awd8sdSobsF8j4xw@mail.gmail.com>
	<c91404b2-6ebe-3ccd-b62c-fec845a858af@marcanoonline.com>
	<CAFdSV9sM+ZVM3iev7TBSe5rOYx4_1rTxpZ94kZOAdQK5pDFNBw@mail.gmail.com>
	<84dd5012-d4ef-abdb-94e0-ea9c00699e8c@marcanoonline.com>
	<CAEqagpohsYUsS_j2MeO8gYN_yZfW8kX+ZT6E2M028xqJJgD5iQ@mail.gmail.com>
Message-ID: <CAFdSV9v1N_ST5oEeBV9DgTF=JM+sY=XYWqwZhcoYPL91uJyswA@mail.gmail.com>

Yes I tested too an it works.  The problem is that hibernate.org has the
wrong url


On Fri, Oct 27, 2017 at 8:57 AM Yoann Rodiere <yoann at hibernate.org> wrote:

> Steve, Robert,
>
> The link to the room is different for guests: https://www.hipchat.
> com/gRRHYZZvB
> I just tested it, it works.
>
> It also tends to be re-generated each time there's a security breach at
> Atlassian, but that's another story... :)
>
>
> Yoann Rodi?re
> Hibernate NoORM Team
> yoann at hibernate.org
>
> On 27 October 2017 at 15:10, Robert Marcano <robert at marcanoonline.com>
> wrote:
>
> > On 10/26/2017 03:40 PM, Steve Ebersole wrote:
> > > I can understand that.
> > >
> > > There is a room in our HipChat that we allow anonymous/guest access, no
> > > need for an account.  The only thing you lose is the ability to see
> > > history.  But I think that's a reasonable expectation.  Have you tried
> > > that approach? http://hibernate.hipchat.com/chat/room/3369275
> >
> > I don't see any options for anonymous logins there. It redirect to a
> > login page with no options for a creating a new account either.
> >
> > If I post an email address in order to check if it later allows to login
> > anonymously or if it ask to create an account. It says:
> >
> > "We don't recognize that email address"
> >
> > >
> > > On Thu, Oct 26, 2017 at 1:25 PM Robert Marcano <
> robert at marcanoonline.com
> > > <mailto:robert at marcanoonline.com>> wrote:
> > >
> > >     On 10/26/2017 12:03 PM, Steve Ebersole wrote:
> > >      > Why would we?  What's the benefit over what we have?
> > >      >
> > >      >
> > >
> > >     As someone that jumps from forums to forums when need to discuss
> bugs
> > >     outside bug reports systems, the lack of anonymous access to
> HipChat
> > >     discouraged me multiple times to join. Not because anonymity was
> > >     important, just tired of creating accounts for a few days usage in
> > >     another service. Just my 2 cents.
> > >
> > >     There are other advantages but are more "political" than practical
> > (OSS,
> > >     federated, etc).
> > >
> > >      >
> > >      > On Thu, Oct 26, 2017 at 10:52 AM Robert Marcano
> > >      > <robert at marcanoonline.com <mailto:robert at marcanoonline.com>
> > >     <mailto:robert at marcanoonline.com <mailto:robert at marcanoonline.com
> >>>
> > >     wrote:
> > >      >
> > >      >     On 10/26/2017 09:22 AM, Sanne Grinovero wrote:
> > >      >      > Thanks, I had the same on my TODO list. Are you going to
> > >     convert the
> > >      >      > HipChat team?
> > >      >
> > >      >     Just out of curiosity from someone that has just 2 weeks
> > >     subscribed to
> > >      >     this mailing list. Why not try Riot/Matrix http://riot.im/
> ?
> > >      >
> > >      >      >
> > >      >      > That way we *could* all try it out, on the other hand
> > since we
> > >      >     have no
> > >      >      > choice we don't really need to evaluate it :D
> > >      >      >
> > >      >      > On 24 October 2017 at 19:34, Steve Ebersole
> > >     <steve at hibernate.org <mailto:steve at hibernate.org>
> > >      >     <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>>
> > wrote:
> > >      >      >> I've signed up for a "test drive" account on Atlassian's
> > >     Stride
> > >      >     server.
> > >      >      >> Stride is their replacement for HipChat.
> > >      >      >>
> > >      >      >> ---------- Forwarded message ---------
> > >      >      >> From: Stride by Atlassian <help at stride.com
> > >     <mailto:help at stride.com> <mailto:help at stride.com
> > >     <mailto:help at stride.com>>>
> > >      >      >> Date: Tue, Oct 24, 2017, 1:32 PM
> > >      >      >> Subject: You're on the Stride waitlist!
> > >      >      >> To: <steve at hibernate.org <mailto:steve at hibernate.org>
> > >     <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>>
> > >      >      >>
> > >      >      >>
> > >      >      >>
> > >      >      >> [image: Stride by Atlassian]
> > >      >      >>
> > >      >      >> Nice! You're on the list!
> > >      >      >> [image: Stride waitlist]
> > >      >      >> Thanks for your interest in Stride!
> > >      >      >> What is Stride?
> > >      >      >> Stride is a complete communication solution that
> empowers
> > >     teams
> > >      >     to talk
> > >      >      >> less and do more. Stride provides teams with group
> > >     messaging, video
> > >      >      >> meetings & built-in collaboration tools. We are rolling
> > >     Stride
> > >      >     out during
> > >      >      >> our Early Access Program and very excited for you and
> > >     your team
> > >      >     to try it!
> > >      >      >> When will I get on Stride?
> > >      >      >> When it's your turn, we'll reach out again to get your
> > team
> > >      >     started. You'll
> > >      >      >> be able to create a new team or upgrade an existing
> > HipChat
> > >      >     team. Get
> > >      >      >> answers to most of your questions on our FAQs
> > >      >      >>
> > >      >
> > >       <https://confluence.atlassian.com/display/STRIDE/
> > Stride+documentation?&utm_source=prefinery&utm_medium=
> > email&utm_campaign=waitlist-confirmation>
> > >      >      >> .
> > >      >      >> Thanks for your support! We can't wait to see your team
> > >     hit its
> > >      >     stride.
> > >      >      >> Cheers,
> > >      >      >> The Stride Team
> > >      >      >>
> > >      >      >> Copyright 2017 Atlassian Pty Ltd. All rights reserved.
> We
> > are
> > >      >     located at 341
> > >      >      >> George Street, Sydney, NSW, 2000, Australia
> > >      >      >>
> > >      >
> > >       <https://maps.google.com/?q=341+George+Street,+Sydney,+
> > NSW,+2000,+Australia&entry=gmail&source=g>
> > >      >      >>
> > >      >      >>
> > >      >      >> Don't want to receive amazing emails from us?
> Unsubscribe
> > >      >      >>
> > >      >
> > >       <https://i.prefinery.com/projects/ykmtf4f9/users/
> > be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe>
> > >      >      >> _______________________________________________
> > >      >      >> 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
> > >      >      > _______________________________________________
> > >      >      > 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
> > >      >      >
> > >      >
> > >      >     _______________________________________________
> > >      >     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
> > >      >
> > >
> > >     _______________________________________________
> > >     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
> > 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  Fri Oct 27 10:14:35 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 27 Oct 2017 16:14:35 +0200
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <CAEqagpohsYUsS_j2MeO8gYN_yZfW8kX+ZT6E2M028xqJJgD5iQ@mail.gmail.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<e610bde9-86e6-5313-4808-82e510f93dc6@marcanoonline.com>
	<CAFdSV9twQx9fRvHTkFjxSWH1TkGa46jXE-Awd8sdSobsF8j4xw@mail.gmail.com>
	<c91404b2-6ebe-3ccd-b62c-fec845a858af@marcanoonline.com>
	<CAFdSV9sM+ZVM3iev7TBSe5rOYx4_1rTxpZ94kZOAdQK5pDFNBw@mail.gmail.com>
	<84dd5012-d4ef-abdb-94e0-ea9c00699e8c@marcanoonline.com>
	<CAEqagpohsYUsS_j2MeO8gYN_yZfW8kX+ZT6E2M028xqJJgD5iQ@mail.gmail.com>
Message-ID: <CADGJaX_0u4n-5hnRnef3Xx88ToVaHximiXt_biPoiwGs13U_kg@mail.gmail.com>

Poor guest accessibility is the biggest issue I see about HipChat. I hope
that's a thing improved in Stride.

@Yoann, could you adjust the info on http://hibernate.org/community/ to the
room link you provided?

2017-10-27 15:41 GMT+02:00 Yoann Rodiere <yoann at hibernate.org>:

> Steve, Robert,
>
> The link to the room is different for guests: https://www.hipchat.
> com/gRRHYZZvB
> I just tested it, it works.
>
> It also tends to be re-generated each time there's a security breach at
> Atlassian, but that's another story... :)
>
>
> Yoann Rodi?re
> Hibernate NoORM Team
> yoann at hibernate.org
>
> On 27 October 2017 at 15:10, Robert Marcano <robert at marcanoonline.com>
> wrote:
>
> > On 10/26/2017 03:40 PM, Steve Ebersole wrote:
> > > I can understand that.
> > >
> > > There is a room in our HipChat that we allow anonymous/guest access, no
> > > need for an account.  The only thing you lose is the ability to see
> > > history.  But I think that's a reasonable expectation.  Have you tried
> > > that approach? http://hibernate.hipchat.com/chat/room/3369275
> >
> > I don't see any options for anonymous logins there. It redirect to a
> > login page with no options for a creating a new account either.
> >
> > If I post an email address in order to check if it later allows to login
> > anonymously or if it ask to create an account. It says:
> >
> > "We don't recognize that email address"
> >
> > >
> > > On Thu, Oct 26, 2017 at 1:25 PM Robert Marcano <
> robert at marcanoonline.com
> > > <mailto:robert at marcanoonline.com>> wrote:
> > >
> > >     On 10/26/2017 12:03 PM, Steve Ebersole wrote:
> > >      > Why would we?  What's the benefit over what we have?
> > >      >
> > >      >
> > >
> > >     As someone that jumps from forums to forums when need to discuss
> bugs
> > >     outside bug reports systems, the lack of anonymous access to
> HipChat
> > >     discouraged me multiple times to join. Not because anonymity was
> > >     important, just tired of creating accounts for a few days usage in
> > >     another service. Just my 2 cents.
> > >
> > >     There are other advantages but are more "political" than practical
> > (OSS,
> > >     federated, etc).
> > >
> > >      >
> > >      > On Thu, Oct 26, 2017 at 10:52 AM Robert Marcano
> > >      > <robert at marcanoonline.com <mailto:robert at marcanoonline.com>
> > >     <mailto:robert at marcanoonline.com <mailto:robert at marcanoonline.com
> >>>
> > >     wrote:
> > >      >
> > >      >     On 10/26/2017 09:22 AM, Sanne Grinovero wrote:
> > >      >      > Thanks, I had the same on my TODO list. Are you going to
> > >     convert the
> > >      >      > HipChat team?
> > >      >
> > >      >     Just out of curiosity from someone that has just 2 weeks
> > >     subscribed to
> > >      >     this mailing list. Why not try Riot/Matrix http://riot.im/
> ?
> > >      >
> > >      >      >
> > >      >      > That way we *could* all try it out, on the other hand
> > since we
> > >      >     have no
> > >      >      > choice we don't really need to evaluate it :D
> > >      >      >
> > >      >      > On 24 October 2017 at 19:34, Steve Ebersole
> > >     <steve at hibernate.org <mailto:steve at hibernate.org>
> > >      >     <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>>
> > wrote:
> > >      >      >> I've signed up for a "test drive" account on Atlassian's
> > >     Stride
> > >      >     server.
> > >      >      >> Stride is their replacement for HipChat.
> > >      >      >>
> > >      >      >> ---------- Forwarded message ---------
> > >      >      >> From: Stride by Atlassian <help at stride.com
> > >     <mailto:help at stride.com> <mailto:help at stride.com
> > >     <mailto:help at stride.com>>>
> > >      >      >> Date: Tue, Oct 24, 2017, 1:32 PM
> > >      >      >> Subject: You're on the Stride waitlist!
> > >      >      >> To: <steve at hibernate.org <mailto:steve at hibernate.org>
> > >     <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>>
> > >      >      >>
> > >      >      >>
> > >      >      >>
> > >      >      >> [image: Stride by Atlassian]
> > >      >      >>
> > >      >      >> Nice! You're on the list!
> > >      >      >> [image: Stride waitlist]
> > >      >      >> Thanks for your interest in Stride!
> > >      >      >> What is Stride?
> > >      >      >> Stride is a complete communication solution that
> empowers
> > >     teams
> > >      >     to talk
> > >      >      >> less and do more. Stride provides teams with group
> > >     messaging, video
> > >      >      >> meetings & built-in collaboration tools. We are rolling
> > >     Stride
> > >      >     out during
> > >      >      >> our Early Access Program and very excited for you and
> > >     your team
> > >      >     to try it!
> > >      >      >> When will I get on Stride?
> > >      >      >> When it's your turn, we'll reach out again to get your
> > team
> > >      >     started. You'll
> > >      >      >> be able to create a new team or upgrade an existing
> > HipChat
> > >      >     team. Get
> > >      >      >> answers to most of your questions on our FAQs
> > >      >      >>
> > >      >
> > >       <https://confluence.atlassian.com/display/STRIDE/
> > Stride+documentation?&utm_source=prefinery&utm_medium=
> > email&utm_campaign=waitlist-confirmation>
> > >      >      >> .
> > >      >      >> Thanks for your support! We can't wait to see your team
> > >     hit its
> > >      >     stride.
> > >      >      >> Cheers,
> > >      >      >> The Stride Team
> > >      >      >>
> > >      >      >> Copyright 2017 Atlassian Pty Ltd. All rights reserved.
> We
> > are
> > >      >     located at 341
> > >      >      >> George Street, Sydney, NSW, 2000, Australia
> > >      >      >>
> > >      >
> > >       <https://maps.google.com/?q=341+George+Street,+Sydney,+
> > NSW,+2000,+Australia&entry=gmail&source=g>
> > >      >      >>
> > >      >      >>
> > >      >      >> Don't want to receive amazing emails from us?
> Unsubscribe
> > >      >      >>
> > >      >
> > >       <https://i.prefinery.com/projects/ykmtf4f9/users/
> > be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe>
> > >      >      >> _______________________________________________
> > >      >      >> 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
> > >      >      > _______________________________________________
> > >      >      > 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
> > >      >      >
> > >      >
> > >      >     _______________________________________________
> > >      >     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
> > >      >
> > >
> > >     _______________________________________________
> > >     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
> > 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 yoann at hibernate.org  Fri Oct 27 10:52:07 2017
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 27 Oct 2017 16:52:07 +0200
Subject: [hibernate-dev] Fwd: You're on the Stride waitlist!
In-Reply-To: <CADGJaX_0u4n-5hnRnef3Xx88ToVaHximiXt_biPoiwGs13U_kg@mail.gmail.com>
References: <62c48106-e598-4f09-aa1f-04b7d034a80d@mtasv.net>
	<CAFdSV9t=-N1wFp5cSdzu2oeBWuY_in=hzayjAGvyumg1vPozdg@mail.gmail.com>
	<CAFm4XO3=uU9REA6HhB5YwWdB2Z4=o-Ui7o26HKVeHBGFaWbuWQ@mail.gmail.com>
	<e610bde9-86e6-5313-4808-82e510f93dc6@marcanoonline.com>
	<CAFdSV9twQx9fRvHTkFjxSWH1TkGa46jXE-Awd8sdSobsF8j4xw@mail.gmail.com>
	<c91404b2-6ebe-3ccd-b62c-fec845a858af@marcanoonline.com>
	<CAFdSV9sM+ZVM3iev7TBSe5rOYx4_1rTxpZ94kZOAdQK5pDFNBw@mail.gmail.com>
	<84dd5012-d4ef-abdb-94e0-ea9c00699e8c@marcanoonline.com>
	<CAEqagpohsYUsS_j2MeO8gYN_yZfW8kX+ZT6E2M028xqJJgD5iQ@mail.gmail.com>
	<CADGJaX_0u4n-5hnRnef3Xx88ToVaHximiXt_biPoiwGs13U_kg@mail.gmail.com>
Message-ID: <CAEqagpoopie4bjy66inZk4u08ZadF4i5zdqok9zsSQDWDtG1sw@mail.gmail.com>

> @Yoann, could you adjust the info on http://hibernate.org/community/ to
the room link you provided?

Steve already did.

Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org

On 27 October 2017 at 16:14, Gunnar Morling <gunnar at hibernate.org> wrote:

> Poor guest accessibility is the biggest issue I see about HipChat. I hope
> that's a thing improved in Stride.
>
> @Yoann, could you adjust the info on http://hibernate.org/community/ to
> the room link you provided?
>
> 2017-10-27 15:41 GMT+02:00 Yoann Rodiere <yoann at hibernate.org>:
>
>> Steve, Robert,
>>
>> The link to the room is different for guests: https://www.hipchat.
>> com/gRRHYZZvB
>> I just tested it, it works.
>>
>> It also tends to be re-generated each time there's a security breach at
>> Atlassian, but that's another story... :)
>>
>>
>> Yoann Rodi?re
>> Hibernate NoORM Team
>> yoann at hibernate.org
>>
>> On 27 October 2017 at 15:10, Robert Marcano <robert at marcanoonline.com>
>> wrote:
>>
>> > On 10/26/2017 03:40 PM, Steve Ebersole wrote:
>> > > I can understand that.
>> > >
>> > > There is a room in our HipChat that we allow anonymous/guest access,
>> no
>> > > need for an account.  The only thing you lose is the ability to see
>> > > history.  But I think that's a reasonable expectation.  Have you tried
>> > > that approach? http://hibernate.hipchat.com/chat/room/3369275
>> >
>> > I don't see any options for anonymous logins there. It redirect to a
>> > login page with no options for a creating a new account either.
>> >
>> > If I post an email address in order to check if it later allows to login
>> > anonymously or if it ask to create an account. It says:
>> >
>> > "We don't recognize that email address"
>> >
>> > >
>> > > On Thu, Oct 26, 2017 at 1:25 PM Robert Marcano <
>> robert at marcanoonline.com
>> > > <mailto:robert at marcanoonline.com>> wrote:
>> > >
>> > >     On 10/26/2017 12:03 PM, Steve Ebersole wrote:
>> > >      > Why would we?  What's the benefit over what we have?
>> > >      >
>> > >      >
>> > >
>> > >     As someone that jumps from forums to forums when need to discuss
>> bugs
>> > >     outside bug reports systems, the lack of anonymous access to
>> HipChat
>> > >     discouraged me multiple times to join. Not because anonymity was
>> > >     important, just tired of creating accounts for a few days usage in
>> > >     another service. Just my 2 cents.
>> > >
>> > >     There are other advantages but are more "political" than practical
>> > (OSS,
>> > >     federated, etc).
>> > >
>> > >      >
>> > >      > On Thu, Oct 26, 2017 at 10:52 AM Robert Marcano
>> > >      > <robert at marcanoonline.com <mailto:robert at marcanoonline.com>
>> > >     <mailto:robert at marcanoonline.com <mailto:robert at marcanoonline.com
>> >>>
>> > >     wrote:
>> > >      >
>> > >      >     On 10/26/2017 09:22 AM, Sanne Grinovero wrote:
>> > >      >      > Thanks, I had the same on my TODO list. Are you going to
>> > >     convert the
>> > >      >      > HipChat team?
>> > >      >
>> > >      >     Just out of curiosity from someone that has just 2 weeks
>> > >     subscribed to
>> > >      >     this mailing list. Why not try Riot/Matrix http://riot.im/
>> ?
>> > >      >
>> > >      >      >
>> > >      >      > That way we *could* all try it out, on the other hand
>> > since we
>> > >      >     have no
>> > >      >      > choice we don't really need to evaluate it :D
>> > >      >      >
>> > >      >      > On 24 October 2017 at 19:34, Steve Ebersole
>> > >     <steve at hibernate.org <mailto:steve at hibernate.org>
>> > >      >     <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>>
>> > wrote:
>> > >      >      >> I've signed up for a "test drive" account on
>> Atlassian's
>> > >     Stride
>> > >      >     server.
>> > >      >      >> Stride is their replacement for HipChat.
>> > >      >      >>
>> > >      >      >> ---------- Forwarded message ---------
>> > >      >      >> From: Stride by Atlassian <help at stride.com
>> > >     <mailto:help at stride.com> <mailto:help at stride.com
>> > >     <mailto:help at stride.com>>>
>> > >      >      >> Date: Tue, Oct 24, 2017, 1:32 PM
>> > >      >      >> Subject: You're on the Stride waitlist!
>> > >      >      >> To: <steve at hibernate.org <mailto:steve at hibernate.org>
>> > >     <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>>
>> > >      >      >>
>> > >      >      >>
>> > >      >      >>
>> > >      >      >> [image: Stride by Atlassian]
>> > >      >      >>
>> > >      >      >> Nice! You're on the list!
>> > >      >      >> [image: Stride waitlist]
>> > >      >      >> Thanks for your interest in Stride!
>> > >      >      >> What is Stride?
>> > >      >      >> Stride is a complete communication solution that
>> empowers
>> > >     teams
>> > >      >     to talk
>> > >      >      >> less and do more. Stride provides teams with group
>> > >     messaging, video
>> > >      >      >> meetings & built-in collaboration tools. We are rolling
>> > >     Stride
>> > >      >     out during
>> > >      >      >> our Early Access Program and very excited for you and
>> > >     your team
>> > >      >     to try it!
>> > >      >      >> When will I get on Stride?
>> > >      >      >> When it's your turn, we'll reach out again to get your
>> > team
>> > >      >     started. You'll
>> > >      >      >> be able to create a new team or upgrade an existing
>> > HipChat
>> > >      >     team. Get
>> > >      >      >> answers to most of your questions on our FAQs
>> > >      >      >>
>> > >      >
>> > >       <https://confluence.atlassian.com/display/STRIDE/
>> > Stride+documentation?&utm_source=prefinery&utm_medium=
>> > email&utm_campaign=waitlist-confirmation>
>> > >      >      >> .
>> > >      >      >> Thanks for your support! We can't wait to see your team
>> > >     hit its
>> > >      >     stride.
>> > >      >      >> Cheers,
>> > >      >      >> The Stride Team
>> > >      >      >>
>> > >      >      >> Copyright 2017 Atlassian Pty Ltd. All rights reserved.
>> We
>> > are
>> > >      >     located at 341
>> <https://maps.google.com/?q=341+%0D+%3E+%3E%C2%A0+%C2%A0+%C2%A0+%3E%C2%A0+%C2%A0+%C2%A0+%3E%3E+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g>
>> > >
>> <https://maps.google.com/?q=341+%0D+%3E+%3E%C2%A0+%C2%A0+%C2%A0+%3E%C2%A0+%C2%A0+%C2%A0+%3E%3E+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g>
>> >
>> <https://maps.google.com/?q=341+%0D+%3E+%3E%C2%A0+%C2%A0+%C2%A0+%3E%C2%A0+%C2%A0+%C2%A0+%3E%3E+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g>>>
>> George Street, Sydney, NSW, 2000, Australia
>> <https://maps.google.com/?q=341+%0D+%3E+%3E%C2%A0+%C2%A0+%C2%A0+%3E%C2%A0+%C2%A0+%C2%A0+%3E%3E+George+Street,+Sydney,+NSW,+2000,+Australia&entry=gmail&source=g>
>> > >      >      >>
>> > >      >
>> > >       <https://maps.google.com/?q=341+George+Street,+Sydney,+
>> > NSW,+2000,+Australia
>> <https://maps.google.com/?q=q%3D341%2BGeorge%2BStreet,%2BSydney,%2B+%0D+%3E+NSW,%2B2000,%2BAustralia&entry=gmail&source=g>
>> &entry=gmail&source=g>
>> > >      >      >>
>> > >      >      >>
>> > >      >      >> Don't want to receive amazing emails from us?
>> Unsubscribe
>> > >      >      >>
>> > >      >
>> > >       <https://i.prefinery.com/projects/ykmtf4f9/users/
>> > be9ecc46-2b3d-4352-a542-57add9ca10c7/unsubscribe>
>> > >      >      >> _______________________________________________
>> > >      >      >> 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
>> > >      >      > _______________________________________________
>> > >      >      > 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
>> > >      >      >
>> > >      >
>> > >      >     _______________________________________________
>> > >      >     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
>> > >      >
>> > >
>> > >     _______________________________________________
>> > >     hibernate-dev mailing list
>> > >     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jb
>> oss.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
>>
>
>