From yoann at hibernate.org  Fri Jun  1 03:00:02 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 1 Jun 2018 09:00:02 +0200
Subject: [hibernate-dev] Health check status API
In-Reply-To: <CA+gWKMDbe0imeXyK-bKXBBYziDA3u9RxR7tcZjpiu_ONd3NsOw@mail.gmail.com>
References: <CAFm4XO0303CTonPNKTVW++5=yxEyjr0mwTACNUZLL7nZrRjLWw@mail.gmail.com>
	<CA+gWKMDbe0imeXyK-bKXBBYziDA3u9RxR7tcZjpiu_ONd3NsOw@mail.gmail.com>
Message-ID: <CAEqagpp8cZPV7jVRBn-OMwdsY+Ctekj-c1hhDHWDYKVkBDCqAw@mail.gmail.com>

> We could do it via the Statistics mechanism which can be made available
via
JMX.

>From what I understand it would be an explicit call from the user
(OpenShift in this case) that would trigger an active check, like a request
to the database. Not sure the statistics are the best place to put such a
thing.

Or is it about us doing periodic checks on our own, and displaying the
results somewhere for anyone to see if something is wrong? That sounds
unnecessarily complex.

> Probably best to explore this in ORM first, but then Search and OGM
could expose/implement it too for their respective services?

Sure. I wonder about the granularity though: if we have multiple
connections (multiple Elasticsearch cluster, a Lucene cluster with JGroups
or JMS, ...), what would these OpenShift people want us to expose? One big
"everything is fine/something is wrong" status, potentially returning a
specific error message to tell what part is wrong exactly? Or finer-grained
statuses, like "backend X: OK, backend Y: OK, Backend Z/JGroups: OK, ..."?

Also, I suppose we would expose our own APIs/SPIs, right? Not implement
some OpenShift-specific SPIs? I'd rather avoid that...

On Fri, 1 Jun 2018 at 01:36 Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> We could do it via the Statistics mechanism which can be made available via
> JMX.
>
> We just have to add whatever info they are interested in to monitor.
>
> Vlad
>
> On Thu, May 31, 2018 at 7:40 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > It was suggested to me that Hibernate ORM could help people developing
> > microservices on Kubernetes / Openshift by making "health checks"
> > easier.
> >
> > In short, how to expose to some management API that we're being able
> > to connect to the database and do our usual things.
> >
> > This could be done by connection pools as well but I suspect there
> > could be benefits in exposing this information in a unified way at an
> > higher level API; also on top of using ad-hoc specific connection
> > APIs, or Dialect specific instructions, I guess we could monitor
> > timeout exceptions, etc.. happening on the application sessions.
> >
> > Wrote some notes on:
> >  - https://hibernate.atlassian.net/browse/HHH-12655
> >
> > Probably best to explore this in ORM first, but then Search and OGM
> > could expose/implement it too for their respective services?
> >
> > Or maybe people would prefer to just run a query?
> >
> > Thanks,
> > Sanne
> > _______________________________________________
> > 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
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From emmanuel at hibernate.org  Fri Jun  1 08:58:47 2018
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 1 Jun 2018 14:58:47 +0200
Subject: [hibernate-dev] Health check status API
In-Reply-To: <CAFm4XO0303CTonPNKTVW++5=yxEyjr0mwTACNUZLL7nZrRjLWw@mail.gmail.com>
References: <CAFm4XO0303CTonPNKTVW++5=yxEyjr0mwTACNUZLL7nZrRjLWw@mail.gmail.com>
Message-ID: <20180601125847.GA59803@hibernate.org>

This ties to the lazy database discovery in Cloud environments. The
issue related to that also mentions a health check API.
I don't think it ties to the Stats or JMX API as at least for the
initial start, this API should be able to provide feedback while
Hibernate engine is starting (and looping).

It would be interesting to explore what other IO engines offer as health
check APIs to be inspired (straight poll, callback etc).

Emmanuel

On Thu 18-05-31 17:40, Sanne Grinovero wrote:
>It was suggested to me that Hibernate ORM could help people developing
>microservices on Kubernetes / Openshift by making "health checks"
>easier.
>
>In short, how to expose to some management API that we're being able
>to connect to the database and do our usual things.
>
>This could be done by connection pools as well but I suspect there
>could be benefits in exposing this information in a unified way at an
>higher level API; also on top of using ad-hoc specific connection
>APIs, or Dialect specific instructions, I guess we could monitor
>timeout exceptions, etc.. happening on the application sessions.
>
>Wrote some notes on:
> - https://hibernate.atlassian.net/browse/HHH-12655
>
>Probably best to explore this in ORM first, but then Search and OGM
>could expose/implement it too for their respective services?
>
>Or maybe people would prefer to just run a query?
>
>Thanks,
>Sanne
>_______________________________________________
>hibernate-dev mailing list
>hibernate-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/hibernate-dev

From chris at hibernate.org  Fri Jun  1 09:06:43 2018
From: chris at hibernate.org (Chris Cranford)
Date: Fri, 1 Jun 2018 09:06:43 -0400
Subject: [hibernate-dev] Health check status API
In-Reply-To: <CAEqagpp8cZPV7jVRBn-OMwdsY+Ctekj-c1hhDHWDYKVkBDCqAw@mail.gmail.com>
References: <CAFm4XO0303CTonPNKTVW++5=yxEyjr0mwTACNUZLL7nZrRjLWw@mail.gmail.com>
	<CA+gWKMDbe0imeXyK-bKXBBYziDA3u9RxR7tcZjpiu_ONd3NsOw@mail.gmail.com>
	<CAEqagpp8cZPV7jVRBn-OMwdsY+Ctekj-c1hhDHWDYKVkBDCqAw@mail.gmail.com>
Message-ID: <61d51b3f-fa05-953b-3879-fe5241d08436@hibernate.org>

See inline

On 06/01/2018 03:00 AM, Yoann Rodiere wrote:
>> We could do it via the Statistics mechanism which can be made available
> via
> JMX.
>
> >From what I understand it would be an explicit call from the user
> (OpenShift in this case) that would trigger an active check, like a request
> to the database. Not sure the statistics are the best place to put such a
> thing.
I don't believe so either, although data from the Statistics may be what
we do expose.

Perhaps a service placed into the StandardServiceRegistry that operates
as a
SessionFactoryObserver would work in this case allowing us to support
the use case
where an application spins up multiple SessionFactory configurations.

> Or is it about us doing periodic checks on our own, and displaying the
> results somewhere for anyone to see if something is wrong? That sounds
> unnecessarily complex.

We either do it periodically or we do it at the time the health check
endpoint is called?
> Sure. I wonder about the granularity though: if we have multiple
> connections (multiple Elasticsearch cluster, a Lucene cluster with JGroups
> or JMS, ...), what would these OpenShift people want us to expose? One big
> "everything is fine/something is wrong" status, potentially returning a
> specific error message to tell what part is wrong exactly? Or finer-grained
> statuses, like "backend X: OK, backend Y: OK, Backend Z/JGroups: OK, ..."?
I haven't looked at OpenShift specifically as-of-yet but I would guess
it is something
akin to my experience with Eureka where the caller is effectively
checking 2 things

1. Can I reach the endpoint (if not, its definitely OFFLINE)
2. The value of the "status" named value in the root of the JSON response.

So I would expect we'd had some type of structure similar to this JSON
response

{
? "status": "UP"
? "backend_X": {
??? "status": "UP",
??? ...
? },
? "backend_Y": {
??? "status": "UP",
??? ...
? }
}

> Also, I suppose we would expose our own APIs/SPIs, right? Not implement
> some OpenShift-specific SPIs? I'd rather avoid that...
+1
> On Fri, 1 Jun 2018 at 01:36 Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>
>> We could do it via the Statistics mechanism which can be made available via
>> JMX.
>>
>> We just have to add whatever info they are interested in to monitor.
>>
>> Vlad
>>
>> On Thu, May 31, 2018 at 7:40 PM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>>> It was suggested to me that Hibernate ORM could help people developing
>>> microservices on Kubernetes / Openshift by making "health checks"
>>> easier.
>>>
>>> In short, how to expose to some management API that we're being able
>>> to connect to the database and do our usual things.
>>>
>>> This could be done by connection pools as well but I suspect there
>>> could be benefits in exposing this information in a unified way at an
>>> higher level API; also on top of using ad-hoc specific connection
>>> APIs, or Dialect specific instructions, I guess we could monitor
>>> timeout exceptions, etc.. happening on the application sessions.
>>>
>>> Wrote some notes on:
>>>  - https://hibernate.atlassian.net/browse/HHH-12655
>>>
>>> Probably best to explore this in ORM first, but then Search and OGM
>>> could expose/implement it too for their respective services?
>>>
>>> Or maybe people would prefer to just run a query?
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> 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 golovnin at gmx.net  Fri Jun  1 09:44:32 2018
From: golovnin at gmx.net (Andrej Golovnin)
Date: Fri, 1 Jun 2018 15:44:32 +0200
Subject: [hibernate-dev] Health check status API
In-Reply-To: <CAFm4XO0303CTonPNKTVW++5=yxEyjr0mwTACNUZLL7nZrRjLWw@mail.gmail.com>
References: <CAFm4XO0303CTonPNKTVW++5=yxEyjr0mwTACNUZLL7nZrRjLWw@mail.gmail.com>
Message-ID: <CF08FF6B-D5C0-4224-819C-BDFDB4977A66@gmx.net>

Hi Sanne,

whatever you consider to implement in Hibernate ORM/Search/OMG
I think you should use/follow the MicroProfile Health spec [1].
As far as I know WildFly Swarm supports already this spec.

Best regards,
Andrej Golovnin

[1] https://github.com/eclipse/microprofile-health/

> On 31. May 2018, at 18:40, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> It was suggested to me that Hibernate ORM could help people developing
> microservices on Kubernetes / Openshift by making "health checks"
> easier.
> 
> In short, how to expose to some management API that we're being able
> to connect to the database and do our usual things.
> 
> This could be done by connection pools as well but I suspect there
> could be benefits in exposing this information in a unified way at an
> higher level API; also on top of using ad-hoc specific connection
> APIs, or Dialect specific instructions, I guess we could monitor
> timeout exceptions, etc.. happening on the application sessions.
> 
> Wrote some notes on:
> - https://hibernate.atlassian.net/browse/HHH-12655
> 
> Probably best to explore this in ORM first, but then Search and OGM
> could expose/implement it too for their respective services?
> 
> Or maybe people would prefer to just run a query?
> 
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From gunnar at hibernate.org  Fri Jun  1 09:57:46 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 1 Jun 2018 15:57:46 +0200
Subject: [hibernate-dev] Health check status API
In-Reply-To: <CF08FF6B-D5C0-4224-819C-BDFDB4977A66@gmx.net>
References: <CAFm4XO0303CTonPNKTVW++5=yxEyjr0mwTACNUZLL7nZrRjLWw@mail.gmail.com>
	<CF08FF6B-D5C0-4224-819C-BDFDB4977A66@gmx.net>
Message-ID: <CADGJaX8t5FFNZWEDjapBURE_nEnLnt3Jm1+onVWokiF6HyHQyw@mail.gmail.com>

+1 for looking into the mP health check API.

In fact, I don't even think that Hibernate would have to implement any sort
of looping itself. Instead, the orchestration layer would check the health
check endpoint and automatically restart the service if it's not in a
healthy state. That way, the ordering of start up isn't really an issue,
the application would be simply restarted as often as needed until the DB
is up.

2018-06-01 15:44 GMT+02:00 Andrej Golovnin <golovnin at gmx.net>:

> Hi Sanne,
>
> whatever you consider to implement in Hibernate ORM/Search/OMG
> I think you should use/follow the MicroProfile Health spec [1].
> As far as I know WildFly Swarm supports already this spec.
>
> Best regards,
> Andrej Golovnin
>
> [1] https://github.com/eclipse/microprofile-health/
>
> > On 31. May 2018, at 18:40, Sanne Grinovero <sanne at hibernate.org> wrote:
> >
> > It was suggested to me that Hibernate ORM could help people developing
> > microservices on Kubernetes / Openshift by making "health checks"
> > easier.
> >
> > In short, how to expose to some management API that we're being able
> > to connect to the database and do our usual things.
> >
> > This could be done by connection pools as well but I suspect there
> > could be benefits in exposing this information in a unified way at an
> > higher level API; also on top of using ad-hoc specific connection
> > APIs, or Dialect specific instructions, I guess we could monitor
> > timeout exceptions, etc.. happening on the application sessions.
> >
> > Wrote some notes on:
> > - https://hibernate.atlassian.net/browse/HHH-12655
> >
> > Probably best to explore this in ORM first, but then Search and OGM
> > could expose/implement it too for their respective services?
> >
> > Or maybe people would prefer to just run a query?
> >
> > Thanks,
> > Sanne
> > _______________________________________________
> > 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  Sun Jun  3 17:56:11 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 3 Jun 2018 22:56:11 +0100
Subject: [hibernate-dev] Health check status API
In-Reply-To: <CADGJaX8t5FFNZWEDjapBURE_nEnLnt3Jm1+onVWokiF6HyHQyw@mail.gmail.com>
References: <CAFm4XO0303CTonPNKTVW++5=yxEyjr0mwTACNUZLL7nZrRjLWw@mail.gmail.com>
	<CF08FF6B-D5C0-4224-819C-BDFDB4977A66@gmx.net>
	<CADGJaX8t5FFNZWEDjapBURE_nEnLnt3Jm1+onVWokiF6HyHQyw@mail.gmail.com>
Message-ID: <CAFm4XO0U_GLaY=APAfHXY+utMqAG-x3DBWrPqhXDA56t5BKF2Q@mail.gmail.com>

Thanks for all comments!

Agreed to look at MicroProfile and other IO engines.

Sure we don't want to pull in more dependencies, just allow others to
query Hibernate status over a well-defined API. In case this was to
need some Openshift or MicroProfile specifics I'd code that as a new
module, somewhat like providing a working example, which calls into /
boots Hibernate.

I don't like to rely exclusively on the orchestration layer to
try/reboot in a loop as the only mechanism - we need to help with
that.

With a non-trivial amount of inter-dependent services, you'd have the
risk of livelock. Even if it eventually resolves with some lucky
timings, you might end up rebooting the Hibernate SessionFactory -
including the JVM - and several other services. That could easily take
a long time and waste a ton of computing resources if we're not
careful.

Sanne



On 1 June 2018 at 14:57, Gunnar Morling <gunnar at hibernate.org> wrote:
> +1 for looking into the mP health check API.
>
> In fact, I don't even think that Hibernate would have to implement any sort
> of looping itself. Instead, the orchestration layer would check the health
> check endpoint and automatically restart the service if it's not in a
> healthy state. That way, the ordering of start up isn't really an issue, the
> application would be simply restarted as often as needed until the DB is up.
>
> 2018-06-01 15:44 GMT+02:00 Andrej Golovnin <golovnin at gmx.net>:
>>
>> Hi Sanne,
>>
>> whatever you consider to implement in Hibernate ORM/Search/OMG
>> I think you should use/follow the MicroProfile Health spec [1].
>> As far as I know WildFly Swarm supports already this spec.
>>
>> Best regards,
>> Andrej Golovnin
>>
>> [1] https://github.com/eclipse/microprofile-health/
>>
>> > On 31. May 2018, at 18:40, Sanne Grinovero <sanne at hibernate.org> wrote:
>> >
>> > It was suggested to me that Hibernate ORM could help people developing
>> > microservices on Kubernetes / Openshift by making "health checks"
>> > easier.
>> >
>> > In short, how to expose to some management API that we're being able
>> > to connect to the database and do our usual things.
>> >
>> > This could be done by connection pools as well but I suspect there
>> > could be benefits in exposing this information in a unified way at an
>> > higher level API; also on top of using ad-hoc specific connection
>> > APIs, or Dialect specific instructions, I guess we could monitor
>> > timeout exceptions, etc.. happening on the application sessions.
>> >
>> > Wrote some notes on:
>> > - https://hibernate.atlassian.net/browse/HHH-12655
>> >
>> > Probably best to explore this in ORM first, but then Search and OGM
>> > could expose/implement it too for their respective services?
>> >
>> > Or maybe people would prefer to just run a query?
>> >
>> > Thanks,
>> > Sanne
>> > _______________________________________________
>> > 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  Sun Jun  3 18:32:02 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 3 Jun 2018 17:32:02 -0500
Subject: [hibernate-dev] Health check status API
In-Reply-To: <CAFm4XO0U_GLaY=APAfHXY+utMqAG-x3DBWrPqhXDA56t5BKF2Q@mail.gmail.com>
References: <CAFm4XO0303CTonPNKTVW++5=yxEyjr0mwTACNUZLL7nZrRjLWw@mail.gmail.com>
	<CF08FF6B-D5C0-4224-819C-BDFDB4977A66@gmx.net>
	<CADGJaX8t5FFNZWEDjapBURE_nEnLnt3Jm1+onVWokiF6HyHQyw@mail.gmail.com>
	<CAFm4XO0U_GLaY=APAfHXY+utMqAG-x3DBWrPqhXDA56t5BKF2Q@mail.gmail.com>
Message-ID: <CAFdSV9tqwxSg=ZkN-OfXe6zQxekUuEppbGXsRs1FqYZLfejtAA@mail.gmail.com>

I've looked into both Hawkular and Dropwizard.  Personally I found neither
of them particularly easy to play with.

Did you have something specific in mind besides what we already collect
with the Statistics API?  As Vlad mentioned, we can already do this.


On Sun, Jun 3, 2018 at 5:22 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Thanks for all comments!
>
> Agreed to look at MicroProfile and other IO engines.
>
> Sure we don't want to pull in more dependencies, just allow others to
> query Hibernate status over a well-defined API. In case this was to
> need some Openshift or MicroProfile specifics I'd code that as a new
> module, somewhat like providing a working example, which calls into /
> boots Hibernate.
>
> I don't like to rely exclusively on the orchestration layer to
> try/reboot in a loop as the only mechanism - we need to help with
> that.
>
> With a non-trivial amount of inter-dependent services, you'd have the
> risk of livelock. Even if it eventually resolves with some lucky
> timings, you might end up rebooting the Hibernate SessionFactory -
> including the JVM - and several other services. That could easily take
> a long time and waste a ton of computing resources if we're not
> careful.
>
> Sanne
>
>
>
> On 1 June 2018 at 14:57, Gunnar Morling <gunnar at hibernate.org> wrote:
> > +1 for looking into the mP health check API.
> >
> > In fact, I don't even think that Hibernate would have to implement any
> sort
> > of looping itself. Instead, the orchestration layer would check the
> health
> > check endpoint and automatically restart the service if it's not in a
> > healthy state. That way, the ordering of start up isn't really an issue,
> the
> > application would be simply restarted as often as needed until the DB is
> up.
> >
> > 2018-06-01 15:44 GMT+02:00 Andrej Golovnin <golovnin at gmx.net>:
> >>
> >> Hi Sanne,
> >>
> >> whatever you consider to implement in Hibernate ORM/Search/OMG
> >> I think you should use/follow the MicroProfile Health spec [1].
> >> As far as I know WildFly Swarm supports already this spec.
> >>
> >> Best regards,
> >> Andrej Golovnin
> >>
> >> [1] https://github.com/eclipse/microprofile-health/
> >>
> >> > On 31. May 2018, at 18:40, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >> >
> >> > It was suggested to me that Hibernate ORM could help people developing
> >> > microservices on Kubernetes / Openshift by making "health checks"
> >> > easier.
> >> >
> >> > In short, how to expose to some management API that we're being able
> >> > to connect to the database and do our usual things.
> >> >
> >> > This could be done by connection pools as well but I suspect there
> >> > could be benefits in exposing this information in a unified way at an
> >> > higher level API; also on top of using ad-hoc specific connection
> >> > APIs, or Dialect specific instructions, I guess we could monitor
> >> > timeout exceptions, etc.. happening on the application sessions.
> >> >
> >> > Wrote some notes on:
> >> > - https://hibernate.atlassian.net/browse/HHH-12655
> >> >
> >> > Probably best to explore this in ORM first, but then Search and OGM
> >> > could expose/implement it too for their respective services?
> >> >
> >> > Or maybe people would prefer to just run a query?
> >> >
> >> > Thanks,
> >> > Sanne
> >> > _______________________________________________
> >> > 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 yoann at hibernate.org  Mon Jun  4 07:51:35 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Mon, 4 Jun 2018 13:51:35 +0200
Subject: [hibernate-dev] [NoORM] A simpler README.md?
Message-ID: <CAEqagpq8Zom-tq4_ttE1iN6TT0OPrcmZyn4dedLrFfu6sm1ZfA@mail.gmail.com>

Hi everyone,

TL;DR: I would like to strip down the README in Hibernate Search to
redirect users to the website, which is better suited for presenting
available versions, and helping users to get started. See what I mean in this
PR <https://github.com/hibernate/hibernate-search/pull/1692>. Any
objections?

Currently, the README.md in NoORM projects duplicates a bit of information
from our website and documentation:

   - The version number and date of the latest release:
   https://github.com/hibernate/hibernate-search#hibernate-search vs.
   http://hibernate.org/search/releases/
   - A description of the project:
   https://github.com/hibernate/hibernate-search#description vs.
   http://hibernate.org/search/
   - The requirements:
   https://github.com/hibernate/hibernate-search#requirements vs.
   http://hibernate.org/search/releases/#compatibility-matrix or
   http://hibernate.org/search/releases/5.10/#compatibility
   - Installation instructions:
   https://github.com/hibernate/hibernate-search#maven +
   https://github.com/hibernate/hibernate-search#sourceforge-bundle vs.
   http://hibernate.org/search/releases/5.10/#get-it or
   http://hibernate.org/search/documentation/getting-started/


Some of this information is updated manually when we don'r forget about it,
and some of it (the latest release) is updated automatically when we
perform a release on master.

As a result, from time to time the information is not in sync. Right now,
in Search, the version displayed in the README is 5.10.0.Final, whereas the
latest release is 5.10.1.Final and the master branch hosts the
5.11.0-SNAPSHOT code. This is because the release scripts do not update
master when we release from another branch, and we have to do it manually
(that's expected: doing otherwise would be too complex).

Also, the information is partial:

   - the README currently completely hides the fact that other Hibernate
   Search versions are still maintained and can work well with older versions
   of Hibernate ORM.
   - whenever the latest release is an alpha/beta/CR, we usually display
   installation instructions for the latest development version, and
   completely hide information about the latest stable version.

What's worse, keeping the documentation on branch master the README on
branch master may prove confusing: the README refers to the latest release,
but the rest of the code may have been updated since the latest release,
sometimes significantly so. We will have trouble dealing with this when we
merge Hibernate Search 6, in particular.

We may not agree on what is the best solution, but let's at least agree
this is not ideal, especially when it comes to informing users about the
stable version they want to use.

We could put in more effort, try our very best to keep everything in sync
and as complete as possible/necessary. Add more documentation about the
release process. Try our best to do less mistakes. We could. But obviously,
nobody is perfect, and so never will this README.

Other projects, such as Spring Boot (
https://github.com/spring-projects/spring-boot) or, more relevantly,
Hibernate ORM (https://github.com/hwithibernate/hibernate-orm
<https://github.com/hibernate/hibernate-orm>), simply do not refer to the
latest version in their README, and redirect to their website for all
version-specific information. The README focuses on presenting the project,
redirecting users to the website, and giving contributor-friendly
information.

I find this solution both elegant and powerful. Presenting the project is
always necessary, but guiding users to the right version and giving getting
started instructions is something complex, and something we already do on
our website. So why not redirect people there? All links stay valid and
relevant as long as the website is up and kept updated, and the impact of
maintainers forgetting to update the README is far smaller. One less thing
to worry about for maintainers, and better guidance for prospective users.

A simple link to the getting started guide could be enough for most users,
but we can go a step further and offer additional links. I just sent a pull
request to show how I see it implemented in Search; please let me know what
you think.
The PR: https://github.com/hibernate/hibernate-search/pull/1692
Preview of the README as seen from the GitHub web view:
https://github.com/yrodiere/hibernate-search/blob/ae4d347fa4c647a3c5ddb6f43412cf3dce0e354e/README.md

Cheers,
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From guillaume.smet at gmail.com  Mon Jun  4 08:22:35 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 4 Jun 2018 14:22:35 +0200
Subject: [hibernate-dev] [NoORM] A simpler README.md?
In-Reply-To: <CAEqagpq8Zom-tq4_ttE1iN6TT0OPrcmZyn4dedLrFfu6sm1ZfA@mail.gmail.com>
References: <CAEqagpq8Zom-tq4_ttE1iN6TT0OPrcmZyn4dedLrFfu6sm1ZfA@mail.gmail.com>
Message-ID: <CALt0+o9oxkZZNM_NKcT=zC-JaupuzwwOBejxmCL1SOCakiD6Hw@mail.gmail.com>

As mentioned on HipChat, feel free to do whatever you want for Search but I
want to keep the HV README.md as is.

So please do not make changes that impact the release process in this
regard (or make it conditional to Search).

Thanks.

On Mon, Jun 4, 2018 at 1:55 PM Yoann Rodiere <yoann at hibernate.org> wrote:

> Hi everyone,
>
> TL;DR: I would like to strip down the README in Hibernate Search to
> redirect users to the website, which is better suited for presenting
> available versions, and helping users to get started. See what I mean in
> this
> PR <https://github.com/hibernate/hibernate-search/pull/1692>. Any
> objections?
>
> Currently, the README.md in NoORM projects duplicates a bit of information
> from our website and documentation:
>
>    - The version number and date of the latest release:
>    https://github.com/hibernate/hibernate-search#hibernate-search vs.
>    http://hibernate.org/search/releases/
>    - A description of the project:
>    https://github.com/hibernate/hibernate-search#description vs.
>    http://hibernate.org/search/
>    - The requirements:
>    https://github.com/hibernate/hibernate-search#requirements vs.
>    http://hibernate.org/search/releases/#compatibility-matrix or
>    http://hibernate.org/search/releases/5.10/#compatibility
>    - Installation instructions:
>    https://github.com/hibernate/hibernate-search#maven +
>    https://github.com/hibernate/hibernate-search#sourceforge-bundle vs.
>    http://hibernate.org/search/releases/5.10/#get-it or
>    http://hibernate.org/search/documentation/getting-started/
>
>
> Some of this information is updated manually when we don'r forget about it,
> and some of it (the latest release) is updated automatically when we
> perform a release on master.
>
> As a result, from time to time the information is not in sync. Right now,
> in Search, the version displayed in the README is 5.10.0.Final, whereas the
> latest release is 5.10.1.Final and the master branch hosts the
> 5.11.0-SNAPSHOT code. This is because the release scripts do not update
> master when we release from another branch, and we have to do it manually
> (that's expected: doing otherwise would be too complex).
>
> Also, the information is partial:
>
>    - the README currently completely hides the fact that other Hibernate
>    Search versions are still maintained and can work well with older
> versions
>    of Hibernate ORM.
>    - whenever the latest release is an alpha/beta/CR, we usually display
>    installation instructions for the latest development version, and
>    completely hide information about the latest stable version.
>
> What's worse, keeping the documentation on branch master the README on
> branch master may prove confusing: the README refers to the latest release,
> but the rest of the code may have been updated since the latest release,
> sometimes significantly so. We will have trouble dealing with this when we
> merge Hibernate Search 6, in particular.
>
> We may not agree on what is the best solution, but let's at least agree
> this is not ideal, especially when it comes to informing users about the
> stable version they want to use.
>
> We could put in more effort, try our very best to keep everything in sync
> and as complete as possible/necessary. Add more documentation about the
> release process. Try our best to do less mistakes. We could. But obviously,
> nobody is perfect, and so never will this README.
>
> Other projects, such as Spring Boot (
> https://github.com/spring-projects/spring-boot) or, more relevantly,
> Hibernate ORM (https://github.com/hwithibernate/hibernate-orm
> <https://github.com/hibernate/hibernate-orm>), simply do not refer to the
> latest version in their README, and redirect to their website for all
> version-specific information. The README focuses on presenting the project,
> redirecting users to the website, and giving contributor-friendly
> information.
>
> I find this solution both elegant and powerful. Presenting the project is
> always necessary, but guiding users to the right version and giving getting
> started instructions is something complex, and something we already do on
> our website. So why not redirect people there? All links stay valid and
> relevant as long as the website is up and kept updated, and the impact of
> maintainers forgetting to update the README is far smaller. One less thing
> to worry about for maintainers, and better guidance for prospective users.
>
> A simple link to the getting started guide could be enough for most users,
> but we can go a step further and offer additional links. I just sent a pull
> request to show how I see it implemented in Search; please let me know what
> you think.
> The PR: https://github.com/hibernate/hibernate-search/pull/1692
> Preview of the README as seen from the GitHub web view:
>
> https://github.com/yrodiere/hibernate-search/blob/ae4d347fa4c647a3c5ddb6f43412cf3dce0e354e/README.md
>
> Cheers,
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Jun  4 08:32:16 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 4 Jun 2018 13:32:16 +0100
Subject: [hibernate-dev] [NoORM] A simpler README.md?
In-Reply-To: <CAEqagpq8Zom-tq4_ttE1iN6TT0OPrcmZyn4dedLrFfu6sm1ZfA@mail.gmail.com>
References: <CAEqagpq8Zom-tq4_ttE1iN6TT0OPrcmZyn4dedLrFfu6sm1ZfA@mail.gmail.com>
Message-ID: <CAFm4XO0ASq3Z65-YP5jkvGVYvZOsRLESc1LcD02BqKKZp0bH2A@mail.gmail.com>

The historical objection has been that many users get the zip of our
project on a floppy disk and have no access to the internet.

That might be an obsolete statement nowadays? They'll use a
USB stick today ;)

Still, we know that e.g. people in China and similar places can't
always access our online resources, even if they "have internet".
University assignments/labs might have similar limitations even in Europe.

I have no strong objections, do it if you feel strongly about this
"inconsistency".

Personally, it hasn't bothered me much to occasionally have to update
the README, and I don't think people will expect that a zip they keep
in a drawer will be the better source of information if they happen to
have access to hibernate.org

Cheers,
Sanne



On 4 June 2018 at 12:51, Yoann Rodiere <yoann at hibernate.org> wrote:
> Hi everyone,
>
> TL;DR: I would like to strip down the README in Hibernate Search to
> redirect users to the website, which is better suited for presenting
> available versions, and helping users to get started. See what I mean in this
> PR <https://github.com/hibernate/hibernate-search/pull/1692>. Any
> objections?
>
> Currently, the README.md in NoORM projects duplicates a bit of information
> from our website and documentation:
>
>    - The version number and date of the latest release:
>    https://github.com/hibernate/hibernate-search#hibernate-search vs.
>    http://hibernate.org/search/releases/
>    - A description of the project:
>    https://github.com/hibernate/hibernate-search#description vs.
>    http://hibernate.org/search/
>    - The requirements:
>    https://github.com/hibernate/hibernate-search#requirements vs.
>    http://hibernate.org/search/releases/#compatibility-matrix or
>    http://hibernate.org/search/releases/5.10/#compatibility
>    - Installation instructions:
>    https://github.com/hibernate/hibernate-search#maven +
>    https://github.com/hibernate/hibernate-search#sourceforge-bundle vs.
>    http://hibernate.org/search/releases/5.10/#get-it or
>    http://hibernate.org/search/documentation/getting-started/
>
>
> Some of this information is updated manually when we don'r forget about it,
> and some of it (the latest release) is updated automatically when we
> perform a release on master.
>
> As a result, from time to time the information is not in sync. Right now,
> in Search, the version displayed in the README is 5.10.0.Final, whereas the
> latest release is 5.10.1.Final and the master branch hosts the
> 5.11.0-SNAPSHOT code. This is because the release scripts do not update
> master when we release from another branch, and we have to do it manually
> (that's expected: doing otherwise would be too complex).
>
> Also, the information is partial:
>
>    - the README currently completely hides the fact that other Hibernate
>    Search versions are still maintained and can work well with older versions
>    of Hibernate ORM.
>    - whenever the latest release is an alpha/beta/CR, we usually display
>    installation instructions for the latest development version, and
>    completely hide information about the latest stable version.
>
> What's worse, keeping the documentation on branch master the README on
> branch master may prove confusing: the README refers to the latest release,
> but the rest of the code may have been updated since the latest release,
> sometimes significantly so. We will have trouble dealing with this when we
> merge Hibernate Search 6, in particular.
>
> We may not agree on what is the best solution, but let's at least agree
> this is not ideal, especially when it comes to informing users about the
> stable version they want to use.
>
> We could put in more effort, try our very best to keep everything in sync
> and as complete as possible/necessary. Add more documentation about the
> release process. Try our best to do less mistakes. We could. But obviously,
> nobody is perfect, and so never will this README.
>
> Other projects, such as Spring Boot (
> https://github.com/spring-projects/spring-boot) or, more relevantly,
> Hibernate ORM (https://github.com/hwithibernate/hibernate-orm
> <https://github.com/hibernate/hibernate-orm>), simply do not refer to the
> latest version in their README, and redirect to their website for all
> version-specific information. The README focuses on presenting the project,
> redirecting users to the website, and giving contributor-friendly
> information.
>
> I find this solution both elegant and powerful. Presenting the project is
> always necessary, but guiding users to the right version and giving getting
> started instructions is something complex, and something we already do on
> our website. So why not redirect people there? All links stay valid and
> relevant as long as the website is up and kept updated, and the impact of
> maintainers forgetting to update the README is far smaller. One less thing
> to worry about for maintainers, and better guidance for prospective users.
>
> A simple link to the getting started guide could be enough for most users,
> but we can go a step further and offer additional links. I just sent a pull
> request to show how I see it implemented in Search; please let me know what
> you think.
> The PR: https://github.com/hibernate/hibernate-search/pull/1692
> Preview of the README as seen from the GitHub web view:
> https://github.com/yrodiere/hibernate-search/blob/ae4d347fa4c647a3c5ddb6f43412cf3dce0e354e/README.md
>
> Cheers,
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Mon Jun  4 08:44:12 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 4 Jun 2018 14:44:12 +0200
Subject: [hibernate-dev] [NoORM] A simpler README.md?
In-Reply-To: <CAFm4XO0ASq3Z65-YP5jkvGVYvZOsRLESc1LcD02BqKKZp0bH2A@mail.gmail.com>
References: <CAEqagpq8Zom-tq4_ttE1iN6TT0OPrcmZyn4dedLrFfu6sm1ZfA@mail.gmail.com>
	<CAFm4XO0ASq3Z65-YP5jkvGVYvZOsRLESc1LcD02BqKKZp0bH2A@mail.gmail.com>
Message-ID: <CADGJaX89YmTp9X8FsNbAEZh_4kkHyNkTgojk50OErp32TpQurw@mail.gmail.com>

No strong preference on my side, but I found this project of Lauri Apple
very useful:

    https://github.com/LappleApple/feedmereadmes

You can ask for input on your README file there (they may send a PR for
updating it) and it also contains a "README maturity model". Perhaps it's
helpful for you, too.

--Gunnar


2018-06-04 14:32 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> The historical objection has been that many users get the zip of our
> project on a floppy disk and have no access to the internet.
>
> That might be an obsolete statement nowadays? They'll use a
> USB stick today ;)
>
> Still, we know that e.g. people in China and similar places can't
> always access our online resources, even if they "have internet".
> University assignments/labs might have similar limitations even in Europe.
>
> I have no strong objections, do it if you feel strongly about this
> "inconsistency".
>
> Personally, it hasn't bothered me much to occasionally have to update
> the README, and I don't think people will expect that a zip they keep
> in a drawer will be the better source of information if they happen to
> have access to hibernate.org
>
> Cheers,
> Sanne
>
>
>
> On 4 June 2018 at 12:51, Yoann Rodiere <yoann at hibernate.org> wrote:
> > Hi everyone,
> >
> > TL;DR: I would like to strip down the README in Hibernate Search to
> > redirect users to the website, which is better suited for presenting
> > available versions, and helping users to get started. See what I mean in
> this
> > PR <https://github.com/hibernate/hibernate-search/pull/1692>. Any
> > objections?
> >
> > Currently, the README.md in NoORM projects duplicates a bit of
> information
> > from our website and documentation:
> >
> >    - The version number and date of the latest release:
> >    https://github.com/hibernate/hibernate-search#hibernate-search vs.
> >    http://hibernate.org/search/releases/
> >    - A description of the project:
> >    https://github.com/hibernate/hibernate-search#description vs.
> >    http://hibernate.org/search/
> >    - The requirements:
> >    https://github.com/hibernate/hibernate-search#requirements vs.
> >    http://hibernate.org/search/releases/#compatibility-matrix or
> >    http://hibernate.org/search/releases/5.10/#compatibility
> >    - Installation instructions:
> >    https://github.com/hibernate/hibernate-search#maven +
> >    https://github.com/hibernate/hibernate-search#sourceforge-bundle vs.
> >    http://hibernate.org/search/releases/5.10/#get-it or
> >    http://hibernate.org/search/documentation/getting-started/
> >
> >
> > Some of this information is updated manually when we don'r forget about
> it,
> > and some of it (the latest release) is updated automatically when we
> > perform a release on master.
> >
> > As a result, from time to time the information is not in sync. Right now,
> > in Search, the version displayed in the README is 5.10.0.Final, whereas
> the
> > latest release is 5.10.1.Final and the master branch hosts the
> > 5.11.0-SNAPSHOT code. This is because the release scripts do not update
> > master when we release from another branch, and we have to do it manually
> > (that's expected: doing otherwise would be too complex).
> >
> > Also, the information is partial:
> >
> >    - the README currently completely hides the fact that other Hibernate
> >    Search versions are still maintained and can work well with older
> versions
> >    of Hibernate ORM.
> >    - whenever the latest release is an alpha/beta/CR, we usually display
> >    installation instructions for the latest development version, and
> >    completely hide information about the latest stable version.
> >
> > What's worse, keeping the documentation on branch master the README on
> > branch master may prove confusing: the README refers to the latest
> release,
> > but the rest of the code may have been updated since the latest release,
> > sometimes significantly so. We will have trouble dealing with this when
> we
> > merge Hibernate Search 6, in particular.
> >
> > We may not agree on what is the best solution, but let's at least agree
> > this is not ideal, especially when it comes to informing users about the
> > stable version they want to use.
> >
> > We could put in more effort, try our very best to keep everything in sync
> > and as complete as possible/necessary. Add more documentation about the
> > release process. Try our best to do less mistakes. We could. But
> obviously,
> > nobody is perfect, and so never will this README.
> >
> > Other projects, such as Spring Boot (
> > https://github.com/spring-projects/spring-boot) or, more relevantly,
> > Hibernate ORM (https://github.com/hwithibernate/hibernate-orm
> > <https://github.com/hibernate/hibernate-orm>), simply do not refer to
> the
> > latest version in their README, and redirect to their website for all
> > version-specific information. The README focuses on presenting the
> project,
> > redirecting users to the website, and giving contributor-friendly
> > information.
> >
> > I find this solution both elegant and powerful. Presenting the project is
> > always necessary, but guiding users to the right version and giving
> getting
> > started instructions is something complex, and something we already do on
> > our website. So why not redirect people there? All links stay valid and
> > relevant as long as the website is up and kept updated, and the impact of
> > maintainers forgetting to update the README is far smaller. One less
> thing
> > to worry about for maintainers, and better guidance for prospective
> users.
> >
> > A simple link to the getting started guide could be enough for most
> users,
> > but we can go a step further and offer additional links. I just sent a
> pull
> > request to show how I see it implemented in Search; please let me know
> what
> > you think.
> > The PR: https://github.com/hibernate/hibernate-search/pull/1692
> > Preview of the README as seen from the GitHub web view:
> > https://github.com/yrodiere/hibernate-search/blob/
> ae4d347fa4c647a3c5ddb6f43412cf3dce0e354e/README.md
> >
> > Cheers,
> > --
> > Yoann Rodiere
> > yoann at hibernate.org / yrodiere at redhat.com
> > Software Engineer
> > Hibernate NoORM team
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Jun  4 08:56:59 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 4 Jun 2018 13:56:59 +0100
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <CALaezvUya6RbOW+AABv_ba2gCKqta5YMjmw04_BSp9N=rgWtqw@mail.gmail.com>
References: <CAFm4XO0ZL3b4AG6Te+sFPjEJCwe_oBUVbbPxLhOVQoNtjyyKBw@mail.gmail.com>
	<CAJtdNN6vg+-wRDLxj06WgFHeZPMMZU+C7FkTiAzVdT+XVaJhbQ@mail.gmail.com>
	<CAJtdNN7R1N0zXgRjLYK54fhFjGcAAPycjLEesHdwZ7r3qt-n_w@mail.gmail.com>
	<CAJtdNN4W_xR+Zxw02wrTOexYo2L7==8NiQ8ptNMWYv_xLWM62Q@mail.gmail.com>
	<CAJtdNN5PRhcfWCApfMEy439EXO4=bDpivqhNEb1ogi2=ivyFKw@mail.gmail.com>
	<CAFm4XO2H8cVBfNO4EHmkoLDBD+qAwSE4qLr0hJNV+aR3S11XqQ@mail.gmail.com>
	<CAJtdNN71PpjLsNkrjNSOFOtpB1CGQ+DnP4aeE6UDcYrUWrEQJg@mail.gmail.com>
	<CAFm4XO1pSwYxBRqNrWNi+USWPNX3LYjRrJ6jLgbhEKMmy=9joQ@mail.gmail.com>
	<CAFdSV9swCEFY-zLqTEY2=D3+T7giXpOzYO2v6tPg7tWt63=ktw@mail.gmail.com>
	<CAFm4XO0Dpn7XP2X8wMMvksr41Tf-f=ZYGEdJwZVtaxN9Ahu7cQ@mail.gmail.com>
	<CALaezvUya6RbOW+AABv_ba2gCKqta5YMjmw04_BSp9N=rgWtqw@mail.gmail.com>
Message-ID: <CAFm4XO2JsEg0iuTsN45Dw9S-xtZsYLLpzaQpyBkT6kOVyQ5i+Q@mail.gmail.com>

On 4 June 2018 at 12:23, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
>
>
> On 28 May 2018 at 12:23, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> On 28 May 2018 at 00:05, Steve Ebersole <steve at hibernate.org> wrote:
>> > JBossStandalone is meant for use of JBoss Transactions outside of
>> > WildFly.
>> > Why are we using it inside WildFly.  Inside WildFly, jipijapa ought to
>> > be
>> > defining that however it needs through a custom JtaPlatform and probably
>> > the
>> > JtaPlatformInitiator.
>>
>> I don't know the reasons, as I just started looking at WildFly Swarm
>> (now named Thorntail) and I'm merely reporting I see such exceptions.
>>
>> It's indeed surprising that this JTA Platform is being picked; I
>> chatted with Scott on another chat wondering why this system
>> apparently is not using JipiJapa - which would configure it correctly.
>> I guess it's not clear to me if Thorntail is to be considered "in" or
>> "outside" WildFly but I'm keeping this conversation for the Thorntail
>> team.
>>
>> All I observe is that 5.3.0.Final worked fine in Thorntail while
>> 5.3.1.Final will not work unless I figure out how to reconfigure it or
>> which other dependencies need switching - neither seems trivial and
>> that's unexpected from a micro update.
>> Same for the Narayana quickstarts and demo projects - maybe their
>> configuration could use some updates but I'm not sure, I'll leave that
>> to Tom and Gytis to decide.
>
>
> I just wanted to check, do we need any changes in the Narayana quickstart to
> deal with this? It reads as though since 5.3.2 we don't need to add a new
> dependency?
> https://github.com/jbosstm/quickstart/blob/master/jca-and-hibernate/src/test/resources/META-INF/persistence.xml#L39

Hi Tom,

I'm not sure either, let's test it after 5.3.2.Final is released -
likely we won't need to make any changes to the quickstarts.

@All:
For Hibernate Search, Thorntail, and Infinispan I already did the
upgrade and they come with custom JTA platform providers to dodge the
incompatibility.
The same trick wasn't possible with OGM as we test interactions with
the transaction system in many more subtle ways; I decided it wasn't
worth the effort of introducing all the scaffolding as we can just
wait for ORM 5.3.2 instead.

Thanks,
Sanne

>
>>
>>
>> Thanks,
>> Sanne
>>
>> >
>> >
>> > On Sun, May 27, 2018, 3:58 PM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> On 27 May 2018 at 15:29, Scott Marlow <smarlow at redhat.com> wrote:
>> >> >
>> >> >
>> >> > On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero
>> >> > <sanne at hibernate.org>
>> >> > wrote:
>> >> >>
>> >> >> On 27 May 2018 at 00:30, Scott Marlow <smarlow at redhat.com> wrote:
>> >> >> > Next idea, we should first look for the WFTC classes, if not
>> >> >> > found,
>> >> >> > then
>> >> >> > look for Arjuna classes.
>> >> >>
>> >> >> +1 that would be nice and I see other implementations e.g.
>> >> >> JBossAppServerJtaPlatform have a precedent of attempting multiple
>> >> >> strategies to maintain backward compatibility.
>> >> >>
>> >> >> Created:
>> >> >>  - https://hibernate.atlassian.net/browse/HHH-12640
>> >> >
>> >> >
>> >> > https://github.com/hibernate/hibernate-orm/pull/2314
>> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> Regarding the use of the old Arjuna name: you might be right that it
>> >> >> shouldn't be used, but it's still very common:
>> >> >>
>> >> >> even the Narayana quickstarts using Hibernate are broken by this
>> >> >> change, and so is any application running on WildFly Swarm or
>> >> >> Thorntail.
>> >> >>
>> >> >> I suppose something should be improved on their side as well, yet we
>> >> >> should give people time (by making it compatible like you suggested)
>> >> >> and help at least with some documented guidance - the fallback
>> >> >> strategy could log a warning to motivate people to update but IMO we
>> >> >> should start bugging people with such messages only when the other
>> >> >> runtimes and examples ship with the new defaults.
>> >> >>
>> >> >> Hibernate Search also has integration tests with Narayana
>> >> >> (standalone
>> >> >> JTA) and it's not clear to me now which dependencies I should be
>> >> >> changing; I suppose I'll figure it out soon as I need to release it
>> >> >> too :)
>> >> >>
>> >> >> The user experience after this error is quite bad: applications now
>> >> >> simply fail to start with a confusing
>> >> >> "javax.persistence.PersistenceException: No Persistence provider for
>> >> >> EntityManager named XYZ found", we give no better error and no clue
>> >> >> about needing to look into the used transactions implementation.
>> >> >>
>> >> >> Created:
>> >> >>  - https://hibernate.atlassian.net/browse/HHH-12639
>> >> >>
>> >> >> Thanks,
>> >> >> Sanne
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > On Sat, May 26, 2018, 7:12 PM Scott Marlow <smarlow at redhat.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> On Sat, May 26, 2018, 6:05 PM Scott Marlow <smarlow at redhat.com>
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> Or, maybe we should just remove the JBOSS_TM_CLASS_NAME +
>> >> >> >>> JBOSS_UT_CLASS_NAME class references and instead JNDI lookup
>> >> >> >>> using
>> >> >> >>> the
>> >> >> >>> standard JBoss TM/UT JNDI names.
>> >> >> >>
>> >> >> >>
>> >> >> >> This wouldn't work for standard alone mode, as there wouldn't be
>> >> >> >> any
>> >> >> >> jndi
>> >> >> >> services.  Guess, we are stuck with using class name references.
>> >> >> >>
>> >> >> >>>
>> >> >> >>> On Sat, May 26, 2018 at 5:05 PM, Scott Marlow
>> >> >> >>> <smarlow at redhat.com>
>> >> >> >>> wrote:
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero
>> >> >> >>>> <sanne at hibernate.org>
>> >> >> >>>> wrote:
>> >> >> >>>>>
>> >> >> >>>>> Hi Scott,
>> >> >> >>>>>
>> >> >> >>>>> I see you changed JBossStandAloneJtaPlatform to use a new API
>> >> >> >>>>> in
>> >> >> >>>>> WildFly;
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> More that in WildFly 13, applications shouldn't use the Arjuna
>> >> >> >>>> TM
>> >> >> >>>> classes directly anymore.  The WildFly Transaction Client wraps
>> >> >> >>>> the
>> >> >> >>>> Arjuna
>> >> >> >>>> TM and maintains correct TX status.
>> >> >> >>>>
>> >> >> >>>>>
>> >> >> >>>>> this breaks all existing applications using a generic "JBoss -
>> >> >> >>>>> standalone" platform which isn't using the very latest
>> >> >> >>>>> WildFly.
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> Hmm, thinking more about this, also broken, are any ORM 5.1.x
>> >> >> >>>> applications that depend on JBossStandAloneJtaPlatform to
>> >> >> >>>> choose
>> >> >> >>>> the
>> >> >> >>>> WildFly
>> >> >> >>>> TM.  JPA container managed applications won't have this
>> >> >> >>>> problem.
>> >> >> >>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> I see that in many cases this type is auto-detected - and
>> >> >> >>>>> while
>> >> >> >>>>> JBossStandAloneJtaPlatform causes an exception this is
>> >> >> >>>>> swallowed
>> >> >> >>>>> by
>> >> >> >>>>> the HibernatePersistenceProvider as any exception is only
>> >> >> >>>>> mentioned
>> >> >> >>>>> at
>> >> >> >>>>> debug level (line 61).
>> >> >
>> >> >
>> >> > This sounds correct, as all persistence providers are given a chance,
>> >> > to
>> >> > try
>> >> > deploying a persistence provider when
>> >> > Persistence.createEntityManagerFactory() (or other calls, like
>> >> > generateSchema()) are made.
>> >>
>> >> I'm aware of how the selection is meant to work, but shouldn't we be
>> >> able to differentiate between the typical scenario "this configuration
>> >> is not meant for me" vs the scenario of an unintended failure because
>> >> of an internal exception?
>> >>
>> >> Especially as in this case you claim it's the user's fault that an
>> >> exception happens, as the user is having an out of date, incompatible
>> >> library on the classpath. Clearly, we shouldn't swallow the error as
>> >> it makes it massively difficult to suggest some upgrades need to be
>> >> explored.
>> >>
>> >> IMO it would be very reasonable to change the exception log from debug
>> >> to warn/error but indeed I'm asking here as I understand the TCK /
>> >> spec intent might disagree with this. I doubt the TCK tests for
>> >> absence of error messaged being logged though?
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >>
>> >>
>> >> >
>> >> >>
>> >> >> >>>>>
>> >> >> >>>>> So two questions:
>> >> >> >>>>>  - could this be reverted and you introduce some new-gen
>> >> >> >>>>> WildflyStandAloneJtaPlatform instead?
>> >> >
>> >> >
>> >> > Yes, good idea https://github.com/hibernate/hibernate-orm/pull/2314
>> >> >
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> Not sure, since the WildFly Transaction Client (WFTC) module is
>> >> >> >>>> also
>> >> >> >>>> in
>> >> >> >>>> earlier WF releases.  I'm not exactly sure of when the WFTC TM
>> >> >> >>>> replaces
>> >> >> >>>> Arjuna TM.  David, is that new for WF13?
>> >> >> >>>>
>> >> >> >>>> We can get more correct in ORM 5.3.x to align with WF 13, but
>> >> >> >>>> not
>> >> >> >>>> sure
>> >> >> >>>> about ORM 5.1 JBossStandAloneJtaPlatform still referencing
>> >> >> >>>> Arjuna
>> >> >> >>>> TM
>> >> >> >>>> directly.  Seems like that is also a problem.
>> >> >> >>>>
>> >> >> >>>>>
>> >> >> >>>>>  - bootstrap exceptions: may I change those to error level?
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> No idea.
>> >> >> >>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> Thanks,
>> >> >> >>>>> Sanne
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>
>> >> >> >
>> >> >
>> >> >
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From yoann at hibernate.org  Mon Jun  4 10:19:18 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Mon, 4 Jun 2018 16:19:18 +0200
Subject: [hibernate-dev] [NoORM] A simpler README.md?
In-Reply-To: <CADGJaX89YmTp9X8FsNbAEZh_4kkHyNkTgojk50OErp32TpQurw@mail.gmail.com>
References: <CAEqagpq8Zom-tq4_ttE1iN6TT0OPrcmZyn4dedLrFfu6sm1ZfA@mail.gmail.com>
	<CAFm4XO0ASq3Z65-YP5jkvGVYvZOsRLESc1LcD02BqKKZp0bH2A@mail.gmail.com>
	<CADGJaX89YmTp9X8FsNbAEZh_4kkHyNkTgojk50OErp32TpQurw@mail.gmail.com>
Message-ID: <CAEqagpq3vWKhR_j=of1t3LwjmruvGAJDn6eXmDQcWyVTSX0uVA@mail.gmail.com>

> So please do not make changes that impact the release process in this
regard (or make it conditional to Search).

Sure.

> The historical objection has been that many users get the zip of our project
on a floppy disk and have no access to the internet.

Right, but in this case the information I'm removing is also present in the
reference documentation (near the top, at the beginning of the getting
started guide). Also, part of it is about downloading from Sourceforge
using Maven coordinates, so it doesn't seem like important information to
these people.

In the long run, I think the getting started guide from our website should
be merged with the one from our reference documentation. Then we would put
it somewhere it can be easily found, either directly in the reference
documentation, or in a separate folder next to the reference documentation
folder and the javadoc folder. We would then have an unambiguous place to
start from, addressing a specific version. And we would also potentially
have a clear, offline getting started guide that we could refer to from the
README.
But that's an orthogonal matter, I think.

> No strong preference on my side, but I found this project of Lauri Apple
very useful:

Thanks, this looks helpful indeed. Not sure I will follow all of their
recommendations, since their model seems to start from the premise that all
the documentation should be in the README (???), but it's definitely useful
to list everything that should be mentioned in some way.

On Mon, 4 Jun 2018 at 14:44 Gunnar Morling <gunnar at hibernate.org> wrote:

> No strong preference on my side, but I found this project of Lauri Apple
> very useful:
>
>     https://github.com/LappleApple/feedmereadmes
>
> You can ask for input on your README file there (they may send a PR for
> updating it) and it also contains a "README maturity model". Perhaps it's
> helpful for you, too.
>
> --Gunnar
>
>
> 2018-06-04 14:32 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
>> The historical objection has been that many users get the zip of our
>> project on a floppy disk and have no access to the internet.
>>
>> That might be an obsolete statement nowadays? They'll use a
>> USB stick today ;)
>>
>> Still, we know that e.g. people in China and similar places can't
>> always access our online resources, even if they "have internet".
>> University assignments/labs might have similar limitations even in Europe.
>>
>> I have no strong objections, do it if you feel strongly about this
>> "inconsistency".
>>
>> Personally, it hasn't bothered me much to occasionally have to update
>> the README, and I don't think people will expect that a zip they keep
>> in a drawer will be the better source of information if they happen to
>> have access to hibernate.org
>>
>> Cheers,
>> Sanne
>>
>>
>>
>> On 4 June 2018 at 12:51, Yoann Rodiere <yoann at hibernate.org> wrote:
>> > Hi everyone,
>> >
>> > TL;DR: I would like to strip down the README in Hibernate Search to
>> > redirect users to the website, which is better suited for presenting
>> > available versions, and helping users to get started. See what I mean
>> in this
>> > PR <https://github.com/hibernate/hibernate-search/pull/1692>. Any
>> > objections?
>> >
>> > Currently, the README.md in NoORM projects duplicates a bit of
>> information
>> > from our website and documentation:
>> >
>> >    - The version number and date of the latest release:
>> >    https://github.com/hibernate/hibernate-search#hibernate-search vs.
>> >    http://hibernate.org/search/releases/
>> >    - A description of the project:
>> >    https://github.com/hibernate/hibernate-search#description vs.
>> >    http://hibernate.org/search/
>> >    - The requirements:
>> >    https://github.com/hibernate/hibernate-search#requirements vs.
>> >    http://hibernate.org/search/releases/#compatibility-matrix or
>> >    http://hibernate.org/search/releases/5.10/#compatibility
>> >    - Installation instructions:
>> >    https://github.com/hibernate/hibernate-search#maven +
>> >    https://github.com/hibernate/hibernate-search#sourceforge-bundle vs.
>> >    http://hibernate.org/search/releases/5.10/#get-it or
>> >    http://hibernate.org/search/documentation/getting-started/
>> >
>> >
>> > Some of this information is updated manually when we don'r forget about
>> it,
>> > and some of it (the latest release) is updated automatically when we
>> > perform a release on master.
>> >
>> > As a result, from time to time the information is not in sync. Right
>> now,
>> > in Search, the version displayed in the README is 5.10.0.Final, whereas
>> the
>> > latest release is 5.10.1.Final and the master branch hosts the
>> > 5.11.0-SNAPSHOT code. This is because the release scripts do not update
>> > master when we release from another branch, and we have to do it
>> manually
>> > (that's expected: doing otherwise would be too complex).
>> >
>> > Also, the information is partial:
>> >
>> >    - the README currently completely hides the fact that other Hibernate
>> >    Search versions are still maintained and can work well with older
>> versions
>> >    of Hibernate ORM.
>> >    - whenever the latest release is an alpha/beta/CR, we usually display
>> >    installation instructions for the latest development version, and
>> >    completely hide information about the latest stable version.
>> >
>> > What's worse, keeping the documentation on branch master the README on
>> > branch master may prove confusing: the README refers to the latest
>> release,
>> > but the rest of the code may have been updated since the latest release,
>> > sometimes significantly so. We will have trouble dealing with this when
>> we
>> > merge Hibernate Search 6, in particular.
>> >
>> > We may not agree on what is the best solution, but let's at least agree
>> > this is not ideal, especially when it comes to informing users about the
>> > stable version they want to use.
>> >
>> > We could put in more effort, try our very best to keep everything in
>> sync
>> > and as complete as possible/necessary. Add more documentation about the
>> > release process. Try our best to do less mistakes. We could. But
>> obviously,
>> > nobody is perfect, and so never will this README.
>> >
>> > Other projects, such as Spring Boot (
>> > https://github.com/spring-projects/spring-boot) or, more relevantly,
>> > Hibernate ORM (https://github.com/hwithibernate/hibernate-orm
>> > <https://github.com/hibernate/hibernate-orm>), simply do not refer to
>> the
>> > latest version in their README, and redirect to their website for all
>> > version-specific information. The README focuses on presenting the
>> project,
>> > redirecting users to the website, and giving contributor-friendly
>> > information.
>> >
>> > I find this solution both elegant and powerful. Presenting the project
>> is
>> > always necessary, but guiding users to the right version and giving
>> getting
>> > started instructions is something complex, and something we already do
>> on
>> > our website. So why not redirect people there? All links stay valid and
>> > relevant as long as the website is up and kept updated, and the impact
>> of
>> > maintainers forgetting to update the README is far smaller. One less
>> thing
>> > to worry about for maintainers, and better guidance for prospective
>> users.
>> >
>> > A simple link to the getting started guide could be enough for most
>> users,
>> > but we can go a step further and offer additional links. I just sent a
>> pull
>> > request to show how I see it implemented in Search; please let me know
>> what
>> > you think.
>> > The PR: https://github.com/hibernate/hibernate-search/pull/1692
>> > Preview of the README as seen from the GitHub web view:
>> >
>> https://github.com/yrodiere/hibernate-search/blob/ae4d347fa4c647a3c5ddb6f43412cf3dce0e354e/README.md
>> >
>> > Cheers,
>> > --
>> > Yoann Rodiere
>> > yoann at hibernate.org / yrodiere at redhat.com
>> > Software Engineer
>> > Hibernate NoORM team
>> > _______________________________________________
>> > 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
>>
>
> --
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From rory.odonnell at oracle.com  Tue Jun  5 04:36:24 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 5 Jun 2018 09:36:24 +0100
Subject: [hibernate-dev] JDK 11 Early Access build 15 is available for
 download.
In-Reply-To: <bf944b3d-df79-ef01-90b9-b6eea0aa8cc2@oracle.com>
References: <d901e688-14cd-483c-a2cf-6ea6810e9f25@oracle.com>
	<CAFm4XO1yUn==8UoCqSUDRzWt082F5iLLWz08n=yAExH1gk9ZHw@mail.gmail.com>
	<bf944b3d-df79-ef01-90b9-b6eea0aa8cc2@oracle.com>
Message-ID: <3e82e0df-8b36-89f5-7ec5-9c9faa72ca1d@oracle.com>

Hi Sanne,

b15 has been superseded by b16, looks like downloads are working. Thanks 
for reporting the issue.

Rgds,Rory
On 31/05/2018 16:00, Rory O'Donnell wrote:
> Thanks Sanne, we are looking into it.
>
> Rgds,Rory
>
>
> On 31/05/2018 15:59, Sanne Grinovero wrote:
>> Hi Rory,
>>
>> I was trying to download the OpenJDK / Linux distribution from
>> http://jdk.java.net/11/, but it seems to link to [1] which returns a
>> 404 error page.
>>
>> I'll use the Oracle / Linux build in the meantime.
>>
>> Thanks,
>> Sanne
>>
>> 1 - 
>> https://download.java.net/java/early_access/jdk11/15/GPL/openjdk-11-ea+15_linux-x64_bin.tar.gz
>>
>>
>> On 29 May 2018 at 10:51, Rory O'Donnell <rory.odonnell at oracle.com> 
>> wrote:
>>> Hi Sanne,
>>>
>>> **JDK 11 EA build 15 , *****under both the GPL and Oracle EA licenses,
>>> is now available at **http://jdk.java.net/11**. **
>>> *
>>>
>>> ?? * Newly approved Schedule, status & features
>>> ?????? o http://openjdk.java.net/projects/jdk/11/
>>> ?? * Release Notes:
>>> ?????? o http://jdk.java.net/11/release-notes
>>> ?? * Summary of changes
>>> ?????? o http://jdk.java.net/11/changes
>>>
>>> *Notable changes in JDK 11 EA builds since last email:*
>>>
>>> ?? * b15 - JDK-8201627 
>>> <http://bugs.openjdk.java.net/browse/JDK-8201627>
>>> ???? - Kerberos sequence number issues
>>> ?? * b13 - JDK-8200146 
>>> <http://bugs.openjdk.java.net/browse/JDK-8200146>
>>> ???? - Removal of appletviewer launcher
>>> ?????? o deprecated in JDK 9 and has been removed in this release
>>> ?? * b13 - JDK-8201793 
>>> <http://bugs.openjdk.java.net/browse/JDK-8201793>
>>> ???? - java.lang.ref.Reference does not support cloning
>>>
>>> **
>>>
>>> **
>>>
>>> JEPs proposed to target JDK 11 (review ends 2018/05/31 23:00 UTC)
>>>
>>> ???? 330: Launch Single-File Source-Code Programs
>>> ???? <http://openjdk.java.net/jeps/330>
>>>
>>> ???? JEPs targeted to JDK 11, so far
>>>
>>> ???? 309: Dynamic Class-File Constants 
>>> <http://openjdk.java.net/jeps/309>
>>> ???? 318: Epsilon: A No-Op Garbage Collector
>>> ???? <http://openjdk.java.net/jeps/318>
>>> ???? 320: Remove the Java EE and CORBA Modules
>>> ???? <http://openjdk.java.net/jeps/320>
>>> ???? 321: HTTP Client (Standard) <http://openjdk.java.net/jeps/321>
>>> ???? 323: Local-Variable Syntax for Lambda Parameters
>>> ???? <http://openjdk.java.net/jeps/323>
>>> ???? 324: Key Agreement with Curve25519 and Curve448
>>> ???? <http://openjdk.java.net/jeps/324>
>>> ???? 327: Unicode 10 <http://openjdk.java.net/jeps/327>
>>> ???? 328: Flight Recorder <http://openjdk.java.net/jeps/328>
>>> ???? 329: ChaCha20 and Poly1305 Cryptographic Algorithms
>>> ???? <http://openjdk.java.net/jeps/329>
>>>
>>> Finally, Initial TLSv1.3 implementation Released to the Open Sandbox.
>>> Please note well: this branch is under
>>> very active development and is not final by any means. Also note: by
>>> releasing this code, we are not committing
>>> a specific release or timeframe. We will continue development and 
>>> fixing
>>> bugs until the code is ready for inclusion
>>> in the JDK. We welcome your feedback, more info [1]
>>>
>>>
>>> Regards,
>>> Rory
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html 
>>>
>>>
>>> -- 
>>> 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 smarlow at redhat.com  Tue Jun  5 09:43:51 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 5 Jun 2018 09:43:51 -0400
Subject: [hibernate-dev] What should be the contract for
 PersistenceUnitInfo#addTransformer with regard to multiple persistence
 units mapping the same entity class?
Message-ID: <CAJtdNN4KbmjrwjG3rhBhBfPFUZ2D8hAjKORyCHtx3WesF-0pGg@mail.gmail.com>

The PersistenceUnitInfo#addTransformer javadoc [1] mentions:

"
Add a transformer supplied by the provider that will be called for every
new class definition or class redefinition that gets loaded by the loader
returned by the getClassLoader()
<https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getClassLoader-->
method. The transformer has no effect on the result returned by the
getNewTempClassLoader()
<https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader-->
method. Classes are only transformed once within the same classloading
scope, regardless of how many persistence units they may be a part of.
"

Should we have a check somewhere that prevents the same entity class from
being enhanced multiple times?  Should the check be in the JPA container or
in the persistence provider?  Thought I would check here in case anyone
remembers the background of where the check was intended to be exactly.

I assume that WildFly might be the best place to have the check but wanted
to ask here first, because if the JPA container does the checking, that
will mean that ORM will only be able to register one class transformer per
persistence unit.  WildFly will also have to prevent other persistence
units from transforming the same entity class in a different thread (e.g.
since we typically deploy all of the persistence units in parallel, we will
need some synchronization).

Scott

[1]
https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#addTransformer-javax.persistence.spi.ClassTransformer-

[2] https://github.com/wildfly/wildfly/pull/11297

From lbarreiro at redhat.com  Tue Jun  5 12:19:15 2018
From: lbarreiro at redhat.com (Luis Barreiro)
Date: Tue, 5 Jun 2018 17:19:15 +0100
Subject: [hibernate-dev] What should be the contract for
 PersistenceUnitInfo#addTransformer with regard to multiple persistence
 units mapping the same entity class?
In-Reply-To: <CAJtdNN4KbmjrwjG3rhBhBfPFUZ2D8hAjKORyCHtx3WesF-0pGg@mail.gmail.com>
References: <CAJtdNN4KbmjrwjG3rhBhBfPFUZ2D8hAjKORyCHtx3WesF-0pGg@mail.gmail.com>
Message-ID: <4fb5f7b4-b854-6221-1221-49433278e282@redhat.com>

Hi Scott,

In the particular case of the hibernate bytecode enhancer, it adds the 
org.hibernate.engine.spi.Managed marker interface to the entity so that 
it only performs the enhancement once. (that implies that you can't have 
the same entity enhanced for different features in the same class loader)

Also, in theory, you could have multiple transformations applied to the 
same entity / PU. So what is it you really want to check ?!

I don't get you last paragraph ... why ORM will be only capable of 
registering one transformer, and why will you need synchronization ?!

Regards,

Luis Barreiro

Middleware Performance Team

<https://red.ht/sig>

On 06/05/2018 02:43 PM, Scott Marlow wrote:
> The PersistenceUnitInfo#addTransformer javadoc [1] mentions:
>
> "
> Add a transformer supplied by the provider that will be called for every
> new class definition or class redefinition that gets loaded by the loader
> returned by the getClassLoader()
> <https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getClassLoader-->
> method. The transformer has no effect on the result returned by the
> getNewTempClassLoader()
> <https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader-->
> method. Classes are only transformed once within the same classloading
> scope, regardless of how many persistence units they may be a part of.
> "
>
> Should we have a check somewhere that prevents the same entity class from
> being enhanced multiple times?  Should the check be in the JPA container or
> in the persistence provider?  Thought I would check here in case anyone
> remembers the background of where the check was intended to be exactly.
>
> I assume that WildFly might be the best place to have the check but wanted
> to ask here first, because if the JPA container does the checking, that
> will mean that ORM will only be able to register one class transformer per
> persistence unit.  WildFly will also have to prevent other persistence
> units from transforming the same entity class in a different thread (e.g.
> since we typically deploy all of the persistence units in parallel, we will
> need some synchronization).
>
> Scott
>
> [1]
> https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#addTransformer-javax.persistence.spi.ClassTransformer-
>
> [2] https://github.com/wildfly/wildfly/pull/11297
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Tue Jun  5 13:06:54 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 5 Jun 2018 18:06:54 +0100
Subject: [hibernate-dev] What should be the contract for
 PersistenceUnitInfo#addTransformer with regard to multiple persistence
 units mapping the same entity class?
In-Reply-To: <CAJtdNN4KbmjrwjG3rhBhBfPFUZ2D8hAjKORyCHtx3WesF-0pGg@mail.gmail.com>
References: <CAJtdNN4KbmjrwjG3rhBhBfPFUZ2D8hAjKORyCHtx3WesF-0pGg@mail.gmail.com>
Message-ID: <CAFm4XO2fQmSOUPHmcLwghLa=tCen-dRmkArgG4Nn7EGvxyBf8w@mail.gmail.com>

On 5 June 2018 at 14:43, Scott Marlow <smarlow at redhat.com> wrote:
> The PersistenceUnitInfo#addTransformer javadoc [1] mentions:
>
> "
> Add a transformer supplied by the provider that will be called for every
> new class definition or class redefinition that gets loaded by the loader
> returned by the getClassLoader()
> <https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getClassLoader-->
> method. The transformer has no effect on the result returned by the
> getNewTempClassLoader()
> <https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader-->
> method. Classes are only transformed once within the same classloading
> scope, regardless of how many persistence units they may be a part of.
> "
>
> Should we have a check somewhere that prevents the same entity class from
> being enhanced multiple times?  Should the check be in the JPA container or
> in the persistence provider?  Thought I would check here in case anyone
> remembers the background of where the check was intended to be exactly.

I suspect it's necessary to do this check in the container.

If you do it in the persistence provider, how can you guarantee that
another persistence provider is not keeping track independently?

> I assume that WildFly might be the best place to have the check but wanted
> to ask here first, because if the JPA container does the checking, that
> will mean that ORM will only be able to register one class transformer per
> persistence unit.  WildFly will also have to prevent other persistence
> units from transforming the same entity class in a different thread (e.g.
> since we typically deploy all of the persistence units in parallel, we will
> need some synchronization).

+1

>
> Scott
>
> [1]
> https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#addTransformer-javax.persistence.spi.ClassTransformer-
>
> [2] https://github.com/wildfly/wildfly/pull/11297
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From smarlow at redhat.com  Tue Jun  5 14:08:35 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 5 Jun 2018 14:08:35 -0400
Subject: [hibernate-dev] What should be the contract for
 PersistenceUnitInfo#addTransformer with regard to multiple persistence
 units mapping the same entity class?
In-Reply-To: <4fb5f7b4-b854-6221-1221-49433278e282@redhat.com>
References: <CAJtdNN4KbmjrwjG3rhBhBfPFUZ2D8hAjKORyCHtx3WesF-0pGg@mail.gmail.com>
	<4fb5f7b4-b854-6221-1221-49433278e282@redhat.com>
Message-ID: <CAJtdNN6o1OXwE3rNCZjqh8kX-Ptj-hBocfEhx+ubDaimkp6x+w@mail.gmail.com>

Thanks, I think they probably intended that the persistence provider would
use a marker interface like org.hibernate.engine.spi.Managed to ensure that
the enhancement is only done once.  Responses to your questions are inline
below.

On Tue, Jun 5, 2018 at 12:19 PM, Luis Barreiro <lbarreiro at redhat.com> wrote:

> Hi Scott,
>
> In the particular case of the hibernate bytecode enhancer, it adds the
> org.hibernate.engine.spi.Managed marker interface to the entity so that
> it only performs the enhancement once. (that implies that you can't have
> the same entity enhanced for different features in the same class loader)
>
> Also, in theory, you could have multiple transformations applied to the
> same entity / PU. So what is it you really want to check ?!
>
Mostly, I'm trying to understand why the [1] javadoc requires that classes
are only transformed only once, as I would expect that some persistence
providers could want to register multiple transformers.

> I don't get you last paragraph ... why ORM will be only capable of
> registering one transformer,
>
If we update the WildFly JPA container  JPADelegatingClassFileTransformer
[2] to only allow the application entity class to be enhanced at most once
(at runtime), ORM would be able to register multiple transformers but the
first ORM transformer that actually enhances the entity class (e.g.
transformer returns non-null return value), would need to terminate the
"for each transformer" loop in [2].

Since, as you said, ORM is already using a marker interface to know when a
class is already enhanced, it sounds like WildFly doesn't really need to
enforce the [1] contract (with regard to only transforming the entity class
once).


> and why will you need synchronization ?!
>
If WildFly JPADelegatingClassFileTransformer [2] where modified to prevent
more than one transformation of an entity class, that would include
checking across (parallel) persistence unit deployment threads, which could
be done with a Java synchronization lock.

Scott

[1]
https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#addTransformer-javax.persistence.spi.ClassTransformer-

[2]
https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/java/org/jboss/as/jpa/classloader/JPADelegatingClassFileTransformer.java#L44

From smarlow at redhat.com  Tue Jun  5 14:14:07 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 5 Jun 2018 14:14:07 -0400
Subject: [hibernate-dev] What should be the contract for
 PersistenceUnitInfo#addTransformer with regard to multiple persistence
 units mapping the same entity class?
In-Reply-To: <CAFm4XO2fQmSOUPHmcLwghLa=tCen-dRmkArgG4Nn7EGvxyBf8w@mail.gmail.com>
References: <CAJtdNN4KbmjrwjG3rhBhBfPFUZ2D8hAjKORyCHtx3WesF-0pGg@mail.gmail.com>
	<CAFm4XO2fQmSOUPHmcLwghLa=tCen-dRmkArgG4Nn7EGvxyBf8w@mail.gmail.com>
Message-ID: <CAJtdNN4KLkzair5fDNx_NcmXxdmhE=iT2VoNrE6cJj5ZDjyi=w@mail.gmail.com>

On Tue, Jun 5, 2018 at 1:06 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> On 5 June 2018 at 14:43, Scott Marlow <smarlow at redhat.com> wrote:
> > The PersistenceUnitInfo#addTransformer javadoc [1] mentions:
> >
> > "
> > Add a transformer supplied by the provider that will be called for every
> > new class definition or class redefinition that gets loaded by the loader
> > returned by the getClassLoader()
> > <https://docs.oracle.com/javaee/7/api/javax/persistence/spi/
> PersistenceUnitInfo.html#getClassLoader-->
> > method. The transformer has no effect on the result returned by the
> > getNewTempClassLoader()
> > <https://docs.oracle.com/javaee/7/api/javax/persistence/spi/
> PersistenceUnitInfo.html#getNewTempClassLoader-->
> > method. Classes are only transformed once within the same classloading
> > scope, regardless of how many persistence units they may be a part of.
> > "
> >
> > Should we have a check somewhere that prevents the same entity class from
> > being enhanced multiple times?  Should the check be in the JPA container
> or
> > in the persistence provider?  Thought I would check here in case anyone
> > remembers the background of where the check was intended to be exactly.
>
> I suspect it's necessary to do this check in the container.
>

For WildFly, the checking would be important when there are multiple
persistence units that include the same entity class(es), to ensure that
only one thread does the transformation, however, the
Hibernate org.hibernate.engine.spi.Managed marker interface may provide
enough protection.



>
> If you do it in the persistence provider, how can you guarantee that
> another persistence provider is not keeping track independently?
>
> > I assume that WildFly might be the best place to have the check but
> wanted
> > to ask here first, because if the JPA container does the checking, that
> > will mean that ORM will only be able to register one class transformer
> per
> > persistence unit.  WildFly will also have to prevent other persistence
> > units from transforming the same entity class in a different thread (e.g.
> > since we typically deploy all of the persistence units in parallel, we
> will
> > need some synchronization).
>
> +1
>
> >
> > Scott
> >
> > [1]
> > https://docs.oracle.com/javaee/7/api/javax/persistence/spi/
> PersistenceUnitInfo.html#addTransformer-javax.persistence.spi.
> ClassTransformer-
> >
> > [2] https://github.com/wildfly/wildfly/pull/11297
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Tue Jun  5 14:21:36 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 5 Jun 2018 14:21:36 -0400
Subject: [hibernate-dev] What should be the contract for
 PersistenceUnitInfo#addTransformer with regard to multiple persistence
 units mapping the same entity class?
In-Reply-To: <CAFm4XO2fQmSOUPHmcLwghLa=tCen-dRmkArgG4Nn7EGvxyBf8w@mail.gmail.com>
References: <CAJtdNN4KbmjrwjG3rhBhBfPFUZ2D8hAjKORyCHtx3WesF-0pGg@mail.gmail.com>
	<CAFm4XO2fQmSOUPHmcLwghLa=tCen-dRmkArgG4Nn7EGvxyBf8w@mail.gmail.com>
Message-ID: <CAJtdNN5PkSgjVSOPyT5_dTE38GhCrwPEdbXgo3og8+GJrVC5Dw@mail.gmail.com>

Sorry, I hit send too soon, response inline below...

On Tue, Jun 5, 2018 at 1:06 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> On 5 June 2018 at 14:43, Scott Marlow <smarlow at redhat.com> wrote:
> > The PersistenceUnitInfo#addTransformer javadoc [1] mentions:
> >
> > "
> > Add a transformer supplied by the provider that will be called for every
> > new class definition or class redefinition that gets loaded by the loader
> > returned by the getClassLoader()
> > <https://docs.oracle.com/javaee/7/api/javax/persistence/spi/
> PersistenceUnitInfo.html#getClassLoader-->
> > method. The transformer has no effect on the result returned by the
> > getNewTempClassLoader()
> > <https://docs.oracle.com/javaee/7/api/javax/persistence/spi/
> PersistenceUnitInfo.html#getNewTempClassLoader-->
> > method. Classes are only transformed once within the same classloading
> > scope, regardless of how many persistence units they may be a part of.
> > "
> >
> > Should we have a check somewhere that prevents the same entity class from
> > being enhanced multiple times?  Should the check be in the JPA container
> or
> > in the persistence provider?  Thought I would check here in case anyone
> > remembers the background of where the check was intended to be exactly.
>
> I suspect it's necessary to do this check in the container.
>

For WildFly, the checking would be important when there are multiple
persistence units that include the same entity class(es), to ensure that
only one thread does the transformation, however, the Hibernate
org.hibernate.engine.spi.Managed marker interface may provide enough
protection.


>
> If you do it in the persistence provider, how can you guarantee that
> another persistence provider is not keeping track independently?
>

IMO, That would be a doubly bad practice, multiple persistence units
mapping the same entity class with different persistence providers used for
each persistence unit but your right, only the JPA container could prevent
that.


>
> > I assume that WildFly might be the best place to have the check but
> wanted
> > to ask here first, because if the JPA container does the checking, that
> > will mean that ORM will only be able to register one class transformer
> per
> > persistence unit.  WildFly will also have to prevent other persistence
> > units from transforming the same entity class in a different thread (e.g.
> > since we typically deploy all of the persistence units in parallel, we
> will
> > need some synchronization).
>
> +1
>

I don't intend to make any WF code changes for this now, as I think the ORM
Managed marker interface is enough (IMO).

Thanks for the feedback!

Scott


> >
> > Scott
> >
> > [1]
> > https://docs.oracle.com/javaee/7/api/javax/persistence/spi/
> PersistenceUnitInfo.html#addTransformer-javax.persistence.spi.
> ClassTransformer-
> >
> > [2] https://github.com/wildfly/wildfly/pull/11297
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From lbarreiro at redhat.com  Tue Jun  5 15:38:27 2018
From: lbarreiro at redhat.com (Luis Barreiro)
Date: Tue, 5 Jun 2018 20:38:27 +0100
Subject: [hibernate-dev] What should be the contract for
 PersistenceUnitInfo#addTransformer with regard to multiple persistence
 units mapping the same entity class?
In-Reply-To: <CAJtdNN6o1OXwE3rNCZjqh8kX-Ptj-hBocfEhx+ubDaimkp6x+w@mail.gmail.com>
References: <CAJtdNN4KbmjrwjG3rhBhBfPFUZ2D8hAjKORyCHtx3WesF-0pGg@mail.gmail.com>
	<4fb5f7b4-b854-6221-1221-49433278e282@redhat.com>
	<CAJtdNN6o1OXwE3rNCZjqh8kX-Ptj-hBocfEhx+ubDaimkp6x+w@mail.gmail.com>
Message-ID: <63776239-7767-f67b-cf61-54eef51664f7@redhat.com>

My reading on that javadoc is that you only get the transformation once 
(the first time that a class is loaded) and after that, if it's used by 
other PUs, it may not get the transformations those PUs specify.

I would like to add that the enhancer is synchronous (it only enhance 
one class at a time), hence my question about synchronization, but you 
were obviously looking at a different level.

Regards,

Luis Barreiro

Middleware Performance Team

<https://red.ht/sig>

On 06/05/2018 07:08 PM, Scott Marlow wrote:
> Thanks, I think they probably intended that the persistence provider 
> would use a marker interface like org.hibernate.engine.spi.Managed to 
> ensure that the enhancement is only done once.? Responses to your 
> questions are inline below.
>
> On Tue, Jun 5, 2018 at 12:19 PM, Luis Barreiro <lbarreiro at redhat.com 
> <mailto:lbarreiro at redhat.com>> wrote:
>
>     Hi Scott,
>
>     In the particular case of the hibernate bytecode enhancer, it adds
>     the org.hibernate.engine.spi.Managed marker interface to the
>     entity so that it only performs the enhancement once. (that
>     implies that you can't have the same entity enhanced for different
>     features in the same class loader)
>
>     Also, in theory, you could have multiple transformations applied
>     to the same entity / PU. So what is it you really want to check ?!
>
> Mostly, I'm trying to understand why the [1] javadoc requires that 
> classes are only transformed only once, as I would expect that some 
> persistence providers could want to register multiple transformers.
>
>     I don't get you last paragraph ... why ORM will be only capable of
>     registering one transformer,
>
> If we update the WildFly JPA container 
> JPADelegatingClassFileTransformer [2] to only allow the application 
> entity class to be enhanced at most once (at runtime), ORM would be 
> able to register multiple transformers but the first ORM transformer 
> that actually enhances the entity class (e.g. transformer returns 
> non-null return value), would need to terminate the "for each 
> transformer" loop in [2].
>
> Since, as you said, ORM is already using a marker interface to know 
> when a class is already enhanced, it sounds like WildFly doesn't 
> really need to enforce the [1] contract (with regard to only 
> transforming the entity class once).
>
>     and why will you need synchronization ?!
>
> If WildFly JPADelegatingClassFileTransformer [2] where modified to 
> prevent more than one transformation of an entity class, that would 
> include checking across (parallel) persistence unit deployment 
> threads, which could be done with a Java synchronization lock.
>
> Scott
>
> [1] 
> https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#addTransformer-javax.persistence.spi.ClassTransformer-
>
> [2] 
> https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/java/org/jboss/as/jpa/classloader/JPADelegatingClassFileTransformer.java#L44


From gbadner at redhat.com  Tue Jun  5 16:18:56 2018
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 5 Jun 2018 13:18:56 -0700
Subject: [hibernate-dev] Hibernate ORM 5.2.18 to be the last in 5.2 series?
Message-ID: <CAFDzhiQMG0MO1fr42jr=aqmm=dxQEaR+khfUcsDsK8G62PwpbA@mail.gmail.com>

Now that 5.3 is out and is in the the process of being stabilized, and
active development is shifting to 6.0, it seems like a good time to wrap up
work on the 5.2 series.

Chris mentioned that he is planning to release 5.2.18 on Thursday.

Does anyone have a compelling reason why we should continue beyond 5.2.18?

From guillaume.smet at gmail.com  Wed Jun  6 06:37:59 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 6 Jun 2018 12:37:59 +0200
Subject: [hibernate-dev] Changes to the JIRA "Pull request sent" status
Message-ID: <CALt0+o8A1Uv9=cu_oWkZUUWGO1ebhX=oQFU36+GbYkk0Kx3iMQ@mail.gmail.com>

Hi,

A few months back, when an issue was in the "Pull request sent" status, it
was considered "In progress" and appeared here:
https://hibernate.atlassian.net/projects/HV/versions/30000/tab/release-report-in-progress
.

This apparently got broken at some point (or someone changed it without
asking).

My personal preference is to consider the issues with pull requests as In
progress instead of To do and it seems more logical as, as soon as you have
a PR, the issue is definitely in progress.

I applied this change as it's a simple one (it's not a workflow change,
it's just marking "Pull request sent" as a "In progress" status) and IMHO
it was a regression.

If someone is against it and it was an intentional change, please speak up.

-- 
Guillaume

From yoann at hibernate.org  Wed Jun  6 06:47:40 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Wed, 6 Jun 2018 12:47:40 +0200
Subject: [hibernate-dev] Changes to the JIRA "Pull request sent" status
In-Reply-To: <CALt0+o8A1Uv9=cu_oWkZUUWGO1ebhX=oQFU36+GbYkk0Kx3iMQ@mail.gmail.com>
References: <CALt0+o8A1Uv9=cu_oWkZUUWGO1ebhX=oQFU36+GbYkk0Kx3iMQ@mail.gmail.com>
Message-ID: <CAEqagpr=dZ=Rt1F9RJpbTLRpBR2LTdnW_aeyea7dBGEWExwbag@mail.gmail.com>

Nice! I had noticed that, but didn't think further, assuming it would not
be configurable anyway.
Thanks for fixing it.

On Wed, 6 Jun 2018 at 12:44 Guillaume Smet <guillaume.smet at gmail.com> wrote:

> Hi,
>
> A few months back, when an issue was in the "Pull request sent" status, it
> was considered "In progress" and appeared here:
>
> https://hibernate.atlassian.net/projects/HV/versions/30000/tab/release-report-in-progress
> .
>
> This apparently got broken at some point (or someone changed it without
> asking).
>
> My personal preference is to consider the issues with pull requests as In
> progress instead of To do and it seems more logical as, as soon as you have
> a PR, the issue is definitely in progress.
>
> I applied this change as it's a simple one (it's not a workflow change,
> it's just marking "Pull request sent" as a "In progress" status) and IMHO
> it was a regression.
>
> If someone is against it and it was an intentional change, please speak up.
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From sanne at hibernate.org  Wed Jun  6 06:57:21 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 6 Jun 2018 11:57:21 +0100
Subject: [hibernate-dev] Changes to the JIRA "Pull request sent" status
In-Reply-To: <CALt0+o8A1Uv9=cu_oWkZUUWGO1ebhX=oQFU36+GbYkk0Kx3iMQ@mail.gmail.com>
References: <CALt0+o8A1Uv9=cu_oWkZUUWGO1ebhX=oQFU36+GbYkk0Kx3iMQ@mail.gmail.com>
Message-ID: <CAFm4XO0JP3_y=h09_7Y9zZmKzEgBpr-icVQ4jFrWLSgNY0471w@mail.gmail.com>

Just curious, did that really work consistently?

As far as I know, the JIRA integration was never really able to match
GitHub PR changes to JIRA issues reliably.

On 6 June 2018 at 11:37, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi,
>
> A few months back, when an issue was in the "Pull request sent" status, it
> was considered "In progress" and appeared here:
> https://hibernate.atlassian.net/projects/HV/versions/30000/tab/release-report-in-progress
> .
>
> This apparently got broken at some point (or someone changed it without
> asking).
>
> My personal preference is to consider the issues with pull requests as In
> progress instead of To do and it seems more logical as, as soon as you have
> a PR, the issue is definitely in progress.
>
> I applied this change as it's a simple one (it's not a workflow change,
> it's just marking "Pull request sent" as a "In progress" status) and IMHO
> it was a regression.
>
> If someone is against it and it was an intentional change, please speak up.
>
> --
> 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  Wed Jun  6 07:04:43 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 6 Jun 2018 13:04:43 +0200
Subject: [hibernate-dev] Changes to the JIRA "Pull request sent" status
In-Reply-To: <CAFm4XO0JP3_y=h09_7Y9zZmKzEgBpr-icVQ4jFrWLSgNY0471w@mail.gmail.com>
References: <CALt0+o8A1Uv9=cu_oWkZUUWGO1ebhX=oQFU36+GbYkk0Kx3iMQ@mail.gmail.com>
	<CAFm4XO0JP3_y=h09_7Y9zZmKzEgBpr-icVQ4jFrWLSgNY0471w@mail.gmail.com>
Message-ID: <CALt0+o-++98w2snFEjmGxMaiMb=dfhREu3ww=FCd+pKRF3sWeQ@mail.gmail.com>

On Wed, Jun 6, 2018 at 12:57 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Just curious, did that really work consistently?
>

Well, it works consistently as in if your issue is in the "Pull request
sent" status, the issue is considered "In progress".

This status is associated with the explicit action "Link to pull request"
we have in the NoORM workflow so it's not about automatic detection.

-- 
Guillaume

From sanne at hibernate.org  Wed Jun  6 07:29:07 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 6 Jun 2018 12:29:07 +0100
Subject: [hibernate-dev] Changes to the JIRA "Pull request sent" status
In-Reply-To: <CALt0+o-++98w2snFEjmGxMaiMb=dfhREu3ww=FCd+pKRF3sWeQ@mail.gmail.com>
References: <CALt0+o8A1Uv9=cu_oWkZUUWGO1ebhX=oQFU36+GbYkk0Kx3iMQ@mail.gmail.com>
	<CAFm4XO0JP3_y=h09_7Y9zZmKzEgBpr-icVQ4jFrWLSgNY0471w@mail.gmail.com>
	<CALt0+o-++98w2snFEjmGxMaiMb=dfhREu3ww=FCd+pKRF3sWeQ@mail.gmail.com>
Message-ID: <CAFm4XO0LUgYxW3JadM+v_8zoa4t3N76+Od9GTgUpx72q5v4WuA@mail.gmail.com>

On 6 June 2018 at 12:04, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> On Wed, Jun 6, 2018 at 12:57 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Just curious, did that really work consistently?
>
>
> Well, it works consistently as in if your issue is in the "Pull request
> sent" status, the issue is considered "In progress".
>
> This status is associated with the explicit action "Link to pull request" we
> have in the NoORM workflow so it's not about automatic detection.

Thanks. This used to not work well at all, it was probably improved.

I don't know about others but I didn't make changes on JIRA in a long
time - or I'd normally share actions here.

>
> --
> Guillaume

From guillaume.smet at gmail.com  Wed Jun  6 07:33:16 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 6 Jun 2018 13:33:16 +0200
Subject: [hibernate-dev] Changes to the JIRA "Pull request sent" status
In-Reply-To: <CAFm4XO0LUgYxW3JadM+v_8zoa4t3N76+Od9GTgUpx72q5v4WuA@mail.gmail.com>
References: <CALt0+o8A1Uv9=cu_oWkZUUWGO1ebhX=oQFU36+GbYkk0Kx3iMQ@mail.gmail.com>
	<CAFm4XO0JP3_y=h09_7Y9zZmKzEgBpr-icVQ4jFrWLSgNY0471w@mail.gmail.com>
	<CALt0+o-++98w2snFEjmGxMaiMb=dfhREu3ww=FCd+pKRF3sWeQ@mail.gmail.com>
	<CAFm4XO0LUgYxW3JadM+v_8zoa4t3N76+Od9GTgUpx72q5v4WuA@mail.gmail.com>
Message-ID: <CALt0+o9FNKJtSF=PtkMjEquN1Bc13h0GsKuusOphZkjb2zahaQ@mail.gmail.com>

On Wed, Jun 6, 2018 at 1:29 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> I don't know about others but I didn't make changes on JIRA in a long
> time - or I'd normally share actions here.
>

It might also be due to a JIRA upgrade as they did quite a lot of changes.

Anyway, we are back on track now.

-- 
Guillaume

From guillaume.smet at gmail.com  Wed Jun  6 08:26:32 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 6 Jun 2018 14:26:32 +0200
Subject: [hibernate-dev] Hibernate ORM 5.2.18 to be the last in 5.2
	series?
In-Reply-To: <CAFDzhiQMG0MO1fr42jr=aqmm=dxQEaR+khfUcsDsK8G62PwpbA@mail.gmail.com>
References: <CAFDzhiQMG0MO1fr42jr=aqmm=dxQEaR+khfUcsDsK8G62PwpbA@mail.gmail.com>
Message-ID: <CALt0+o99rw=_TWEEAWnAX1oTZB=dziuR+KnHfhxhcdEKivatiQ@mail.gmail.com>

On Tue, Jun 5, 2018 at 10:33 PM Gail Badner <gbadner at redhat.com> wrote:

> Chris mentioned that he is planning to release 5.2.18 on Thursday.
>

It would be nice if we could get
https://hibernate.atlassian.net/browse/HHH-12645 fixed before releasing
5.2.18, considering it's a regression introduced after 5.2.13. If we didn't
expect 5.2.18 to be the last 5.2, I wouldn't ask.

I don't know if Christian has some bandwidth to take a look as it seems
related to his prior work.

-- 
Guillaume

From steve at hibernate.org  Wed Jun  6 08:45:33 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 6 Jun 2018 07:45:33 -0500
Subject: [hibernate-dev] Hibernate ORM 5.2.18 to be the last in 5.2
	series?
In-Reply-To: <CALt0+o99rw=_TWEEAWnAX1oTZB=dziuR+KnHfhxhcdEKivatiQ@mail.gmail.com>
References: <CAFDzhiQMG0MO1fr42jr=aqmm=dxQEaR+khfUcsDsK8G62PwpbA@mail.gmail.com>
	<CALt0+o99rw=_TWEEAWnAX1oTZB=dziuR+KnHfhxhcdEKivatiQ@mail.gmail.com>
Message-ID: <CAFdSV9tTCWj2D7dsznKZ+Wqu1vz+aiV=V_+psJ_7ZiMCXwmhiQ@mail.gmail.com>

+1 to stopping 5.2 releases.

On Wed, Jun 6, 2018 at 7:40 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> On Tue, Jun 5, 2018 at 10:33 PM Gail Badner <gbadner at redhat.com> wrote:
>
> > Chris mentioned that he is planning to release 5.2.18 on Thursday.
> >
>
> It would be nice if we could get
> https://hibernate.atlassian.net/browse/HHH-12645 fixed before releasing
> 5.2.18, considering it's a regression introduced after 5.2.13. If we didn't
> expect 5.2.18 to be the last 5.2, I wouldn't ask.
>
> I don't know if Christian has some bandwidth to take a look as it seems
> related to his prior work.
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From crancran at gmail.com  Wed Jun  6 10:01:39 2018
From: crancran at gmail.com (Chris Cranford)
Date: Wed, 6 Jun 2018 10:01:39 -0400
Subject: [hibernate-dev] Hibernate ORM 5.2.18 to be the last in 5.2
 series?
In-Reply-To: <CALt0+o99rw=_TWEEAWnAX1oTZB=dziuR+KnHfhxhcdEKivatiQ@mail.gmail.com>
References: <CAFDzhiQMG0MO1fr42jr=aqmm=dxQEaR+khfUcsDsK8G62PwpbA@mail.gmail.com>
	<CALt0+o99rw=_TWEEAWnAX1oTZB=dziuR+KnHfhxhcdEKivatiQ@mail.gmail.com>
Message-ID: <eb5eb978-48bf-05bf-896e-f9d1df12516c@gmail.com>

I'm fine postponing the release for another week or 2 if that helps,
Christian.?

On 06/06/2018 08:26 AM, Guillaume Smet wrote:
> On Tue, Jun 5, 2018 at 10:33 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> Chris mentioned that he is planning to release 5.2.18 on Thursday.
>>
> It would be nice if we could get
> https://hibernate.atlassian.net/browse/HHH-12645 fixed before releasing
> 5.2.18, considering it's a regression introduced after 5.2.13. If we didn't
> expect 5.2.18 to be the last 5.2, I wouldn't ask.
>
> I don't know if Christian has some bandwidth to take a look as it seems
> related to his prior work.
>


From mihalcea.vlad at gmail.com  Wed Jun  6 11:09:18 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 6 Jun 2018 18:09:18 +0300
Subject: [hibernate-dev] Hibernate ORM 5.2.18 to be the last in 5.2
	series?
In-Reply-To: <CAFdSV9tTCWj2D7dsznKZ+Wqu1vz+aiV=V_+psJ_7ZiMCXwmhiQ@mail.gmail.com>
References: <CAFDzhiQMG0MO1fr42jr=aqmm=dxQEaR+khfUcsDsK8G62PwpbA@mail.gmail.com>
	<CALt0+o99rw=_TWEEAWnAX1oTZB=dziuR+KnHfhxhcdEKivatiQ@mail.gmail.com>
	<CAFdSV9tTCWj2D7dsznKZ+Wqu1vz+aiV=V_+psJ_7ZiMCXwmhiQ@mail.gmail.com>
Message-ID: <CA+gWKMBZT_NtQdzNYZOLUXQGegRCJSBe6hLrd+ci+48gJ56iBA@mail.gmail.com>

+1.

Unless there will be some serious issues that call for a 5.2.19 release, we
should focus on 5.3.

Vlad

On Wed, Jun 6, 2018 at 3:45 PM, Steve Ebersole <steve at hibernate.org> wrote:

> +1 to stopping 5.2 releases.
>
> On Wed, Jun 6, 2018 at 7:40 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
> > On Tue, Jun 5, 2018 at 10:33 PM Gail Badner <gbadner at redhat.com> wrote:
> >
> > > Chris mentioned that he is planning to release 5.2.18 on Thursday.
> > >
> >
> > It would be nice if we could get
> > https://hibernate.atlassian.net/browse/HHH-12645 fixed before releasing
> > 5.2.18, considering it's a regression introduced after 5.2.13. If we
> didn't
> > expect 5.2.18 to be the last 5.2, I wouldn't ask.
> >
> > I don't know if Christian has some bandwidth to take a look as it seems
> > related to his prior work.
> >
> > --
> > Guillaume
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Wed Jun  6 12:59:11 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 6 Jun 2018 12:59:11 -0400
Subject: [hibernate-dev] What should be the contract for
 PersistenceUnitInfo#addTransformer with regard to multiple persistence
 units mapping the same entity class?
In-Reply-To: <63776239-7767-f67b-cf61-54eef51664f7@redhat.com>
References: <CAJtdNN4KbmjrwjG3rhBhBfPFUZ2D8hAjKORyCHtx3WesF-0pGg@mail.gmail.com>
	<4fb5f7b4-b854-6221-1221-49433278e282@redhat.com>
	<CAJtdNN6o1OXwE3rNCZjqh8kX-Ptj-hBocfEhx+ubDaimkp6x+w@mail.gmail.com>
	<63776239-7767-f67b-cf61-54eef51664f7@redhat.com>
Message-ID: <CAJtdNN7sqTMm6w2phDsrHUx8r8NYS8hag3JS=GqzAMM3he9p=g@mail.gmail.com>

On Tue, Jun 5, 2018 at 3:38 PM, Luis Barreiro <lbarreiro at redhat.com> wrote:

> My reading on that javadoc is that you only get the transformation once
> (the first time that a class is loaded) and after that, if it's used by
> other PUs, it may not get the transformations those PUs specify.
>

We added TRACE logging for WildFly 14 that shows when the transformation
occurs.  https://paste.fedoraproject.org/paste/gna7ww8aM59sXjnAUIsEJw shows
server output for ORM 5.1.14 + 5.3.1.  I also locally added a call to
Thread.printStack()
if org.hibernate.jpa.internal.enhance.EnhancingClassTransformerImpl returns
a non-null result (which means that the passed entity class was enhanced).

The server output, shows the persistence.xml for an invalid application, so
we can see what happens if the same entity class is mapped to two
persistence units, that both enable entity enhancing.

If there is interest in discussion this, we can meet up on hipchat or irc
(or discussing here is also fine).

It looks like EnhancingClassTransformerImpl doesn't return the correct
result, if no transformation is made.  Not a serious bug but I think
we EnhancingClassTransformerImpl
should return null if the class is already transformed.

Scott

> I would like to add that the enhancer is synchronous (it only enhance one
> class at a time), hence my question about synchronization, but you were
> obviously looking at a different level.
>
> Regards,
>
> Luis Barreiro
>
> Middleware Performance Team
> <https://red.ht/sig>
> On 06/05/2018 07:08 PM, Scott Marlow wrote:
>
> Thanks, I think they probably intended that the persistence provider would
> use a marker interface like org.hibernate.engine.spi.Managed to ensure
> that the enhancement is only done once.  Responses to your questions are
> inline below.
>
> On Tue, Jun 5, 2018 at 12:19 PM, Luis Barreiro <lbarreiro at redhat.com>
> wrote:
>
>> Hi Scott,
>>
>> In the particular case of the hibernate bytecode enhancer, it adds the
>> org.hibernate.engine.spi.Managed marker interface to the entity so that
>> it only performs the enhancement once. (that implies that you can't have
>> the same entity enhanced for different features in the same class loader)
>>
>> Also, in theory, you could have multiple transformations applied to the
>> same entity / PU. So what is it you really want to check ?!
>>
> Mostly, I'm trying to understand why the [1] javadoc requires that classes
> are only transformed only once, as I would expect that some persistence
> providers could want to register multiple transformers.
>
>> I don't get you last paragraph ... why ORM will be only capable of
>> registering one transformer,
>>
> If we update the WildFly JPA container  JPADelegatingClassFileTransformer
> [2] to only allow the application entity class to be enhanced at most once
> (at runtime), ORM would be able to register multiple transformers but the
> first ORM transformer that actually enhances the entity class (e.g.
> transformer returns non-null return value), would need to terminate the
> "for each transformer" loop in [2].
>
> Since, as you said, ORM is already using a marker interface to know when a
> class is already enhanced, it sounds like WildFly doesn't really need to
> enforce the [1] contract (with regard to only transforming the entity class
> once).
>
>
>> and why will you need synchronization ?!
>>
> If WildFly JPADelegatingClassFileTransformer [2] where modified to
> prevent more than one transformation of an entity class, that would include
> checking across (parallel) persistence unit deployment threads, which could
> be done with a Java synchronization lock.
>
> Scott
>
> [1] https://docs.oracle.com/javaee/7/api/javax/persistence/spi/
> PersistenceUnitInfo.html#addTransformer-javax.persistence.spi.
> ClassTransformer-
>
> [2] https://github.com/wildfly/wildfly/blob/master/
> jpa/subsystem/src/main/java/org/jboss/as/jpa/classloader/
> JPADelegatingClassFileTransformer.java#L44
>
>
>
>

From sanne at hibernate.org  Thu Jun  7 09:20:07 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 7 Jun 2018 14:20:07 +0100
Subject: [hibernate-dev] JDK 11 Early Access build 15 is available for
	download.
In-Reply-To: <3e82e0df-8b36-89f5-7ec5-9c9faa72ca1d@oracle.com>
References: <d901e688-14cd-483c-a2cf-6ea6810e9f25@oracle.com>
	<CAFm4XO1yUn==8UoCqSUDRzWt082F5iLLWz08n=yAExH1gk9ZHw@mail.gmail.com>
	<bf944b3d-df79-ef01-90b9-b6eea0aa8cc2@oracle.com>
	<3e82e0df-8b36-89f5-7ec5-9c9faa72ca1d@oracle.com>
Message-ID: <CAFm4XO0rPs_jze5gi7udPTPkUDt3OZO5_5LiMK9v5Q7bUxtOAg@mail.gmail.com>

Thanks, Rory!

making some progress with b16.

Regards,
Sanne


On 5 June 2018 at 09:36, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
> Hi Sanne,
>
> b15 has been superseded by b16, looks like downloads are working. Thanks for
> reporting the issue.
>
> Rgds,Rory
>
> On 31/05/2018 16:00, Rory O'Donnell wrote:
>>
>> Thanks Sanne, we are looking into it.
>>
>> Rgds,Rory
>>
>>
>> On 31/05/2018 15:59, Sanne Grinovero wrote:
>>>
>>> Hi Rory,
>>>
>>> I was trying to download the OpenJDK / Linux distribution from
>>> http://jdk.java.net/11/, but it seems to link to [1] which returns a
>>> 404 error page.
>>>
>>> I'll use the Oracle / Linux build in the meantime.
>>>
>>> Thanks,
>>> Sanne
>>>
>>> 1 -
>>> https://download.java.net/java/early_access/jdk11/15/GPL/openjdk-11-ea+15_linux-x64_bin.tar.gz
>>>
>>>
>>> On 29 May 2018 at 10:51, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
>>>>
>>>> Hi Sanne,
>>>>
>>>> **JDK 11 EA build 15 , *****under both the GPL and Oracle EA licenses,
>>>> is now available at **http://jdk.java.net/11**. **
>>>> *
>>>>
>>>>    * Newly approved Schedule, status & features
>>>>        o http://openjdk.java.net/projects/jdk/11/
>>>>    * Release Notes:
>>>>        o http://jdk.java.net/11/release-notes
>>>>    * Summary of changes
>>>>        o http://jdk.java.net/11/changes
>>>>
>>>> *Notable changes in JDK 11 EA builds since last email:*
>>>>
>>>>    * b15 - JDK-8201627 <http://bugs.openjdk.java.net/browse/JDK-8201627>
>>>>      - Kerberos sequence number issues
>>>>    * b13 - JDK-8200146 <http://bugs.openjdk.java.net/browse/JDK-8200146>
>>>>      - Removal of appletviewer launcher
>>>>        o deprecated in JDK 9 and has been removed in this release
>>>>    * b13 - JDK-8201793 <http://bugs.openjdk.java.net/browse/JDK-8201793>
>>>>      - java.lang.ref.Reference does not support cloning
>>>>
>>>> **
>>>>
>>>> **
>>>>
>>>> JEPs proposed to target JDK 11 (review ends 2018/05/31 23:00 UTC)
>>>>
>>>>      330: Launch Single-File Source-Code Programs
>>>>      <http://openjdk.java.net/jeps/330>
>>>>
>>>>      JEPs targeted to JDK 11, so far
>>>>
>>>>      309: Dynamic Class-File Constants
>>>> <http://openjdk.java.net/jeps/309>
>>>>      318: Epsilon: A No-Op Garbage Collector
>>>>      <http://openjdk.java.net/jeps/318>
>>>>      320: Remove the Java EE and CORBA Modules
>>>>      <http://openjdk.java.net/jeps/320>
>>>>      321: HTTP Client (Standard) <http://openjdk.java.net/jeps/321>
>>>>      323: Local-Variable Syntax for Lambda Parameters
>>>>      <http://openjdk.java.net/jeps/323>
>>>>      324: Key Agreement with Curve25519 and Curve448
>>>>      <http://openjdk.java.net/jeps/324>
>>>>      327: Unicode 10 <http://openjdk.java.net/jeps/327>
>>>>      328: Flight Recorder <http://openjdk.java.net/jeps/328>
>>>>      329: ChaCha20 and Poly1305 Cryptographic Algorithms
>>>>      <http://openjdk.java.net/jeps/329>
>>>>
>>>> Finally, Initial TLSv1.3 implementation Released to the Open Sandbox.
>>>> Please note well: this branch is under
>>>> very active development and is not final by any means. Also note: by
>>>> releasing this code, we are not committing
>>>> a specific release or timeframe. We will continue development and fixing
>>>> bugs until the code is ready for inclusion
>>>> in the JDK. We welcome your feedback, more info [1]
>>>>
>>>>
>>>> Regards,
>>>> Rory
>>>>
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html
>>>>
>>>> --
>>>> 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 sanne at hibernate.org  Fri Jun  8 05:12:42 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 8 Jun 2018 10:12:42 +0100
Subject: [hibernate-dev] Help please: HHH-12674 Upgrade to Gradle 4.8
Message-ID: <CAFm4XO1CpDtd8ThRCWsDgYJBnNj7pY1nao5ZEVSu2BZ5waJatA@mail.gmail.com>

I previously upgraded Hibernate ORM to Gradle 4.7, that was trivial.

I'd like us to upgrade to 4.8 (now also released) so to keep going
testing with JDK11 - but I got some puzzling errors with the Gradle
build to remind me that this is still beyond my Gradle-fu :)

If someone else could take [1] that would be very nice... thanks!

Sanne

 1 - https://hibernate.atlassian.net/browse/HHH-12674

From gbadner at redhat.com  Fri Jun  8 15:53:45 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 8 Jun 2018 12:53:45 -0700
Subject: [hibernate-dev] Hibernate ORM Binary Compatibility between 5.1 and
	5.3 (June 6, 2018)
Message-ID: <CAFDzhiSgq9n+anJpJos6jCGZWk6kj5yA1WzKw0jf4D2Z4Gkt-A@mail.gmail.com>

I re-ran japi-compliance-checker on Wednesday (6/6/18) comparing binary
compatibility of 5.1.15-SNAPSHOT vs 5.2.3-SNAPSHOT.

I've summarized the results at [1]. I have shared this document to everyone
who requested access to the older reports. Please request access if you're
interested in seeing it.

AFAICT, everything identified as an issue in my previous report from 4/2/18
[2] has been resolved, except for those described in
https://hibernate.atlassian.net/browse/HHH-12651 that were not found by
japi-compliance-checker.

Does anyone have a recommendation of a different tool that can check API
binary compatibility between 2 Java project versions that doesn't suffer
from the false positives and oversights we ran into with
japi-compliance-checker?

Regards,
Gail

[1]
https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-wxoMglU/edit?usp=sharing
[2]
https://docs.google.com/document/d/1ZjdVuNzYPjjmvVd7mDLw9zwy9c0By_FP0oj8DkHgiBE/edit?usp=sharing

From steve at hibernate.org  Fri Jun  8 16:42:30 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 8 Jun 2018 15:42:30 -0500
Subject: [hibernate-dev] Hibernate ORM Binary Compatibility between 5.1
 and 5.3 (June 6, 2018)
In-Reply-To: <CAFDzhiSgq9n+anJpJos6jCGZWk6kj5yA1WzKw0jf4D2Z4Gkt-A@mail.gmail.com>
References: <CAFDzhiSgq9n+anJpJos6jCGZWk6kj5yA1WzKw0jf4D2Z4Gkt-A@mail.gmail.com>
Message-ID: <CAFdSV9vA=m274Q5toX44Wuc_wYRpTDHDo-r+oAeNXaWjFDHtAA@mail.gmail.com>

Have you tried https://plugins.gradle.org/plugin/me.champeau.gradle.japicmp
 ?

On Fri, Jun 8, 2018 at 3:29 PM Gail Badner <gbadner at redhat.com> wrote:

> I re-ran japi-compliance-checker on Wednesday (6/6/18) comparing binary
> compatibility of 5.1.15-SNAPSHOT vs 5.2.3-SNAPSHOT.
>
> I've summarized the results at [1]. I have shared this document to everyone
> who requested access to the older reports. Please request access if you're
> interested in seeing it.
>
> AFAICT, everything identified as an issue in my previous report from 4/2/18
> [2] has been resolved, except for those described in
> https://hibernate.atlassian.net/browse/HHH-12651 that were not found by
> japi-compliance-checker.
>
> Does anyone have a recommendation of a different tool that can check API
> binary compatibility between 2 Java project versions that doesn't suffer
> from the false positives and oversights we ran into with
> japi-compliance-checker?
>
> Regards,
> Gail
>
> [1]
>
> https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-wxoMglU/edit?usp=sharing
> [2]
>
> https://docs.google.com/document/d/1ZjdVuNzYPjjmvVd7mDLw9zwy9c0By_FP0oj8DkHgiBE/edit?usp=sharing
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Fri Jun  8 17:39:37 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 8 Jun 2018 14:39:37 -0700
Subject: [hibernate-dev] Hibernate ORM Binary Compatibility between 5.1
 and 5.3 (June 6, 2018)
In-Reply-To: <CAFdSV9vA=m274Q5toX44Wuc_wYRpTDHDo-r+oAeNXaWjFDHtAA@mail.gmail.com>
References: <CAFDzhiSgq9n+anJpJos6jCGZWk6kj5yA1WzKw0jf4D2Z4Gkt-A@mail.gmail.com>
	<CAFdSV9vA=m274Q5toX44Wuc_wYRpTDHDo-r+oAeNXaWjFDHtAA@mail.gmail.com>
Message-ID: <CAFDzhiTs6MuekT63a9xP7mBha36-D2ZsX=daRFETR4e+E07YmQ@mail.gmail.com>

I'll give it a try.

Thanks!

On Fri, Jun 8, 2018 at 1:42 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Have you tried https://plugins.gradle.org/plugin/me.champeau.gradle.
> japicmp ?
>
> On Fri, Jun 8, 2018 at 3:29 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> I re-ran japi-compliance-checker on Wednesday (6/6/18) comparing binary
>> compatibility of 5.1.15-SNAPSHOT vs 5.2.3-SNAPSHOT.
>>
>> I've summarized the results at [1]. I have shared this document to
>> everyone
>> who requested access to the older reports. Please request access if you're
>> interested in seeing it.
>>
>> AFAICT, everything identified as an issue in my previous report from
>> 4/2/18
>> [2] has been resolved, except for those described in
>> https://hibernate.atlassian.net/browse/HHH-12651 that were not found by
>> japi-compliance-checker.
>>
>> Does anyone have a recommendation of a different tool that can check API
>> binary compatibility between 2 Java project versions that doesn't suffer
>> from the false positives and oversights we ran into with
>> japi-compliance-checker?
>>
>> Regards,
>> Gail
>>
>> [1]
>> https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_
>> GKSahh_gRd7bKI6kII-wxoMglU/edit?usp=sharing
>> [2]
>> https://docs.google.com/document/d/1ZjdVuNzYPjjmvVd7mDLw9zwy9c0By
>> _FP0oj8DkHgiBE/edit?usp=sharing
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From christian.beikov at gmail.com  Mon Jun 11 01:37:20 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 11 Jun 2018 07:37:20 +0200
Subject: [hibernate-dev] Multiple ResultSets from JDBC execution
In-Reply-To: <CAJtdNN4oxE3kxjB4GD1RX_0q4=1Gk_qB5C38xCzTL6HrAwfgLA@mail.gmail.com>
References: <CAFdSV9tfJFc6abR63f8QfjBScLgaLfTbZVRcx7rx_EEU_gFNkQ@mail.gmail.com>
	<CA+gWKMA7Y117YnR62P42Obw4vfF2uGJWWAb33MXJpjAmGJ8bMg@mail.gmail.com>
	<CAFdSV9uAFgn=owV=F44sdoCSVpLUvvrh_jfjEjOrSZN9xvJsYg@mail.gmail.com>
	<CA+gWKMD-jQxGrKrCYAXxvVUS-P=yohtSKrNk1bU5cxyMrqc95Q@mail.gmail.com>
	<CAFdSV9tvoWoM1nwSqzrvFVu=QM3eQD7qmx_U2p7jwBB44iX9vQ@mail.gmail.com>
	<CAJtdNN4oxE3kxjB4GD1RX_0q4=1Gk_qB5C38xCzTL6HrAwfgLA@mail.gmail.com>
Message-ID: <dad8e945-9537-ff66-490e-f5e0108697f6@gmail.com>

+1 from me as well on that.


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 25.05.2018 um 17:24 schrieb Scott Marlow:
> On Fri, May 25, 2018 at 8:59 AM, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Great that was actually my thought as well.
>>
>> Anyone else?
>>
> +1 for being able to treat the result sets as not the same.
>
> Scott
> _______________________________________________
> 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 Jun 11 13:34:31 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 11 Jun 2018 19:34:31 +0200
Subject: [hibernate-dev] Bytecode enhancement and inheritance
Message-ID: <CALt0+o9P3U0+_SYnhCN5=rtq-T98e1MZDiGG-UMpmBoMuUoOHg@mail.gmail.com>

Hi Luis,

This question is related to https://hibernate.atlassian.net/browse/HHH-12601
.

AFAICS, the following case (e.g. having the fields defined in the parent
class and the laziness defined in the child class) is not working very well
with bytecode enhancement:
====
@Entity
public class RequestWithLazyEvents extends RelatedToEvents {

    @ManyToMany(fetch = FetchType.LAZY)
    @Fetch(FetchMode.SELECT)
    public Set<Event> getEvents() {
        return events;
    }
}

@MappedSuperclass
public abstract class RelatedToEvents extends Base {
    protected Set<Event> events = new LinkedHashSet<>();

    public void setEvents(Set<Event> events) {
        this.events = events;
    }
}
====

By not working very well, I mean that the interceptor read/write methods
are defined in the child class but the getters and setters are not
intercepted because we only intercept the getters/setters if the fields are
defined in the current class:

See this method in PersistentAttributeTransformer and especially the last
test:
====
    private boolean isEnhanced(String owner, String name, String desc) {
        for ( FieldDescription enhancedField : enhancedFields ) {
            if ( enhancedField.getName().equals( name )
                    && enhancedField.getDescriptor().equals( desc )
                    &&
enhancedField.getDeclaringType().asErasure().getInternalName().equals(
owner ) ) {
                return true;
            }
        }
        return false;
    }
====

(Note that supporting this case is not only a matter of removing the test)

I don't know if it's a case we want to support or not but I'm a bit worried
that we don't throw any error and the collection is not loaded at all (as
the rest of ORM supposes the enhancer will do the work).

You end up saving the collection in the database and when you get it back
the collection is always empty.

It can lead to serious data loss if you save the entity back to the
database thus I think it's somewhat critical to fix it.

WDYT?

-- 
Guillaume

From lbarreiro at redhat.com  Mon Jun 11 15:39:23 2018
From: lbarreiro at redhat.com (Luis Barreiro)
Date: Mon, 11 Jun 2018 20:39:23 +0100
Subject: [hibernate-dev] Bytecode enhancement and inheritance
In-Reply-To: <CALt0+o9P3U0+_SYnhCN5=rtq-T98e1MZDiGG-UMpmBoMuUoOHg@mail.gmail.com>
References: <CALt0+o9P3U0+_SYnhCN5=rtq-T98e1MZDiGG-UMpmBoMuUoOHg@mail.gmail.com>
Message-ID: <93b45db4-1e97-b57a-6812-0808e6a7ddb8@redhat.com>

Hi Guillaume,

Can you please check the behavior of with the Javassist enhancer in this 
particular case? I believe it's the correct one, but one has to double 
check.

Also, on a related issue, please check the comments I made on 
https://hibernate.atlassian.net/browse/HHH-12593 about property access.

I think we need to sort out both aspects, the interception and enhancing 
as mapped collection, in order to support this case properly. The former 
is a bug but for the latter I don't see a good enough solution.

Let me know what you find so we can proceed on solving this out.

Regards,

Luis Barreiro

Middleware Performance Team

<https://red.ht/sig>

On 06/11/2018 06:34 PM, Guillaume Smet wrote:
> Hi Luis,
>
> This question is related to 
> https://hibernate.atlassian.net/browse/HHH-12601 .
>
> AFAICS, the following case (e.g. having the fields defined in the 
> parent class and the laziness defined in the child class) is not 
> working very well with bytecode enhancement:
> ====
> @Entity
> public class RequestWithLazyEvents extends RelatedToEvents {
>
> ??? @ManyToMany(fetch = FetchType.LAZY)
> ??? @Fetch(FetchMode.SELECT)
> ??? public Set<Event> getEvents() {
> ??? ??? return events;
> ??? }
> }
>
> @MappedSuperclass
> public abstract class RelatedToEvents extends Base {
> ??? protected Set<Event> events = new LinkedHashSet<>();
>
> ??? public void setEvents(Set<Event> events) {
> ??? ??? this.events = events;
> ??? }
> }
> ====
>
> By not working very well, I mean that the interceptor read/write 
> methods are defined in the child class but the getters and setters are 
> not intercepted because we only intercept the getters/setters if the 
> fields are defined in the current class:
>
> See this method in PersistentAttributeTransformer and especially the 
> last test:
> ====
> ??? private boolean isEnhanced(String owner, String name, String desc) {
> ??? ??? for ( FieldDescription enhancedField : enhancedFields ) {
> ??? ??? ??? if ( enhancedField.getName().equals( name )
> ??? ??? ??? ??? ??? && enhancedField.getDescriptor().equals( desc )
> ??? ??? ??? ??? ??? && 
> enhancedField.getDeclaringType().asErasure().getInternalName().equals( 
> owner ) ) {
> ??? ??? ??? ??? return true;
> ??? ??? ??? }
> ??? ??? }
> ??? ??? return false;
> ??? }
> ====
>
> (Note that supporting this case is not only a matter of removing the test)
>
> I don't know if it's a case we want to support or not but I'm a bit 
> worried that we don't throw any error and the collection is not loaded 
> at all (as the rest of ORM supposes the enhancer will do the work).
>
> You end up saving the collection in the database and when you get it 
> back the collection is always empty.
>
> It can lead to serious data loss if you save the entity back to the 
> database thus I think it's somewhat critical to fix it.
>
> WDYT?
>
> -- 
> Guillaume


From guillaume.smet at gmail.com  Tue Jun 12 05:59:58 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 12 Jun 2018 11:59:58 +0200
Subject: [hibernate-dev] Bytecode enhancement and inheritance
In-Reply-To: <93b45db4-1e97-b57a-6812-0808e6a7ddb8@redhat.com>
References: <CALt0+o9P3U0+_SYnhCN5=rtq-T98e1MZDiGG-UMpmBoMuUoOHg@mail.gmail.com>
	<93b45db4-1e97-b57a-6812-0808e6a7ddb8@redhat.com>
Message-ID: <CALt0+o-uaARaBx-oiGMAmZ6SXZJqbmXDYDuJfUO8gCytcj=Khw@mail.gmail.com>

Hi Luis,

On Mon, Jun 11, 2018 at 9:39 PM Luis Barreiro <lbarreiro at redhat.com> wrote:

> Can you please check the behavior of with the Javassist enhancer in this
> particular case? I believe it's the correct one, but one has to double
> check.
>

>From my tests, the behavior is exactly the same with Javassist.

-- 
Guillaume

From sanne at hibernate.org  Wed Jun 13 12:44:46 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 13 Jun 2018 17:44:46 +0100
Subject: [hibernate-dev] Help please: HHH-12674 Upgrade to Gradle 4.8
In-Reply-To: <CAFm4XO1CpDtd8ThRCWsDgYJBnNj7pY1nao5ZEVSu2BZ5waJatA@mail.gmail.com>
References: <CAFm4XO1CpDtd8ThRCWsDgYJBnNj7pY1nao5ZEVSu2BZ5waJatA@mail.gmail.com>
Message-ID: <CAFm4XO1YEPKv7L4SepWq0t7pHgR-XsmyR821q0R-HqaqSkq9SQ@mail.gmail.com>

Just an update: Steve and Andrea helped me and we got it done.

We can finally run the full build on JDK10; for JDK11 we still need to
sort out some details, e.g. yet another Gradle update.
On Fri, 8 Jun 2018 at 10:12, Sanne Grinovero <sanne at hibernate.org> wrote:
>
> I previously upgraded Hibernate ORM to Gradle 4.7, that was trivial.
>
> I'd like us to upgrade to 4.8 (now also released) so to keep going
> testing with JDK11 - but I got some puzzling errors with the Gradle
> build to remind me that this is still beyond my Gradle-fu :)
>
> If someone else could take [1] that would be very nice... thanks!
>
> Sanne
>
>  1 - https://hibernate.atlassian.net/browse/HHH-12674

From steve at hibernate.org  Wed Jun 13 13:20:09 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 Jun 2018 12:20:09 -0500
Subject: [hibernate-dev] Help please: HHH-12674 Upgrade to Gradle 4.8
In-Reply-To: <CAFm4XO1YEPKv7L4SepWq0t7pHgR-XsmyR821q0R-HqaqSkq9SQ@mail.gmail.com>
References: <CAFm4XO1CpDtd8ThRCWsDgYJBnNj7pY1nao5ZEVSu2BZ5waJatA@mail.gmail.com>
	<CAFm4XO1YEPKv7L4SepWq0t7pHgR-XsmyR821q0R-HqaqSkq9SQ@mail.gmail.com>
Message-ID: <CAFdSV9vHT_H08p-Pbh9WtK+PEo3QAJaO=i2ocMKde4ggzgco7w@mail.gmail.com>

Well to be fair, if they tried to stay ahead of the curve on all these new
JDK releases they'd do nothing else ;)

Anyway, glad you worked it out.

On Wed, Jun 13, 2018 at 12:03 PM Sanne Grinovero <sanne at hibernate.org>
wrote:

> Just an update: Steve and Andrea helped me and we got it done.
>
> We can finally run the full build on JDK10; for JDK11 we still need to
> sort out some details, e.g. yet another Gradle update.
> On Fri, 8 Jun 2018 at 10:12, Sanne Grinovero <sanne at hibernate.org> wrote:
> >
> > I previously upgraded Hibernate ORM to Gradle 4.7, that was trivial.
> >
> > I'd like us to upgrade to 4.8 (now also released) so to keep going
> > testing with JDK11 - but I got some puzzling errors with the Gradle
> > build to remind me that this is still beyond my Gradle-fu :)
> >
> > If someone else could take [1] that would be very nice... thanks!
> >
> > Sanne
> >
> >  1 - https://hibernate.atlassian.net/browse/HHH-12674
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Sat Jun 16 03:05:35 2018
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Sat, 16 Jun 2018 09:05:35 +0200
Subject: [hibernate-dev] HTTPS for Bean Validation
Message-ID: <A4246237-4A8E-4B94-91D3-5877327186B6@hibernate.org>

I?ve enabled HTTPS for BV after a bit of a fight with the DNS entries. I?m planning to enforce HTTPS only in a few days. 

Have all of our GH pages hosted properties moved to HTTPS?
What about the other properties?

Emmanuel 


From emmanuel at hibernate.org  Sat Jun 16 03:08:01 2018
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Sat, 16 Jun 2018 09:08:01 +0200
Subject: [hibernate-dev] Help please: HHH-12674 Upgrade to Gradle 4.8
In-Reply-To: <CAFdSV9vHT_H08p-Pbh9WtK+PEo3QAJaO=i2ocMKde4ggzgco7w@mail.gmail.com>
References: <CAFm4XO1CpDtd8ThRCWsDgYJBnNj7pY1nao5ZEVSu2BZ5waJatA@mail.gmail.com>
	<CAFm4XO1YEPKv7L4SepWq0t7pHgR-XsmyR821q0R-HqaqSkq9SQ@mail.gmail.com>
	<CAFdSV9vHT_H08p-Pbh9WtK+PEo3QAJaO=i2ocMKde4ggzgco7w@mail.gmail.com>
Message-ID: <D3B4F147-7FF9-4F73-B591-3824271032C3@hibernate.org>

That?s a good question. I don?t know if that was mainly due to the JDK 9 follow up or if the JDK will keep breaking stuff at rapid pace - which is supposed to be different that releasing at a rapid pace ;)

> On 13 Jun 2018, at 19:20, Steve Ebersole <steve at hibernate.org> wrote:
> 
> Well to be fair, if they tried to stay ahead of the curve on all these new
> JDK releases they'd do nothing else ;)
> 
> Anyway, glad you worked it out.
> 
> On Wed, Jun 13, 2018 at 12:03 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> 
>> Just an update: Steve and Andrea helped me and we got it done.
>> 
>> We can finally run the full build on JDK10; for JDK11 we still need to
>> sort out some details, e.g. yet another Gradle update.
>>> On Fri, 8 Jun 2018 at 10:12, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> 
>>> I previously upgraded Hibernate ORM to Gradle 4.7, that was trivial.
>>> 
>>> I'd like us to upgrade to 4.8 (now also released) so to keep going
>>> testing with JDK11 - but I got some puzzling errors with the Gradle
>>> build to remind me that this is still beyond my Gradle-fu :)
>>> 
>>> If someone else could take [1] that would be very nice... thanks!
>>> 
>>> Sanne
>>> 
>>> 1 - https://hibernate.atlassian.net/browse/HHH-12674
>> _______________________________________________
>> 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  Sat Jun 16 04:06:05 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sat, 16 Jun 2018 10:06:05 +0200
Subject: [hibernate-dev] HTTPS for Bean Validation
In-Reply-To: <A4246237-4A8E-4B94-91D3-5877327186B6@hibernate.org>
References: <A4246237-4A8E-4B94-91D3-5877327186B6@hibernate.org>
Message-ID: <CADGJaX_z9qFgp-WCgEVN4aRy2bvuUHY_T8U0BZzwFAh5DdJyDg@mail.gmail.com>

Excellent, thanks a lot! Do you have a link to instructions you followed?
Would like to do the same for another site of mine.

2018-06-16 9:05 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> I?ve enabled HTTPS for BV after a bit of a fight with the DNS entries. I?m
> planning to enforce HTTPS only in a few days.
>
> Have all of our GH pages hosted properties moved to HTTPS?
> What about the other properties?
>
> Emmanuel
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Sat Jun 16 10:20:08 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Sat, 16 Jun 2018 16:20:08 +0200
Subject: [hibernate-dev] HTTPS for Bean Validation
In-Reply-To: <A4246237-4A8E-4B94-91D3-5877327186B6@hibernate.org>
References: <A4246237-4A8E-4B94-91D3-5877327186B6@hibernate.org>
Message-ID: <CALt0+o-pYh8wmhe+18EkY-h=w3eBg_9JfRNbTgTRV0soXqNftQ@mail.gmail.com>

Hi,

On Sat, Jun 16, 2018 at 9:08 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Have all of our GH pages hosted properties moved to HTTPS?
> What about the other properties?
>

A month ago or so, I moved the hibernate.org DNS to the SSL enabled GitHub
hosts and enabled SSL (had to disable then reenable the website to trigger
the certificate generation).

The issue is that hibernate.org uses a JSON feed from in.relation.to and
thus requires in.relation.to to be served on HTTPS too (otherwise, the news
simply don't appear). So I haven't enforced HTTPS for now.

in.relation.to is a bit special as it's not hosted on GitHub but directly
on our CI (you can have only one website per organization on GH). Sanne
told me he started the work on getting in.relation.to on HTTPS but got
stuck somehow with the certificates. He will probably reply with the
details.

I concur it would be high time to move all our website to HTTPS so ready to
spend some cycle on it if any help is needed.

One thing we could do that would simplify a lot of things is moving
in.relation.to to its own organization and have the website on GH. It
wouldn't be too much work and would solve the issue once and for all and
get our web infrastructure consistent.

Thoughts on this idea?

-- 
Guillaume

From emmanuel at hibernate.org  Sat Jun 16 12:58:12 2018
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Sat, 16 Jun 2018 18:58:12 +0200
Subject: [hibernate-dev] HTTPS for Bean Validation
In-Reply-To: <CADGJaX_z9qFgp-WCgEVN4aRy2bvuUHY_T8U0BZzwFAh5DdJyDg@mail.gmail.com>
References: <A4246237-4A8E-4B94-91D3-5877327186B6@hibernate.org>
	<CADGJaX_z9qFgp-WCgEVN4aRy2bvuUHY_T8U0BZzwFAh5DdJyDg@mail.gmail.com>
Message-ID: <B8A4A2A9-EBAF-4C25-8D76-8A0EE5765E8A@hibernate.org>

https://blog.github.com/2018-05-01-github-pages-custom-domains-https/

update your DNS records to the new IPs,
Wait for propagation
And like Guillaume said, disable GH pages generation and reenable to trigger the move. 

Emmanuel

> On 16 Jun 2018, at 10:06, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Excellent, thanks a lot! Do you have a link to instructions you followed? Would like to do the same for another site of mine.
> 
> 2018-06-16 9:05 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> I?ve enabled HTTPS for BV after a bit of a fight with the DNS entries. I?m planning to enforce HTTPS only in a few days. 
>> 
>> Have all of our GH pages hosted properties moved to HTTPS?
>> What about the other properties?
>> 
>> Emmanuel 
>> 
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From emmanuel at hibernate.org  Sat Jun 16 13:01:00 2018
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Sat, 16 Jun 2018 19:01:00 +0200
Subject: [hibernate-dev] HTTPS for Bean Validation
In-Reply-To: <CALt0+o-pYh8wmhe+18EkY-h=w3eBg_9JfRNbTgTRV0soXqNftQ@mail.gmail.com>
References: <A4246237-4A8E-4B94-91D3-5877327186B6@hibernate.org>
	<CALt0+o-pYh8wmhe+18EkY-h=w3eBg_9JfRNbTgTRV0soXqNftQ@mail.gmail.com>
Message-ID: <6F944BB4-C25A-4818-BD35-B683052056DA@hibernate.org>

Let?s wait quickly for Sanne?s feedback on why he was having certificate issues. My experience with let?s encrypt has been stellar so far (httpd). 

> On 16 Jun 2018, at 16:20, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> 
> One thing we could do that would simplify a lot of things is moving in.relation.to to its own organization and have the website on GH. It wouldn't be too much work and would solve the issue once and for all and get our web infrastructure consistent.
> 
> Thoughts on this idea?

From steve at hibernate.org  Sat Jun 16 13:14:12 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 16 Jun 2018 12:14:12 -0500
Subject: [hibernate-dev] Native SQL Queries and Parameters
Message-ID: <CAFdSV9vTHxiLLFhDytE-Pi9hKVtoKKYSb26Jb4W8qohkv8o_yA@mail.gmail.com>

While working on 6.0 I am wondering whether it makes sense to support
parameters of anything other than basic types.  Personally I am thinking
not, but wanted to get other's opinions.

The idea being that neither SQL nor JDBC define support for bind parameters
of multiple values.  So expecting to bind non-simple values is not strictly
"native SQL" support.

From yoann at hibernate.org  Mon Jun 18 03:45:13 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Mon, 18 Jun 2018 09:45:13 +0200
Subject: [hibernate-dev] Native SQL Queries and Parameters
In-Reply-To: <CAEqagpoYNZ9WuYgWsaCm=V1mbQphL55jyJRtLhT+N-mCVEiyKA@mail.gmail.com>
References: <CAFdSV9vTHxiLLFhDytE-Pi9hKVtoKKYSb26Jb4W8qohkv8o_yA@mail.gmail.com>
	<CAEqagpoYNZ9WuYgWsaCm=V1mbQphL55jyJRtLhT+N-mCVEiyKA@mail.gmail.com>
Message-ID: <CAEqagprwLZD=c0iU9n1TWPjhq32W7d4NbRWPf5y4bksRXL78Uw@mail.gmail.com>

If by "basic types" you mean *all* basic types, including user-defined
ones, I think it would make sense. Otherwise it sounds a bit limiting.

There's the case of embedded IDs that might be considered as an exception,
but I'm not sure there's a compelling reason to do so.

By the way... it's not native queries, but it illustrates the challenges of
supporting such composite types. There is currently some support for
composite types in ORM 5, in org.hibernate.criterion.Order#toSqlString,
Restrictions.gt, Restrictions.ge, etc. But restrictions are a bit buggy, in
a way that we had to circumvent in Hibernate Search [1]. In short they do
not implement restrictions lexicographically, resulting in
Restrictions.disjunction( Restrictions.gt( "myCompositeProperty", someValue
), Restrictions.le( "myCompositeProperty", someValue ) ) not matching all
records, which may be counter-intuitive to some.
Would it make sense for me to open a ticket? I'm not sure that's the kind
of behavior one can change in 5, but maybe in a major such as 6...

[1] *https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/
<https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L106>https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107
<https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107>**jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
<https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L106>*


On Mon, 18 Jun 2018 at 09:44 Yoann Rodiere <yrodiere at redhat.com> wrote:

> If by "basic types" you mean *all* basic types, including user-defined
> ones, I think it would make sense. Otherwise it sounds a bit limiting.
>
> There's the case of embedded IDs that might be considered as an exception,
> but I'm not sure there's a compelling reason to do so.
>
> By the way... it's not native queries, but it illustrates the challenges
> of supporting such composite types. There is currently some support for
> composite types in ORM 5, in org.hibernate.criterion.Order#toSqlString,
> Restrictions.gt, Restrictions.ge, etc. But restrictions are a bit buggy, in
> a way that we had to circumvent in Hibernate Search [1]. In short they do
> not implement restrictions lexicographically, resulting in
> Restrictions.disjunction( Restrictions.gt( "myCompositeProperty", someValue
> ), Restrictions.le( "myCompositeProperty", someValue ) ) not matching all
> records, which may be counter-intuitive to some.
> Would it make sense for me to open a ticket? I'm not sure that's the kind
> of behavior one can change in 5, but maybe in a major such as 6...
>
> [1] *https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/
> <https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L106>https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107
> <https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107>**jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> <https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L106>*
>
>
> On Sat, 16 Jun 2018 at 20:20 Steve Ebersole <steve at hibernate.org> wrote:
>
>> While working on 6.0 I am wondering whether it makes sense to support
>> parameters of anything other than basic types.  Personally I am thinking
>> not, but wanted to get other's opinions.
>>
>> The idea being that neither SQL nor JDBC define support for bind
>> parameters
>> of multiple values.  So expecting to bind non-simple values is not
>> strictly
>> "native SQL" support.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From sanne at hibernate.org  Mon Jun 18 05:11:14 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 18 Jun 2018 10:11:14 +0100
Subject: [hibernate-dev] Help please: HHH-12674 Upgrade to Gradle 4.8
In-Reply-To: <D3B4F147-7FF9-4F73-B591-3824271032C3@hibernate.org>
References: <CAFm4XO1CpDtd8ThRCWsDgYJBnNj7pY1nao5ZEVSu2BZ5waJatA@mail.gmail.com>
	<CAFm4XO1YEPKv7L4SepWq0t7pHgR-XsmyR821q0R-HqaqSkq9SQ@mail.gmail.com>
	<CAFdSV9vHT_H08p-Pbh9WtK+PEo3QAJaO=i2ocMKde4ggzgco7w@mail.gmail.com>
	<D3B4F147-7FF9-4F73-B591-3824271032C3@hibernate.org>
Message-ID: <CAFm4XO2kF7tx6AJNpCLYf=kS64aoopmEJLmD6WyzoJnnP9GL+Q@mail.gmail.com>

On Sat, 16 Jun 2018 at 08:08, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
> That?s a good question. I don?t know if that was mainly due to the JDK 9 follow up or if the JDK will keep breaking stuff at rapid pace - which is supposed to be different that releasing at a rapid pace ;)

No crystal ball, but so far we had quite some work to do for each JDK
release; I thought I had highlighted that to you.

Certainly Jigsaw had a big impact when it came in 9, but that work is
far from over as barely any build tool / IDE / dependency management
has caught up yet: stuff "boots" today but there's a long list of
missing stuff. We're certainly far from getting benefits from it.

Then there's all the tangential chaos: in 9 we had issues with the EE
modules, such as the XML parsers; for that one the widely agreed on
solution was to use options like "--add-modules java.xml.bind", yet
now testing JDK11 that same module has been removed, so we need to
re-think that one.

Another example is Javadoc linting: options we need have been
deprecated in 9, removed in 10. With this faster pace affecting
deprecation + removal cycles one can't really be sure of what's going
to be broken within a year.

Doclet APIs are gone as well, some more JDK options and flags we used
now fail to start, and some such options are hardcoded in e.g. Maven
or Gradle extensions we used for other purposes.

The issues are compounding each other: since build tools are barely
able to keep up, some of our dependencies just don't keep up as they
can't easily build / test; hitting issues first is quite time
consuming and when reporting issues other communities aren't
particularly eager to fix those.
Not least sometimes we need to apply or experiment with JDK new flags
or solutions which are presented as the appropriate way forward - like
multi-release JARs - but build tools don't support them yet so you
need complex build workarounds.. which spread issues to IDEs, CI, ..
all needing updates, all breaking someone's workflow.

In short, so far it has been breaking stuff at increased pace. I don't
see it as too negative though, it's looking like overall speed is
faster in all areas so maybe "speed to break" is proprortionate to
overall speed increase - I hope thought that other communities we rely
on can adjust to this too. That includes ourselves, I needed another
HCANN release last weekend, some more metadata changes in ORM... list
goes on and we haven't touched much on actually benefitting from the
new version features.

Thanks,
Sanne



>
> > On 13 Jun 2018, at 19:20, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > Well to be fair, if they tried to stay ahead of the curve on all these new
> > JDK releases they'd do nothing else ;)
> >
> > Anyway, glad you worked it out.
> >
> > On Wed, Jun 13, 2018 at 12:03 PM Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >
> >> Just an update: Steve and Andrea helped me and we got it done.
> >>
> >> We can finally run the full build on JDK10; for JDK11 we still need to
> >> sort out some details, e.g. yet another Gradle update.
> >>> On Fri, 8 Jun 2018 at 10:12, Sanne Grinovero <sanne at hibernate.org> wrote:
> >>>
> >>> I previously upgraded Hibernate ORM to Gradle 4.7, that was trivial.
> >>>
> >>> I'd like us to upgrade to 4.8 (now also released) so to keep going
> >>> testing with JDK11 - but I got some puzzling errors with the Gradle
> >>> build to remind me that this is still beyond my Gradle-fu :)
> >>>
> >>> If someone else could take [1] that would be very nice... thanks!
> >>>
> >>> Sanne
> >>>
> >>> 1 - https://hibernate.atlassian.net/browse/HHH-12674
> >> _______________________________________________
> >> 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 andrea at hibernate.org  Mon Jun 18 06:43:41 2018
From: andrea at hibernate.org (andrea boriero)
Date: Mon, 18 Jun 2018 11:43:41 +0100
Subject: [hibernate-dev] Native SQL Queries and Parameters
In-Reply-To: <CAEqagprwLZD=c0iU9n1TWPjhq32W7d4NbRWPf5y4bksRXL78Uw@mail.gmail.com>
References: <CAFdSV9vTHxiLLFhDytE-Pi9hKVtoKKYSb26Jb4W8qohkv8o_yA@mail.gmail.com>
	<CAEqagpoYNZ9WuYgWsaCm=V1mbQphL55jyJRtLhT+N-mCVEiyKA@mail.gmail.com>
	<CAEqagprwLZD=c0iU9n1TWPjhq32W7d4NbRWPf5y4bksRXL78Uw@mail.gmail.com>
Message-ID: <CAL00eSSn4HpTyivSABm0SXJuT5NtuCK4qsnx9CYz20e9Kyci1A@mail.gmail.com>

for native SQL I think it makes sense to only support basic types for
parameters binding.


On Mon, 18 Jun 2018 at 08:45, Yoann Rodiere <yoann at hibernate.org> wrote:

> If by "basic types" you mean *all* basic types, including user-defined
> ones, I think it would make sense. Otherwise it sounds a bit limiting.
>
> There's the case of embedded IDs that might be considered as an exception,
> but I'm not sure there's a compelling reason to do so.
>
> By the way... it's not native queries, but it illustrates the challenges of
> supporting such composite types. There is currently some support for
> composite types in ORM 5, in org.hibernate.criterion.Order#toSqlString,
> Restrictions.gt, Restrictions.ge, etc. But restrictions are a bit buggy, in
> a way that we had to circumvent in Hibernate Search [1]. In short they do
> not implement restrictions lexicographically, resulting in
> Restrictions.disjunction( Restrictions.gt( "myCompositeProperty", someValue
> ), Restrictions.le( "myCompositeProperty", someValue ) ) not matching all
> records, which may be counter-intuitive to some.
> Would it make sense for me to open a ticket? I'm not sure that's the kind
> of behavior one can change in 5, but maybe in a major such as 6...
>
> [1] *
> https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/
> <
> https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> >
> https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107
> <
> https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107
> >**jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> <
> https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> >*
>
>
> On Mon, 18 Jun 2018 at 09:44 Yoann Rodiere <yrodiere at redhat.com> wrote:
>
> > If by "basic types" you mean *all* basic types, including user-defined
> > ones, I think it would make sense. Otherwise it sounds a bit limiting.
> >
> > There's the case of embedded IDs that might be considered as an
> exception,
> > but I'm not sure there's a compelling reason to do so.
> >
> > By the way... it's not native queries, but it illustrates the challenges
> > of supporting such composite types. There is currently some support for
> > composite types in ORM 5, in org.hibernate.criterion.Order#toSqlString,
> > Restrictions.gt, Restrictions.ge, etc. But restrictions are a bit buggy,
> in
> > a way that we had to circumvent in Hibernate Search [1]. In short they do
> > not implement restrictions lexicographically, resulting in
> > Restrictions.disjunction( Restrictions.gt( "myCompositeProperty",
> someValue
> > ), Restrictions.le( "myCompositeProperty", someValue ) ) not matching all
> > records, which may be counter-intuitive to some.
> > Would it make sense for me to open a ticket? I'm not sure that's the kind
> > of behavior one can change in 5, but maybe in a major such as 6...
> >
> > [1] *
> https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/
> > <
> https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> >
> https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107
> > <
> https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107
> >**jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> > <
> https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> >*
> >
> >
> > On Sat, 16 Jun 2018 at 20:20 Steve Ebersole <steve at hibernate.org> wrote:
> >
> >> While working on 6.0 I am wondering whether it makes sense to support
> >> parameters of anything other than basic types.  Personally I am thinking
> >> not, but wanted to get other's opinions.
> >>
> >> The idea being that neither SQL nor JDBC define support for bind
> >> parameters
> >> of multiple values.  So expecting to bind non-simple values is not
> >> strictly
> >> "native SQL" support.
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > --
> > Yoann Rodiere
> > yoann at hibernate.org / yrodiere at redhat.com
> > Software Engineer
> > Hibernate NoORM team
> >
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Jun 18 08:16:29 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 18 Jun 2018 07:16:29 -0500
Subject: [hibernate-dev] Native SQL Queries and Parameters
In-Reply-To: <CAEqagpoYNZ9WuYgWsaCm=V1mbQphL55jyJRtLhT+N-mCVEiyKA@mail.gmail.com>
References: <CAFdSV9vTHxiLLFhDytE-Pi9hKVtoKKYSb26Jb4W8qohkv8o_yA@mail.gmail.com>
	<CAEqagpoYNZ9WuYgWsaCm=V1mbQphL55jyJRtLhT+N-mCVEiyKA@mail.gmail.com>
Message-ID: <CAFdSV9siJndEHq+Kbj5yj0T0E378rogDDXa7Yrz8HRhCk9kKqA@mail.gmail.com>

On Mon, Jun 18, 2018, 2:44 AM Yoann Rodiere <yrodiere at redhat.com> wrote:

> If by "basic types" you mean *all* basic types, including user-defined
> ones, I think it would make sense. Otherwise it sounds a bit limiting.
>

In 6.0 "user-defined type" means a very different thing generally speaking.
But I mean any BasicType, which may be a Hibernate class or a user class.

>


> There's the case of embedded IDs that might be considered as an exception,
> but I'm not sure there's a compelling reason to do so.
>

But this is my point.  We can support composite parameters here.  The
question really is whether we want to.  In SQL there is no construct like
`(col1, col2) " ?` regardless of whether col1 and col2 are PK columns or
normal columns.

Really what I am asking is how closely we want native queries to look, feel
and work like a SQL query.  Otherwise it's not really "native"




> By the way... it's not native queries, but it illustrates the challenges
> of supporting such composite types. There is currently some support for
> composite types in ORM 5, in org.hibernate.criterion.Order#toSqlString,
> Restrictions.gt, Restrictions.ge, etc. But restrictions are a bit buggy, in
> a way that we had to circumvent in Hibernate Search [1]. In short they do
> not implement restrictions lexicographically, resulting in
> Restrictions.disjunction( Restrictions.gt( "myCompositeProperty", someValue
> ), Restrictions.le( "myCompositeProperty", someValue ) ) not matching all
> records, which may be counter-intuitive to some.
> Would it make sense for me to open a ticket? I'm not sure that's the kind
> of behavior one can change in 5, but maybe in a major such as 6...
>

You are talking about Hibernate's legacy criteria API which has been
deprecated for many years now and is already gone in 6.  So no, I don't
want to see Jiras for that ?



> [1] *https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/
> <https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L106>https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107
> <https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107>**jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> <https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L106>*
>
>
> On Sat, 16 Jun 2018 at 20:20 Steve Ebersole <steve at hibernate.org> wrote:
>
>> While working on 6.0 I am wondering whether it makes sense to support
>> parameters of anything other than basic types.  Personally I am thinking
>> not, but wanted to get other's opinions.
>>
>> The idea being that neither SQL nor JDBC define support for bind
>> parameters
>> of multiple values.  So expecting to bind non-simple values is not
>> strictly
>> "native SQL" support.
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team
>

From sanne at hibernate.org  Mon Jun 18 11:49:31 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 18 Jun 2018 16:49:31 +0100
Subject: [hibernate-dev] HTTPS for Bean Validation
In-Reply-To: <6F944BB4-C25A-4818-BD35-B683052056DA@hibernate.org>
References: <A4246237-4A8E-4B94-91D3-5877327186B6@hibernate.org>
	<CALt0+o-pYh8wmhe+18EkY-h=w3eBg_9JfRNbTgTRV0soXqNftQ@mail.gmail.com>
	<6F944BB4-C25A-4818-BD35-B683052056DA@hibernate.org>
Message-ID: <CAFm4XO1VmdC3b-sHLByqz6deNsAAUk4K+0S_+kdv6OVDdx7MiA@mail.gmail.com>

On Sat, 16 Jun 2018 at 18:51, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
> Let?s wait quickly for Sanne?s feedback on why he was having certificate issues. My experience with let?s encrypt has been stellar so far (httpd).

I was experimenting with "let's encrypt" but then you told me that I
wasn't allowed to use that service.

So if that's no longer true I can resume my experiments? I don't
remember the details of the issues I had exactly; there was something
related with using an incompatible httpd version.

>
> > On 16 Jun 2018, at 16:20, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> >
> > One thing we could do that would simplify a lot of things is moving in.relation.to to its own organization and have the website on GH. It wouldn't be too much work and would solve the issue once and for all and get our web infrastructure consistent.
> >
> > Thoughts on this idea?

I'm understanding GH now offers a

I'm still hoping to move our javadocs as well after we move the
websites though, so not sure if that's worth it as we'll always have
some

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


From henri.tremblay at gmail.com  Mon Jun 18 14:32:24 2018
From: henri.tremblay at gmail.com (Henri Tremblay)
Date: Mon, 18 Jun 2018 14:32:24 -0400
Subject: [hibernate-dev] Provide a RegionFactory from Spring
Message-ID: <CADZL2=uQpEMV=gK=acU=PQLgadF5YKbotih4YNkqYyoAwitOZQ@mail.gmail.com>

Hi,

A change in the latest Spring Boot version is now setting a real class
loader when creating a JCache cache manager. Before it used to pass null.
Just like Hibernate still does.

So right now, we end up with two class managers. One for Hibernate 2nd
level cache and one for Spring cache.

We made a workaround in JHipster. You can see the full code and discussion
here
https://github.com/hibernate/hibernate-orm/pull/2351

It's not super pretty. The Hibernate region factory is instantiated from a
property using the no-args constructor. So we set the wanted class loader
to a static variable and retrieves it in the region factory implementation.
It works. But it's not pretty.

I was looking for a cleaner solution. Probably passing a Contributor to
Hibernate.

Is there a way to programmatically pass a contributor or a region factory
to Hibernate? From Spring Boot.

Thanks,
Henri

From emmanuel at hibernate.org  Mon Jun 18 16:47:47 2018
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 18 Jun 2018 22:47:47 +0200
Subject: [hibernate-dev] HTTPS for Bean Validation
In-Reply-To: <CAFm4XO1VmdC3b-sHLByqz6deNsAAUk4K+0S_+kdv6OVDdx7MiA@mail.gmail.com>
References: <A4246237-4A8E-4B94-91D3-5877327186B6@hibernate.org>
	<CALt0+o-pYh8wmhe+18EkY-h=w3eBg_9JfRNbTgTRV0soXqNftQ@mail.gmail.com>
	<6F944BB4-C25A-4818-BD35-B683052056DA@hibernate.org>
	<CAFm4XO1VmdC3b-sHLByqz6deNsAAUk4K+0S_+kdv6OVDdx7MiA@mail.gmail.com>
Message-ID: <15A32D57-9F3A-49A8-9525-F4E26E0C7B0B@hibernate.org>



> On 18 Jun 2018, at 17:49, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> I was experimenting with "let's encrypt" but then you told me that I
> wasn't allowed to use that service.

I don?t remember saying that. Knowing me I surely gave you a reason :)


From steve at hibernate.org  Mon Jun 18 16:51:36 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 18 Jun 2018 15:51:36 -0500
Subject: [hibernate-dev] Provide a RegionFactory from Spring
In-Reply-To: <CADZL2=uQpEMV=gK=acU=PQLgadF5YKbotih4YNkqYyoAwitOZQ@mail.gmail.com>
References: <CADZL2=uQpEMV=gK=acU=PQLgadF5YKbotih4YNkqYyoAwitOZQ@mail.gmail.com>
Message-ID: <CAFdSV9s4NVnzt6etSR4W2254SW6Auvjdr32fL2QrAzze1wqorQ@mail.gmail.com>

You can pass a RegionFactory instance.

On Mon, Jun 18, 2018 at 1:48 PM Henri Tremblay <henri.tremblay at gmail.com>
wrote:

> Hi,
>
> A change in the latest Spring Boot version is now setting a real class
> loader when creating a JCache cache manager. Before it used to pass null.
> Just like Hibernate still does.
>
> So right now, we end up with two class managers. One for Hibernate 2nd
> level cache and one for Spring cache.
>
> We made a workaround in JHipster. You can see the full code and discussion
> here
> https://github.com/hibernate/hibernate-orm/pull/2351
>
> It's not super pretty. The Hibernate region factory is instantiated from a
> property using the no-args constructor. So we set the wanted class loader
> to a static variable and retrieves it in the region factory implementation.
> It works. But it's not pretty.
>
> I was looking for a cleaner solution. Probably passing a Contributor to
> Hibernate.
>
> Is there a way to programmatically pass a contributor or a region factory
> to Hibernate? From Spring Boot.
>
> Thanks,
> Henri
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Jun 18 16:52:33 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 18 Jun 2018 15:52:33 -0500
Subject: [hibernate-dev] Provide a RegionFactory from Spring
In-Reply-To: <CAFdSV9s4NVnzt6etSR4W2254SW6Auvjdr32fL2QrAzze1wqorQ@mail.gmail.com>
References: <CADZL2=uQpEMV=gK=acU=PQLgadF5YKbotih4YNkqYyoAwitOZQ@mail.gmail.com>
	<CAFdSV9s4NVnzt6etSR4W2254SW6Auvjdr32fL2QrAzze1wqorQ@mail.gmail.com>
Message-ID: <CAFdSV9tR8bwZbCR2s2vak4T1ReUaKRzZzqEDcN4K3T_qjLYPmQ@mail.gmail.com>

Or Class (not String) loaded from the proper ClassLoader

On Mon, Jun 18, 2018 at 3:51 PM Steve Ebersole <steve at hibernate.org> wrote:

> You can pass a RegionFactory instance.
>
> On Mon, Jun 18, 2018 at 1:48 PM Henri Tremblay <henri.tremblay at gmail.com>
> wrote:
>
>> Hi,
>>
>> A change in the latest Spring Boot version is now setting a real class
>> loader when creating a JCache cache manager. Before it used to pass null.
>> Just like Hibernate still does.
>>
>> So right now, we end up with two class managers. One for Hibernate 2nd
>> level cache and one for Spring cache.
>>
>> We made a workaround in JHipster. You can see the full code and discussion
>> here
>> https://github.com/hibernate/hibernate-orm/pull/2351
>>
>> It's not super pretty. The Hibernate region factory is instantiated from a
>> property using the no-args constructor. So we set the wanted class loader
>> to a static variable and retrieves it in the region factory
>> implementation.
>> It works. But it's not pretty.
>>
>> I was looking for a cleaner solution. Probably passing a Contributor to
>> Hibernate.
>>
>> Is there a way to programmatically pass a contributor or a region factory
>> to Hibernate? From Spring Boot.
>>
>> Thanks,
>> Henri
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Tue Jun 19 09:36:08 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 Jun 2018 08:36:08 -0500
Subject: [hibernate-dev] Backport caching ValueBinders and ValueExtractors
 for a SqlTypeDescriptor from 6.0 to 5.x
Message-ID: <CAFdSV9tVe_am4T5BPa2Pwffm3CjESvW9BDUCMNog=5sB7r5j8g@mail.gmail.com>

Today, when either `SqlTypeDescriptor#getBinder` or
`SqlTypeDescriptor#getExtractor` are called we build/calculate the
binder/extractor each and every time.  In 6.0 we added code that caches
these binders and extractors as they are requested.

IMO we should backport the idea of caching these to 5.x.  Any volunteers?

The code on 6.0 is still local to my machine, but the code in general looks
like[1]:

public interface SqlTypeDescriptor {
...

<X>JdbcValueMapper<X> getJdbcValueMapper(BasicJavaDescriptor<X>
javaTypeDescriptor);

@Remove
default <X> JdbcValueBinder<X> getBinder(BasicJavaDescriptor<X>
javaTypeDescriptor) {
return getJdbcValueMapper( javaTypeDescriptor ).getJdbcValueBinder();
}

@Remove
default <X> JdbcValueExtractor<X> getExtractor(BasicJavaDescriptor<X>
javaTypeDescriptor) {
return getJdbcValueMapper( javaTypeDescriptor ).getJdbcValueExtractor();
}
}

public abstract class AbstractSqlTypeDescriptor implements
SqlTypeDescriptor {
private final Map<JavaTypeDescriptor<?>,JdbcValueMapper<?>>
valueMapperCache = new ConcurrentHashMap<>();

protected <J> JdbcValueMapper<J> determineValueMapper(
JavaTypeDescriptor<J> javaTypeDescriptor,
Function<JavaTypeDescriptor<J>,JdbcValueMapper<J>> creator) {
return (JdbcValueMapper<J>) valueMapperCache.computeIfAbsent(
javaTypeDescriptor,
javaTypeDescriptor1 -> creator.apply( javaTypeDescriptor )
);
}
}

public abstract class AbstractTemplateSqlTypeDescriptor extends
AbstractSqlTypeDescriptor {
@Override
public <X> JdbcValueMapper<X> getJdbcValueMapper(BasicJavaDescriptor<X>
javaTypeDescriptor) {
return determineValueMapper(
javaTypeDescriptor,
jtd -> {
final JdbcValueBinder<X> binder = createBinder( javaTypeDescriptor );
final JdbcValueExtractor<X> extractor = createExtractor( javaTypeDescriptor
);

return new JdbcValueMapperImpl<>( javaTypeDescriptor, this, extractor,
binder );
}
);
}

protected abstract <X> JdbcValueBinder<X>
createBinder(BasicJavaDescriptor<X> javaTypeDescriptor);

protected abstract <X> JdbcValueExtractor<X>
createExtractor(BasicJavaDescriptor<X> javaTypeDescriptor);
}


[1] In 6.0 ValueBinder is replaced by JdbcValueBinder and ValueExtractor is
replaced by JdbcValueExtractor - the new variants serve the same basic
purposes but in different ways related to the other changes  in 6.0.
JdbcValueMapper is a new contract that combines a JavaTypeDescriptor
(specifically a BasicJavaDescriptor since all JDBC types are "basic"),
SqlTypeDescriptor, JdbcValueBinder and JdbcValueExtractor

From sanne at hibernate.org  Tue Jun 19 10:13:18 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 19 Jun 2018 15:13:18 +0100
Subject: [hibernate-dev] HTTPS for Bean Validation
In-Reply-To: <15A32D57-9F3A-49A8-9525-F4E26E0C7B0B@hibernate.org>
References: <A4246237-4A8E-4B94-91D3-5877327186B6@hibernate.org>
	<CALt0+o-pYh8wmhe+18EkY-h=w3eBg_9JfRNbTgTRV0soXqNftQ@mail.gmail.com>
	<6F944BB4-C25A-4818-BD35-B683052056DA@hibernate.org>
	<CAFm4XO1VmdC3b-sHLByqz6deNsAAUk4K+0S_+kdv6OVDdx7MiA@mail.gmail.com>
	<15A32D57-9F3A-49A8-9525-F4E26E0C7B0B@hibernate.org>
Message-ID: <CAFm4XO0inQp0vnKFodev3SO2Wu2DM_9QTi8DSrY49QJ6c39hEA@mail.gmail.com>

On Mon, 18 Jun 2018 at 21:48, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>
>
> > On 18 Jun 2018, at 17:49, Sanne Grinovero <sanne at hibernate.org> wrote:
> >
> > I was experimenting with "let's encrypt" but then you told me that I
> > wasn't allowed to use that service.
>
> I don?t remember saying that. Knowing me I surely gave you a reason :)

Yes, you did :)


From emmanuel at hibernate.org  Tue Jun 19 11:31:36 2018
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 19 Jun 2018 17:31:36 +0200
Subject: [hibernate-dev] HTTPS for Bean Validation
In-Reply-To: <CAFm4XO0inQp0vnKFodev3SO2Wu2DM_9QTi8DSrY49QJ6c39hEA@mail.gmail.com>
References: <A4246237-4A8E-4B94-91D3-5877327186B6@hibernate.org>
	<CALt0+o-pYh8wmhe+18EkY-h=w3eBg_9JfRNbTgTRV0soXqNftQ@mail.gmail.com>
	<6F944BB4-C25A-4818-BD35-B683052056DA@hibernate.org>
	<CAFm4XO1VmdC3b-sHLByqz6deNsAAUk4K+0S_+kdv6OVDdx7MiA@mail.gmail.com>
	<15A32D57-9F3A-49A8-9525-F4E26E0C7B0B@hibernate.org>
	<CAFm4XO0inQp0vnKFodev3SO2Wu2DM_9QTi8DSrY49QJ6c39hEA@mail.gmail.com>
Message-ID: <20180619153136.GA23792@hibernate.org>

On Tue 18-06-19 15:13, Sanne Grinovero wrote:
>On Mon, 18 Jun 2018 at 21:48, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>
>>
>>
>> > On 18 Jun 2018, at 17:49, Sanne Grinovero <sanne at hibernate.org> wrote:
>> >
>> > I was experimenting with "let's encrypt" but then you told me that I
>> > wasn't allowed to use that service.
>>
>> I don?t remember saying that. Knowing me I surely gave you a reason :)
>
>Yes, you did :)

What was it?

From guillaume.smet at hibernate.org  Tue Jun 19 11:35:19 2018
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Tue, 19 Jun 2018 17:35:19 +0200
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o9xwrL_NhLo8gEYJpsYRFT0=XJxswCa09uNW91wdBQ9ww@mail.gmail.com>

Hi everyone,

Here are the minutes of our NoORM IRC meeting:

15:59 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-06-19-13.07.html
15:59 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-06-19-13.07.txt
15:59 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-06-19-13.07.log.html

Cheers,

-- 
Guillaume

From sanne at hibernate.org  Tue Jun 19 11:36:44 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 19 Jun 2018 16:36:44 +0100
Subject: [hibernate-dev] HTTPS for Bean Validation
In-Reply-To: <20180619153136.GA23792@hibernate.org>
References: <A4246237-4A8E-4B94-91D3-5877327186B6@hibernate.org>
	<CALt0+o-pYh8wmhe+18EkY-h=w3eBg_9JfRNbTgTRV0soXqNftQ@mail.gmail.com>
	<6F944BB4-C25A-4818-BD35-B683052056DA@hibernate.org>
	<CAFm4XO1VmdC3b-sHLByqz6deNsAAUk4K+0S_+kdv6OVDdx7MiA@mail.gmail.com>
	<15A32D57-9F3A-49A8-9525-F4E26E0C7B0B@hibernate.org>
	<CAFm4XO0inQp0vnKFodev3SO2Wu2DM_9QTi8DSrY49QJ6c39hEA@mail.gmail.com>
	<20180619153136.GA23792@hibernate.org>
Message-ID: <CAFm4XO0DN9g+bphruDBoSVB1pVYs019cd0HF+upS0q0r8LRZyQ@mail.gmail.com>

On Tue, 19 Jun 2018 at 16:32, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
> On Tue 18-06-19 15:13, Sanne Grinovero wrote:
> >On Mon, 18 Jun 2018 at 21:48, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> >>
> >>
> >>
> >> > On 18 Jun 2018, at 17:49, Sanne Grinovero <sanne at hibernate.org> wrote:
> >> >
> >> > I was experimenting with "let's encrypt" but then you told me that I
> >> > wasn't allowed to use that service.
> >>
> >> I don?t remember saying that. Knowing me I surely gave you a reason :)
> >
> >Yes, you did :)
>
> What was it?

Preference to use the existing certificate authority.


From emmanuel at hibernate.org  Tue Jun 19 11:53:12 2018
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 19 Jun 2018 17:53:12 +0200
Subject: [hibernate-dev] HTTPS for Bean Validation
In-Reply-To: <CAFm4XO0DN9g+bphruDBoSVB1pVYs019cd0HF+upS0q0r8LRZyQ@mail.gmail.com>
References: <A4246237-4A8E-4B94-91D3-5877327186B6@hibernate.org>
	<CALt0+o-pYh8wmhe+18EkY-h=w3eBg_9JfRNbTgTRV0soXqNftQ@mail.gmail.com>
	<6F944BB4-C25A-4818-BD35-B683052056DA@hibernate.org>
	<CAFm4XO1VmdC3b-sHLByqz6deNsAAUk4K+0S_+kdv6OVDdx7MiA@mail.gmail.com>
	<15A32D57-9F3A-49A8-9525-F4E26E0C7B0B@hibernate.org>
	<CAFm4XO0inQp0vnKFodev3SO2Wu2DM_9QTi8DSrY49QJ6c39hEA@mail.gmail.com>
	<20180619153136.GA23792@hibernate.org>
	<CAFm4XO0DN9g+bphruDBoSVB1pVYs019cd0HF+upS0q0r8LRZyQ@mail.gmail.com>
Message-ID: <20180619155312.GA24446@hibernate.org>

On Tue 18-06-19 16:36, Sanne Grinovero wrote:
>On Tue, 19 Jun 2018 at 16:32, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>
>> On Tue 18-06-19 15:13, Sanne Grinovero wrote:
>> >On Mon, 18 Jun 2018 at 21:48, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> >>
>> >>
>> >>
>> >> > On 18 Jun 2018, at 17:49, Sanne Grinovero <sanne at hibernate.org> wrote:
>> >> >
>> >> > I was experimenting with "let's encrypt" but then you told me that I
>> >> > wasn't allowed to use that service.
>> >>
>> >> I don?t remember saying that. Knowing me I surely gave you a reason :)
>> >
>> >Yes, you did :)
>>
>> What was it?
>
>Preference to use the existing certificate authority.

Yes ok, that's the one I could reconstruct from first principle. Plus it
would give us EV which is better. But if that becomes a hurdle and slow
down the project by 2 months, then better start with a let's encrypt
one.

From andrea at hibernate.org  Wed Jun 20 05:09:01 2018
From: andrea at hibernate.org (andrea boriero)
Date: Wed, 20 Jun 2018 10:09:01 +0100
Subject: [hibernate-dev] Backport caching ValueBinders and
 ValueExtractors for a SqlTypeDescriptor from 6.0 to 5.x
In-Reply-To: <CAFdSV9tVe_am4T5BPa2Pwffm3CjESvW9BDUCMNog=5sB7r5j8g@mail.gmail.com>
References: <CAFdSV9tVe_am4T5BPa2Pwffm3CjESvW9BDUCMNog=5sB7r5j8g@mail.gmail.com>
Message-ID: <CAL00eSQau24qc-1Y=FeLs5jWfabPXEY39wPV+JPOU3=zXVW-9w@mail.gmail.com>

I can do it.

On Tue, 19 Jun 2018 at 14:37, Steve Ebersole <steve at hibernate.org> wrote:

> Today, when either `SqlTypeDescriptor#getBinder` or
> `SqlTypeDescriptor#getExtractor` are called we build/calculate the
> binder/extractor each and every time.  In 6.0 we added code that caches
> these binders and extractors as they are requested.
>
> IMO we should backport the idea of caching these to 5.x.  Any volunteers?
>
> The code on 6.0 is still local to my machine, but the code in general looks
> like[1]:
>
> public interface SqlTypeDescriptor {
> ...
>
> <X>JdbcValueMapper<X> getJdbcValueMapper(BasicJavaDescriptor<X>
> javaTypeDescriptor);
>
> @Remove
> default <X> JdbcValueBinder<X> getBinder(BasicJavaDescriptor<X>
> javaTypeDescriptor) {
> return getJdbcValueMapper( javaTypeDescriptor ).getJdbcValueBinder();
> }
>
> @Remove
> default <X> JdbcValueExtractor<X> getExtractor(BasicJavaDescriptor<X>
> javaTypeDescriptor) {
> return getJdbcValueMapper( javaTypeDescriptor ).getJdbcValueExtractor();
> }
> }
>
> public abstract class AbstractSqlTypeDescriptor implements
> SqlTypeDescriptor {
> private final Map<JavaTypeDescriptor<?>,JdbcValueMapper<?>>
> valueMapperCache = new ConcurrentHashMap<>();
>
> protected <J> JdbcValueMapper<J> determineValueMapper(
> JavaTypeDescriptor<J> javaTypeDescriptor,
> Function<JavaTypeDescriptor<J>,JdbcValueMapper<J>> creator) {
> return (JdbcValueMapper<J>) valueMapperCache.computeIfAbsent(
> javaTypeDescriptor,
> javaTypeDescriptor1 -> creator.apply( javaTypeDescriptor )
> );
> }
> }
>
> public abstract class AbstractTemplateSqlTypeDescriptor extends
> AbstractSqlTypeDescriptor {
> @Override
> public <X> JdbcValueMapper<X> getJdbcValueMapper(BasicJavaDescriptor<X>
> javaTypeDescriptor) {
> return determineValueMapper(
> javaTypeDescriptor,
> jtd -> {
> final JdbcValueBinder<X> binder = createBinder( javaTypeDescriptor );
> final JdbcValueExtractor<X> extractor = createExtractor( javaTypeDescriptor
> );
>
> return new JdbcValueMapperImpl<>( javaTypeDescriptor, this, extractor,
> binder );
> }
> );
> }
>
> protected abstract <X> JdbcValueBinder<X>
> createBinder(BasicJavaDescriptor<X> javaTypeDescriptor);
>
> protected abstract <X> JdbcValueExtractor<X>
> createExtractor(BasicJavaDescriptor<X> javaTypeDescriptor);
> }
>
>
> [1] In 6.0 ValueBinder is replaced by JdbcValueBinder and ValueExtractor is
> replaced by JdbcValueExtractor - the new variants serve the same basic
> purposes but in different ways related to the other changes  in 6.0.
> JdbcValueMapper is a new contract that combines a JavaTypeDescriptor
> (specifically a BasicJavaDescriptor since all JDBC types are "basic"),
> SqlTypeDescriptor, JdbcValueBinder and JdbcValueExtractor
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From henri.tremblay at gmail.com  Wed Jun 20 14:58:37 2018
From: henri.tremblay at gmail.com (Henri Tremblay)
Date: Wed, 20 Jun 2018 14:58:37 -0400
Subject: [hibernate-dev] Provide a RegionFactory from Spring
In-Reply-To: <CAFdSV9tR8bwZbCR2s2vak4T1ReUaKRzZzqEDcN4K3T_qjLYPmQ@mail.gmail.com>
References: <CADZL2=uQpEMV=gK=acU=PQLgadF5YKbotih4YNkqYyoAwitOZQ@mail.gmail.com>
	<CAFdSV9s4NVnzt6etSR4W2254SW6Auvjdr32fL2QrAzze1wqorQ@mail.gmail.com>
	<CAFdSV9tR8bwZbCR2s2vak4T1ReUaKRzZzqEDcN4K3T_qjLYPmQ@mail.gmail.com>
Message-ID: <CADZL2=tTwyRCZQf+j-dGOOQ71UiWstd9RUxoiLO0TW0K3BFafA@mail.gmail.com>

Thanks Steve.

If I got it right, to gain flexibility we should instantiate
programmatically?

Because right now, the region factory is a class defined in the Spring
configuration.

Do you have an code example (I haven't done programmatic instantiation of
Hibernate for a long long time)

On Mon, 18 Jun 2018 at 16:52, Steve Ebersole <steve at hibernate.org> wrote:

> Or Class (not String) loaded from the proper ClassLoader
>
> On Mon, Jun 18, 2018 at 3:51 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> You can pass a RegionFactory instance.
>>
>> On Mon, Jun 18, 2018 at 1:48 PM Henri Tremblay <henri.tremblay at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> A change in the latest Spring Boot version is now setting a real class
>>> loader when creating a JCache cache manager. Before it used to pass null.
>>> Just like Hibernate still does.
>>>
>>> So right now, we end up with two class managers. One for Hibernate 2nd
>>> level cache and one for Spring cache.
>>>
>>> We made a workaround in JHipster. You can see the full code and
>>> discussion
>>> here
>>> https://github.com/hibernate/hibernate-orm/pull/2351
>>>
>>> It's not super pretty. The Hibernate region factory is instantiated from
>>> a
>>> property using the no-args constructor. So we set the wanted class loader
>>> to a static variable and retrieves it in the region factory
>>> implementation.
>>> It works. But it's not pretty.
>>>
>>> I was looking for a cleaner solution. Probably passing a Contributor to
>>> Hibernate.
>>>
>>> Is there a way to programmatically pass a contributor or a region factory
>>> to Hibernate? From Spring Boot.
>>>
>>> Thanks,
>>> Henri
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From yoann at hibernate.org  Fri Jun 22 09:59:31 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 22 Jun 2018 15:59:31 +0200
Subject: [hibernate-dev] Hibernate Search 5.10.2.Final released
Message-ID: <CAEqagpp5FONWKx+G8ZGn9GKSF_eL869Eda0619yFtc0WTOjApQ@mail.gmail.com>

Hello,

We just published Hibernate Search version 5.10.2.Final, the second
maintenance release of Hibernate Search 5.10. This release adds previously
missing handling of minimumShouldMatch constraints in boolean junctions.

See our blog for more information:
http://in.relation.to/2018/06/22/hibernate-search-5-10-2-Final/

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

From sanne at hibernate.org  Thu Jun 28 14:29:16 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 28 Jun 2018 19:29:16 +0100
Subject: [hibernate-dev] Hibernate OGM on JDK10
Message-ID: <CAFm4XO2UmwT20w81-_DwhbSqakG3zBjXKnCDxrR+V2GdNXqhTg@mail.gmail.com>

Hibernate OGM is now also being tested on CI with an OpenJDK 10 job.

Let's keep it green ;)

 - http://ci.hibernate.org/view/JDK10/job/hibernate-ogm-master-jdk10/1/

Thanks,
Sanne

From postmaster at lists.jboss.org  Thu Jun 28 18:03:38 2018
From: postmaster at lists.jboss.org (Bounced mail)
Date: Fri, 29 Jun 2018 06:03:38 +0800
Subject: [hibernate-dev] Message could not be delivered
Message-ID: <201806282205.w5SM5HN9007927@lists01.dmz-a.mwc.hst.phx2.redhat.com>

The original message was received at Fri, 29 Jun 2018 06:03:38 +0800
from lists.jboss.org [154.188.185.178]

----- The following addresses had permanent fatal errors -----
<hibernate-dev at lists.jboss.org>