From yoann at hibernate.org  Wed May  2 07:49:25 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Wed, 02 May 2018 11:49:25 +0000
Subject: [hibernate-dev] Releases and CI setup
In-Reply-To: <CANoTJYPazyvZTkXBc60Dc9nTRb3YH8K2zALhz9--+bd1CGvBTQ@mail.gmail.com>
References: <CALt0+o9vioLiLrhpk64F1=7d2=1ujZ=je_LERmAWEGoqdE0Zvw@mail.gmail.com>
	<CAFm4XO1tEUw_qygK22OJLR4TNznO7X6POoPWAOehXwbdEGH7vA@mail.gmail.com>
	<CALt0+o9qhuAA-tzYfGcqew-fgQMy+gGETxJO7gEuJnBUGhVfrw@mail.gmail.com>
	<CANoTJYPazyvZTkXBc60Dc9nTRb3YH8K2zALhz9--+bd1CGvBTQ@mail.gmail.com>
Message-ID: <CAEqagpr7SPqahwCjRXhzgN+1VsHbYtW4-jZz4ZCciMitKYybqw@mail.gmail.com>

Let's keep in mind that the current way CI works is the only way we can
enable starting nodes on-demand. Any solution involving the "heavy job"
plugin like we used to will force us to have a static number of nodes, and
leave them up even when unused for extended periods of time, leading us to
either long waiting queues or higher costs. That's because the "heavy job"
plugin does not work well with the AWS plugin.
So it might have drawbacks, but it's not like other solutions are great
either.

I assume your problem was that all the instances were busy when you started
your release, so you had to wait for one build to be finished before your
release starts. As a temporary workaround, if it happens again before we
addressed the problem, you can simply start more instances manually by
going to http://ci.hibernate.org/computer/ and using the "Provision via
AWS" dropdown. This should work even if the instance cap has been reached,
and if your release job is already pending it will be the first to be
executed using this new instance.

Regarding your suggestions, I also think fixing the GitHub plugin would be
the way to go, since it would benefit to us beyond releases. We could first
try sending a pull request and asking for a release. If they don't react,
we'll have to ask ourselves whether we want this fix badly enough to
maintain a fork...

This does not exclude your other suggestion, though. I've had a look, and
it seems that it's not easy for several reasons:

   1. The AWS plugin does not work well when you use the same VM image
   ("AMI") in multiple "slave templates", so we would have to create multiple
   AMIs with different IDs but the same content. Annoying, but manageable, I
   suppose.
   2. The AWS plugin always picks a single "slave template", the first one
   matching the required labels, whenever it picks the right slave template
   for a given job [2]. Thus, if we create an additional "instance
   configuration" for release jobs, we will have to put it in first position
   and the plugin will always execute release jobs on that configuration. We
   will never be able to opportunistically use existing, idle instances of the
   "default" slave template for release jobs.
   In short, we'll probably have to spin up a node every time we do a
   release.

I'd say both problems qualify as a bug. I could have a look and submit a
pull request, but I guess the 3 minutes it takes to spin up a node won't
satisfy you, even if it's not for every release so I'm not sure it's worth
the effort?

We can apply some workarounds in the meantime. We could in particular add
throttle the jobs we know should very rarely be triggered. The setting is
located in "Job Notifications > Throttle builds". Setting this to 1 build
per day should mitigate the problem, and it's not as bad as disabling the
job entirely.

[1] The plugin assumes that AMI IDs are unique identifiers of "Slave
templates" in various places, such as
https://github.com/jenkinsci/ec2-plugin/blob/affb7f407cd024accdf4e9093b07efada117814d/src/main/java/hudson/plugins/ec2/EC2Cloud.java#L366
[2]
https://github.com/jenkinsci/ec2-plugin/blob/affb7f407cd024accdf4e9093b07efada117814d/src/main/java/hudson/plugins/ec2/EC2Cloud.java#L545

On Mon, 30 Apr 2018 at 20:54 Davide D'Alto <daltodavide at gmail.com> wrote:

> Using docker might be a nice idea if the machines are powerful enough.
>
> I will just mention it here but for the release only we can also not
> use Jenkins and run the command
> we need from the terminal of ci.hibernate.org. We already have the
> scripts ready so it shouldn't be too hard.
>
> If the Jenkins plugin doesn't work the way we need I don't feel like
> creating our own branch and
> I will consider it only if it's about sending a PR somewhere.
>
> But all this won't solve the problem with SourceForge that seems to be
> the main reason
> we see failures lately.
>
> On Mon, Apr 30, 2018 at 7:42 PM, Guillaume Smet
> <guillaume.smet at gmail.com> wrote:
> > On Mon, Apr 30, 2018 at 8:34 PM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >
> >> Starting a new slave only takes 3 minutes, but I believe it has to be
> >> a "manual start" from its admin dashboard as Jenkins's scaling plugin
> >> is limited.
> >>
> >> Fixing the Jenkins triggers would be my preference.
> >>
> >
> > Yeah, last time we discussed this on HipChat, I have all the useful
> > pointers. The code changes to the official plugin would be minimal. The
> > only thing I'm worried about is how we would maintain this plugin.
> >
> > Alternatively:
> >>  - we could look at pipelines
> >>
> >
> > How would they solve the issue?
> >
> >
> >>  - run all jobs within Docker -> improved isolation would allow us to
> >> run N builds per machine
> >>
> >
> > Would that help? I.e. are the machines we start powerful enough to run
> > several jobs in parallel?
> >
> > I suspect, it wouldn't change the issue, just change the numbers of
> servers
> > we would need (which might be good anyway but is not related to the issue
> > at hand).
> >
> > --
> > 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
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From sanne at hibernate.org  Wed May  2 14:38:36 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 2 May 2018 19:38:36 +0100
Subject: [hibernate-dev] Depending on JAXB / JDK11 compatibility
Message-ID: <CAFm4XO1QJbTZLS=gD1mq85Ujyz2pAAPGX8ZqJDtFb28TWowP1g@mail.gmail.com>

With JAXB being part of the JDK in Java 8, Hibernate ORM doesn't list
it as a runtime dependency.

Java 9 users have been suggested to use the JVM option "--add-modules
java.xml.bind" to avoid the JVM hiding the JAXB library from
classpath.

With Java 11 the java.xml.bind is no longer available; what should we
suggest to users?

Should we list it as an explicit dependency in the released pom files?

Thanks,
Sanne

From christian.beikov at gmail.com  Wed May  2 16:30:30 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 2 May 2018 22:30:30 +0200
Subject: [hibernate-dev] Depending on JAXB / JDK11 compatibility
In-Reply-To: <CAFm4XO1QJbTZLS=gD1mq85Ujyz2pAAPGX8ZqJDtFb28TWowP1g@mail.gmail.com>
References: <CAFm4XO1QJbTZLS=gD1mq85Ujyz2pAAPGX8ZqJDtFb28TWowP1g@mail.gmail.com>
Message-ID: <3db9ade4-3fd0-be2e-337d-0290939e203e@gmail.com>

+1 for listing the API dependency "javax.xml.bind:jaxb-api". Not sure 
about the implementation though, maybe we can use 
"com.sun.xml.bind:jaxb-impl" as an optional dependency?


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 02.05.2018 um 20:38 schrieb Sanne Grinovero:
> With JAXB being part of the JDK in Java 8, Hibernate ORM doesn't list
> it as a runtime dependency.
>
> Java 9 users have been suggested to use the JVM option "--add-modules
> java.xml.bind" to avoid the JVM hiding the JAXB library from
> classpath.
>
> With Java 11 the java.xml.bind is no longer available; what should we
> suggest to users?
>
> Should we list it as an explicit dependency in the released pom files?
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From marko.prykladna at gmail.com  Wed May  2 16:38:15 2018
From: marko.prykladna at gmail.com (Marko Bekhta)
Date: Wed, 2 May 2018 22:38:15 +0200
Subject: [hibernate-dev] Depending on JAXB / JDK11 compatibility
In-Reply-To: <3db9ade4-3fd0-be2e-337d-0290939e203e@gmail.com>
References: <CAFm4XO1QJbTZLS=gD1mq85Ujyz2pAAPGX8ZqJDtFb28TWowP1g@mail.gmail.com>
	<3db9ade4-3fd0-be2e-337d-0290939e203e@gmail.com>
Message-ID: <CACYzyeuVN8j-uEjyaehF6k5vU8goh7fBS4cQvwE25Vk6Lsr8PQ@mail.gmail.com>

Why not move to Stax as we've done in HV? It'll be more consistent this way.

Have a nice day,
Marko

2018-05-02 22:30 GMT+02:00 Christian Beikov <christian.beikov at gmail.com>:

> +1 for listing the API dependency "javax.xml.bind:jaxb-api". Not sure
> about the implementation though, maybe we can use
> "com.sun.xml.bind:jaxb-impl" as an optional dependency?
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 02.05.2018 um 20:38 schrieb Sanne Grinovero:
> > With JAXB being part of the JDK in Java 8, Hibernate ORM doesn't list
> > it as a runtime dependency.
> >
> > Java 9 users have been suggested to use the JVM option "--add-modules
> > java.xml.bind" to avoid the JVM hiding the JAXB library from
> > classpath.
> >
> > With Java 11 the java.xml.bind is no longer available; what should we
> > suggest to users?
> >
> > Should we list it as an explicit dependency in the released pom files?
> >
> > 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  Wed May  2 17:24:22 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 2 May 2018 22:24:22 +0100
Subject: [hibernate-dev] Depending on JAXB / JDK11 compatibility
In-Reply-To: <3db9ade4-3fd0-be2e-337d-0290939e203e@gmail.com>
References: <CAFm4XO1QJbTZLS=gD1mq85Ujyz2pAAPGX8ZqJDtFb28TWowP1g@mail.gmail.com>
	<3db9ade4-3fd0-be2e-337d-0290939e203e@gmail.com>
Message-ID: <CAFm4XO0=1AZX4AaXLAufev5d4E1+813maY2YHc8csW+gL5H_2w@mail.gmail.com>

On 2 May 2018 at 21:30, Christian Beikov <christian.beikov at gmail.com> wrote:
> +1 for listing the API dependency "javax.xml.bind:jaxb-api". Not sure
> about the implementation though, maybe we can use
> "com.sun.xml.bind:jaxb-impl" as an optional dependency?

Hi Christian,

right that's what makes it confusing. We might want to list the
jaxb-api explicitly but it's not enough to make it work: people will
need to know to list several more dependencies.

This is what I've been experimenting with in the Search testsuite
(which uses Hibernate ORM):

<!-- All replacements for JAXB -->
<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>com.sun.xml.bind</groupId>
    <artifactId>jaxb-impl</artifactId>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>com.sun.xml.bind</groupId>
    <artifactId>jaxb-core</artifactId>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>javax.activation</groupId>
    <artifactId>javax.activation-api</artifactId>
    <scope>provided</scope>
</dependency>

I'm afraid that we might as well not list jaxb-api as users need to
understand this all either way.

Thanks,
Sanne


>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 02.05.2018 um 20:38 schrieb Sanne Grinovero:
>> With JAXB being part of the JDK in Java 8, Hibernate ORM doesn't list
>> it as a runtime dependency.
>>
>> Java 9 users have been suggested to use the JVM option "--add-modules
>> java.xml.bind" to avoid the JVM hiding the JAXB library from
>> classpath.
>>
>> With Java 11 the java.xml.bind is no longer available; what should we
>> suggest to users?
>>
>> Should we list it as an explicit dependency in the released pom files?
>>
>> 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  Wed May  2 17:30:06 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 2 May 2018 22:30:06 +0100
Subject: [hibernate-dev] Depending on JAXB / JDK11 compatibility
In-Reply-To: <CACYzyeuVN8j-uEjyaehF6k5vU8goh7fBS4cQvwE25Vk6Lsr8PQ@mail.gmail.com>
References: <CAFm4XO1QJbTZLS=gD1mq85Ujyz2pAAPGX8ZqJDtFb28TWowP1g@mail.gmail.com>
	<3db9ade4-3fd0-be2e-337d-0290939e203e@gmail.com>
	<CACYzyeuVN8j-uEjyaehF6k5vU8goh7fBS4cQvwE25Vk6Lsr8PQ@mail.gmail.com>
Message-ID: <CAFm4XO19CC_z-8n0Ew4e5Db04kWJ4Wi5MomD_qF6nwE1sWGHiw@mail.gmail.com>

On 2 May 2018 at 21:38, Marko Bekhta <marko.prykladna at gmail.com> wrote:
> Why not move to Stax as we've done in HV? It'll be more consistent this way.

+1
that would be my preference, but it's longer term.

It will require quite some more work - especially for Hibernate ORM.

For now I'm wondering if we can be more helpful with the current
versions, especially 5.3 which is about to be released. At very least
I'd like to document the needs but I'm not entirely sure myself if we
should list specific versions (and which ones), it all seems to vary
on the JDK being used.

Thanks,
Sanne


>
> Have a nice day,
> Marko
>
> 2018-05-02 22:30 GMT+02:00 Christian Beikov <christian.beikov at gmail.com>:
>
>> +1 for listing the API dependency "javax.xml.bind:jaxb-api". Not sure
>> about the implementation though, maybe we can use
>> "com.sun.xml.bind:jaxb-impl" as an optional dependency?
>>
>>
>> Mit freundlichen Gr??en,
>> ------------------------------------------------------------------------
>> *Christian Beikov*
>> Am 02.05.2018 um 20:38 schrieb Sanne Grinovero:
>> > With JAXB being part of the JDK in Java 8, Hibernate ORM doesn't list
>> > it as a runtime dependency.
>> >
>> > Java 9 users have been suggested to use the JVM option "--add-modules
>> > java.xml.bind" to avoid the JVM hiding the JAXB library from
>> > classpath.
>> >
>> > With Java 11 the java.xml.bind is no longer available; what should we
>> > suggest to users?
>> >
>> > Should we list it as an explicit dependency in the released pom files?
>> >
>> > 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 guillaume.smet at gmail.com  Wed May  2 17:39:56 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 2 May 2018 23:39:56 +0200
Subject: [hibernate-dev] Depending on JAXB / JDK11 compatibility
In-Reply-To: <CAFm4XO0=1AZX4AaXLAufev5d4E1+813maY2YHc8csW+gL5H_2w@mail.gmail.com>
References: <CAFm4XO1QJbTZLS=gD1mq85Ujyz2pAAPGX8ZqJDtFb28TWowP1g@mail.gmail.com>
	<3db9ade4-3fd0-be2e-337d-0290939e203e@gmail.com>
	<CAFm4XO0=1AZX4AaXLAufev5d4E1+813maY2YHc8csW+gL5H_2w@mail.gmail.com>
Message-ID: <CALt0+o8N0oaOPSStkkrYx4D+H9t1Y+Zzhj6X6SLztAds7GMxjw@mail.gmail.com>

Hi Sanne,

On Wed, May 2, 2018 at 11:24 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:
>
> <!-- All replacements for JAXB -->
> <dependency>
>     <groupId>javax.xml.bind</groupId>
>     <artifactId>jaxb-api</artifactId>
>     <scope>provided</scope>
> </dependency>

<dependency>
>     <groupId>com.sun.xml.bind</groupId>
>     <artifactId>jaxb-impl</artifactId>
>     <scope>test</scope>
> </dependency>
>

Not sure where you got these dependencies.

I think the one we should use is the following:
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
(which comes with quite a few transitive dependencies unfortunately)

JAXB is currently maintained here: https://javaee.github.io/jaxb-v2/.

HTH

-- 
Guillaume

From christian.beikov at gmail.com  Wed May  2 17:40:47 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 2 May 2018 23:40:47 +0200
Subject: [hibernate-dev] Depending on JAXB / JDK11 compatibility
In-Reply-To: <CAFm4XO0=1AZX4AaXLAufev5d4E1+813maY2YHc8csW+gL5H_2w@mail.gmail.com>
References: <CAFm4XO1QJbTZLS=gD1mq85Ujyz2pAAPGX8ZqJDtFb28TWowP1g@mail.gmail.com>
	<3db9ade4-3fd0-be2e-337d-0290939e203e@gmail.com>
	<CAFm4XO0=1AZX4AaXLAufev5d4E1+813maY2YHc8csW+gL5H_2w@mail.gmail.com>
Message-ID: <af8cc09c-929b-5bda-bd86-05f37af0fb36@gmail.com>

You are right that people will have to add some other dependencies if 
they want to use Hibernate on Java 9+, but IMO we should at least put 
the dependencies into the pom.xml that we have a hard dependency on 
which in this case is the jaxb-api or in module descriptor speak the 
"java.xml.bind" module.

People will have to adapt to this and add their own JAXB implementation, 
just like they now use Hibernate as JPA implementation.


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 02.05.2018 um 23:24 schrieb Sanne Grinovero:
> On 2 May 2018 at 21:30, Christian Beikov <christian.beikov at gmail.com> wrote:
>> +1 for listing the API dependency "javax.xml.bind:jaxb-api". Not sure
>> about the implementation though, maybe we can use
>> "com.sun.xml.bind:jaxb-impl" as an optional dependency?
> Hi Christian,
>
> right that's what makes it confusing. We might want to list the
> jaxb-api explicitly but it's not enough to make it work: people will
> need to know to list several more dependencies.
>
> This is what I've been experimenting with in the Search testsuite
> (which uses Hibernate ORM):
>
> <!-- All replacements for JAXB -->
> <dependency>
>      <groupId>javax.xml.bind</groupId>
>      <artifactId>jaxb-api</artifactId>
>      <scope>provided</scope>
> </dependency>
> <dependency>
>      <groupId>com.sun.xml.bind</groupId>
>      <artifactId>jaxb-impl</artifactId>
>      <scope>test</scope>
> </dependency>
> <dependency>
>      <groupId>com.sun.xml.bind</groupId>
>      <artifactId>jaxb-core</artifactId>
>      <scope>test</scope>
> </dependency>
> <dependency>
>      <groupId>javax.activation</groupId>
>      <artifactId>javax.activation-api</artifactId>
>      <scope>provided</scope>
> </dependency>
>
> I'm afraid that we might as well not list jaxb-api as users need to
> understand this all either way.
>
> Thanks,
> Sanne
>
>
>>
>> Mit freundlichen Gr??en,
>> ------------------------------------------------------------------------
>> *Christian Beikov*
>> Am 02.05.2018 um 20:38 schrieb Sanne Grinovero:
>>> With JAXB being part of the JDK in Java 8, Hibernate ORM doesn't list
>>> it as a runtime dependency.
>>>
>>> Java 9 users have been suggested to use the JVM option "--add-modules
>>> java.xml.bind" to avoid the JVM hiding the JAXB library from
>>> classpath.
>>>
>>> With Java 11 the java.xml.bind is no longer available; what should we
>>> suggest to users?
>>>
>>> Should we list it as an explicit dependency in the released pom files?
>>>
>>> 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 guillaume.smet at gmail.com  Wed May  2 17:48:22 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 2 May 2018 23:48:22 +0200
Subject: [hibernate-dev] Depending on JAXB / JDK11 compatibility
In-Reply-To: <af8cc09c-929b-5bda-bd86-05f37af0fb36@gmail.com>
References: <CAFm4XO1QJbTZLS=gD1mq85Ujyz2pAAPGX8ZqJDtFb28TWowP1g@mail.gmail.com>
	<3db9ade4-3fd0-be2e-337d-0290939e203e@gmail.com>
	<CAFm4XO0=1AZX4AaXLAufev5d4E1+813maY2YHc8csW+gL5H_2w@mail.gmail.com>
	<af8cc09c-929b-5bda-bd86-05f37af0fb36@gmail.com>
Message-ID: <CALt0+o_xfrKP3XZW1MTPU+Asx85b1BeoR6MxXXYba57xATo7-g@mail.gmail.com>

On Wed, May 2, 2018 at 11:40 PM, Christian Beikov <
christian.beikov at gmail.com> wrote:

> People will have to adapt to this and add their own JAXB implementation,
> just like they now use Hibernate as JPA implementation.
>

What happens if we add a strong dependency to a JAXB implementation in
addition to the one from the JDK (8)?

-- 
Guillaume

From sanne at hibernate.org  Wed May  2 17:50:58 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 2 May 2018 22:50:58 +0100
Subject: [hibernate-dev] Depending on JAXB / JDK11 compatibility
In-Reply-To: <CALt0+o8N0oaOPSStkkrYx4D+H9t1Y+Zzhj6X6SLztAds7GMxjw@mail.gmail.com>
References: <CAFm4XO1QJbTZLS=gD1mq85Ujyz2pAAPGX8ZqJDtFb28TWowP1g@mail.gmail.com>
	<3db9ade4-3fd0-be2e-337d-0290939e203e@gmail.com>
	<CAFm4XO0=1AZX4AaXLAufev5d4E1+813maY2YHc8csW+gL5H_2w@mail.gmail.com>
	<CALt0+o8N0oaOPSStkkrYx4D+H9t1Y+Zzhj6X6SLztAds7GMxjw@mail.gmail.com>
Message-ID: <CAFm4XO3KXuNYNf61=O46MzmNVH041PC=Bb33cyKaUgV+O8dyCQ@mail.gmail.com>

On 2 May 2018 at 22:39, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi Sanne,
>
> On Wed, May 2, 2018 at 11:24 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> <!-- All replacements for JAXB -->
>> <dependency>
>>     <groupId>javax.xml.bind</groupId>
>>     <artifactId>jaxb-api</artifactId>
>>     <scope>provided</scope>
>> </dependency>
>>
>> <dependency>
>>     <groupId>com.sun.xml.bind</groupId>
>>     <artifactId>jaxb-impl</artifactId>
>>     <scope>test</scope>
>> </dependency>
>
>
> Not sure where you got these dependencies.
>
> I think the one we should use is the following:
> <groupId>org.glassfish.jaxb</groupId>
> <artifactId>jaxb-runtime</artifactId>
> (which comes with quite a few transitive dependencies unfortunately)

The org.glassfish stuff is legacy / deprecated. You should use the
groupId javax.xml.bind now.

Great example of the kind of confusion I'd like to avoid every user to have :)

> JAXB is currently maintained here: https://javaee.github.io/jaxb-v2/.

That's right, and uses "javax.xml.bind" if you check its sources.

>
> HTH
>
> --
> Guillaume

From christian.beikov at gmail.com  Wed May  2 17:55:57 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 2 May 2018 23:55:57 +0200
Subject: [hibernate-dev] Depending on JAXB / JDK11 compatibility
In-Reply-To: <CALt0+o_xfrKP3XZW1MTPU+Asx85b1BeoR6MxXXYba57xATo7-g@mail.gmail.com>
References: <CAFm4XO1QJbTZLS=gD1mq85Ujyz2pAAPGX8ZqJDtFb28TWowP1g@mail.gmail.com>
	<3db9ade4-3fd0-be2e-337d-0290939e203e@gmail.com>
	<CAFm4XO0=1AZX4AaXLAufev5d4E1+813maY2YHc8csW+gL5H_2w@mail.gmail.com>
	<af8cc09c-929b-5bda-bd86-05f37af0fb36@gmail.com>
	<CALt0+o_xfrKP3XZW1MTPU+Asx85b1BeoR6MxXXYba57xATo7-g@mail.gmail.com>
Message-ID: <2f5ce45d-0458-edb0-8794-b8d7fd7a880d@gmail.com>

I actually think since the bootclasspath has precedence over the user 
classpath, nothing will happen. It's just that there is an additional 
JAR that needs to be downloaded.

If it's an implementation with zero further dependencies, it might 
actually be an ok solution to add the dependency, as users could simply 
exclude the dependency if they like without messing up other transitive 
dependencies.


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 02.05.2018 um 23:48 schrieb Guillaume Smet:
> On Wed, May 2, 2018 at 11:40 PM, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     People will have to adapt to this and add their own JAXB
>     implementation,
>     just like they now use Hibernate as JPA implementation.
>
>
> What happens if we add a strong dependency to a JAXB implementation in 
> addition to the one from the JDK (8)?
>
> -- 
> Guillaume
>


From guillaume.smet at gmail.com  Wed May  2 18:07:09 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 3 May 2018 00:07:09 +0200
Subject: [hibernate-dev] Depending on JAXB / JDK11 compatibility
In-Reply-To: <CAFm4XO3KXuNYNf61=O46MzmNVH041PC=Bb33cyKaUgV+O8dyCQ@mail.gmail.com>
References: <CAFm4XO1QJbTZLS=gD1mq85Ujyz2pAAPGX8ZqJDtFb28TWowP1g@mail.gmail.com>
	<3db9ade4-3fd0-be2e-337d-0290939e203e@gmail.com>
	<CAFm4XO0=1AZX4AaXLAufev5d4E1+813maY2YHc8csW+gL5H_2w@mail.gmail.com>
	<CALt0+o8N0oaOPSStkkrYx4D+H9t1Y+Zzhj6X6SLztAds7GMxjw@mail.gmail.com>
	<CAFm4XO3KXuNYNf61=O46MzmNVH041PC=Bb33cyKaUgV+O8dyCQ@mail.gmail.com>
Message-ID: <CALt0+o8swf1+t9P7_gnna+=Xwc9osi7eEQgPDvBJRghztbN3_w@mail.gmail.com>

On Wed, May 2, 2018 at 11:50 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 2 May 2018 at 22:39, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> > Hi Sanne,
> >
> > On Wed, May 2, 2018 at 11:24 PM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> <!-- All replacements for JAXB -->
> >> <dependency>
> >>     <groupId>javax.xml.bind</groupId>
> >>     <artifactId>jaxb-api</artifactId>
> >>     <scope>provided</scope>
> >> </dependency>
> >>
> >> <dependency>
> >>     <groupId>com.sun.xml.bind</groupId>
> >>     <artifactId>jaxb-impl</artifactId>
> >>     <scope>test</scope>
> >> </dependency>
> >
> >
> > Not sure where you got these dependencies.
> >
> > I think the one we should use is the following:
> > <groupId>org.glassfish.jaxb</groupId>
> > <artifactId>jaxb-runtime</artifactId>
> > (which comes with quite a few transitive dependencies unfortunately)
>
> The org.glassfish stuff is legacy / deprecated. You should use the
> groupId javax.xml.bind now.
>

Maybe my quote wasn't clear enough but I was talking about the impl (the
jaxb-impl I quoted), not the API.

See
https://github.com/javaee/jaxb-v2/blob/master/jaxb-ri/runtime/impl/pom.xml .

Great example of the kind of confusion I'd like to avoid every user to have
> :)
>

And to have some fun, take a look at the Maven coordinates of the parent of
the above link :).

> JAXB is currently maintained here: https://javaee.github.io/jaxb-v2/.
>
> That's right, and uses "javax.xml.bind" if you check its sources.
>

For the API, not the runtime/impl.

-- 
Guillaume

From mihalcea.vlad at gmail.com  Thu May  3 03:35:02 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 3 May 2018 10:35:02 +0300
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in 5.3
Message-ID: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>

Hi,

On Discourse, a user told us that the memory footprint has increased
dramatically between 5.2 and 5.3:

https://discourse.hibernate.org/t/batch-fetch-style-recommendations/631/5?u=vlad

I think it's worth investigating the cause and see how we could address it
in the next release.

Vlad

From guillaume.smet at gmail.com  Thu May  3 06:53:12 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 3 May 2018 12:53:12 +0200
Subject: [hibernate-dev] Releases and CI setup
In-Reply-To: <CALt0+o9vioLiLrhpk64F1=7d2=1ujZ=je_LERmAWEGoqdE0Zvw@mail.gmail.com>
References: <CALt0+o9vioLiLrhpk64F1=7d2=1ujZ=je_LERmAWEGoqdE0Zvw@mail.gmail.com>
Message-ID: <CALt0+o93eTEzcsLmwJVu2iT7hK2zxR=a_Wh2-BUA5SXCyZbg=Q@mail.gmail.com>

On Mon, Apr 30, 2018 at 6:09 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> So I would say:
> - either we fix the issue we have with all the branches being tested for
> each commit that we discussed numerous times
>

Here it is:
https://github.com/gsmet/github-plugin/commit/03328fcf8ecd9117d1c8c2a9b967efa111d6be46

Unit tests are OK and I added new ones. We would need to test it in the
wild.

It's not intrusive at all and rather clean (there's a small hack related to
BranchSpec pattern matching but it's due to a bug in an underlying
library). The class GitHubRepositoryBranchSpecContributor that might look a
bit obscure is just an adaptation of the original Jenkins class filtering
on repository name only.

Comments welcome, I would like to test it on our CI at some point.

-- 
Guillaume

From guillaume.smet at gmail.com  Thu May  3 07:01:01 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 3 May 2018 13:01:01 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
Message-ID: <CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>

On Thu, May 3, 2018 at 9:35 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I think it's worth investigating the cause and see how we could address it
> in the next release.
>

Sure, something looks fishy there.

Will you do it or do you expect someone else to do it? It's not very clear
from your email.

-- 
Guillaume

From mihalcea.vlad at gmail.com  Thu May  3 07:17:31 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 3 May 2018 14:17:31 +0300
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
Message-ID: <CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>

I asked because someone might have an idea about some change that was doe
in 5.3 that might affect it.
For the moment, I haven't started doing anything about it.

Vlad

On Thu, May 3, 2018 at 2:01 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> On Thu, May 3, 2018 at 9:35 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> I think it's worth investigating the cause and see how we could address it
>> in the next release.
>>
>
> Sure, something looks fishy there.
>
> Will you do it or do you expect someone else to do it? It's not very clear
> from your email.
>
> --
> Guillaume
>
>

From sanne at hibernate.org  Thu May  3 07:17:34 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 3 May 2018 12:17:34 +0100
Subject: [hibernate-dev] Releases and CI setup
In-Reply-To: <CALt0+o93eTEzcsLmwJVu2iT7hK2zxR=a_Wh2-BUA5SXCyZbg=Q@mail.gmail.com>
References: <CALt0+o9vioLiLrhpk64F1=7d2=1ujZ=je_LERmAWEGoqdE0Zvw@mail.gmail.com>
	<CALt0+o93eTEzcsLmwJVu2iT7hK2zxR=a_Wh2-BUA5SXCyZbg=Q@mail.gmail.com>
Message-ID: <CAFm4XO25PaBV0fojvg-GNGM1ZEAXDO+vb1A2fbbOm+pXUhKU3Q@mail.gmail.com>

Very cool!

Feel free to build it and deploy on ci.hibernate.org ?

On 3 May 2018 at 11:53, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> On Mon, Apr 30, 2018 at 6:09 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> So I would say:
>> - either we fix the issue we have with all the branches being tested for
>> each commit that we discussed numerous times
>>
>
> Here it is:
> https://github.com/gsmet/github-plugin/commit/03328fcf8ecd9117d1c8c2a9b967efa111d6be46
>
> Unit tests are OK and I added new ones. We would need to test it in the
> wild.
>
> It's not intrusive at all and rather clean (there's a small hack related to
> BranchSpec pattern matching but it's due to a bug in an underlying
> library). The class GitHubRepositoryBranchSpecContributor that might look a
> bit obscure is just an adaptation of the original Jenkins class filtering
> on repository name only.
>
> Comments welcome, I would like to test it on our CI at some point.
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From yoann at hibernate.org  Thu May  3 07:18:03 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Thu, 03 May 2018 11:18:03 +0000
Subject: [hibernate-dev] Releases and CI setup
In-Reply-To: <CALt0+o93eTEzcsLmwJVu2iT7hK2zxR=a_Wh2-BUA5SXCyZbg=Q@mail.gmail.com>
References: <CALt0+o9vioLiLrhpk64F1=7d2=1ujZ=je_LERmAWEGoqdE0Zvw@mail.gmail.com>
	<CALt0+o93eTEzcsLmwJVu2iT7hK2zxR=a_Wh2-BUA5SXCyZbg=Q@mail.gmail.com>
Message-ID: <CAEqagpo5Vykwgyf2tmx07qH19BQpAiGTdmONGc25hXK66-op-A@mail.gmail.com>

Great! Thanks a lot :)

I added a few comments, but nothing very important.


On Thu, 3 May 2018 at 12:55 Guillaume Smet <guillaume.smet at gmail.com> wrote:

> On Mon, Apr 30, 2018 at 6:09 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
> > So I would say:
> > - either we fix the issue we have with all the branches being tested for
> > each commit that we discussed numerous times
> >
>
> Here it is:
>
> https://github.com/gsmet/github-plugin/commit/03328fcf8ecd9117d1c8c2a9b967efa111d6be46
>
> Unit tests are OK and I added new ones. We would need to test it in the
> wild.
>
> It's not intrusive at all and rather clean (there's a small hack related to
> BranchSpec pattern matching but it's due to a bug in an underlying
> library). The class GitHubRepositoryBranchSpecContributor that might look a
> bit obscure is just an adaptation of the original Jenkins class filtering
> on repository name only.
>
> Comments welcome, I would like to test it on our CI at some point.
>
> --
> 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 yoann at hibernate.org  Thu May  3 08:17:17 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Thu, 03 May 2018 12:17:17 +0000
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CAFm4XO0HmE60s+ZK=mYc-TbeOmfU5b8LKqvV=5cpdyKjnT6PHw@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
	<CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
	<CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
	<CAEqagpoObS3DvgXkwg0xwu0D20LX4sQRupHc6fMfND2u1O_82Q@mail.gmail.com>
	<CAFm4XO26EK-8qHyXwSMtbp6eYi-hfs7uwPThTBYdpcy4m92tLA@mail.gmail.com>
	<CAEqagpppLa7YhQ63oeQuYSRoPvNSfBWzEdEbAFosmCVWqLWteA@mail.gmail.com>
	<CALt0+o8Z8THJc7cPhnXHquqX-qn4kKHKya7V2902CjYdgk+PyQ@mail.gmail.com>
	<CAFm4XO0HmE60s+ZK=mYc-TbeOmfU5b8LKqvV=5cpdyKjnT6PHw@mail.gmail.com>
Message-ID: <CAEqagpoBX77w56YOZb7x=enQ+FQjQm74zgVGfbhtQbuqNjjmmA@mail.gmail.com>

Since the names are about to be set in stone, and there has been some
discussion off list, I'd like to talk a bit about the Elasticsearch/Lucene
module names...

In the Search 6 architecture, these modules really provide a "backend",
i.e. a component that actually implements indexing/querying over multiple
indexes, but operates "behind" the engine (the engine uses the backend).
Essentially the data flow is:

Indexing: User => Mapper (user APIs) => Engine => Backend => Disk/network
Querying: User <= Mapper (user APIs) <= Engine <= Backend <= Disk/network

We discussed it a bit with Sanne (and with Guillaume) and agreed that
"backend" was the right word for this part of our architecture.

Now, the discussion is about module names, not component names.

Still, there are several reasons because of which I'd rather use
"org.hibernate.search.backend.<elasticsearch/lucene>":

   - It is closer to how we will probably refer to the module on a
   day-to-day basis: I don't know about you, but I'll probably talk about "the
   Elasticsearch backend" rather than "Elasticsearch indexing" or "the
   Elasticsearch module".
   - It is generic enough to cover all of the tasks we delegate to
   Elasticsearch/Lucene.
"org.hibernate.search.indexing.<elasticsearch/lucene>",
   on the other hand, feels like it's only about indexing, and not querying,
   maybe not even about defining a schema.
   - It is consistent with our architecture and APIs in Search 6:
      - The main component (and entry point) in those modules will be an
      object implementing BackendImplementor (SPI)
      - We will actually expose "backends" as part of our Java APIs, for
      instance to allow users to retrieve the Elasticsearch client, or to query
      some backend-scoped metadata.
      - We will also use the word "backend" in the user configuration,
      where the user will have to define a backend, its type and its options
      using the "hibernate.search.backends.<backendName>.*" properties
   - As opposed to the "prefix-less" naming scheme
   ("org.hibernate.search.<elasticsearch/lucene>"), it makes it easy to infer
   what the module actually provides to users: the actual implementation
   behind Hibernate Search, even without extensive knowledge about Hibernate
   Search.
      - When listing all the modules of Hibernate Search, it makes it easy
      to spot which module is about what, and which modules provide the same
      thing using a different technology:

      org.hibernate.search.engine
      org.hibernate.search.orm
      org.hibernate.search.clustering.jms
      org.hibernate.search.clustering.jgroups
      org.hibernate.search.backend.elasticsearch
      org.hibernate.search.backend.lucene

      vs:

      org.hibernate.search.engine
      org.hibernate.search.orm
      org.hibernate.search.jms
      org.hibernate.search.jgroups
      org.hibernate.search.elasticsearch
      org.hibernate.search.lucene
      - When the module name appears in some error message (for instance
      when a user starts experimenting with Java 9), it will also make it clear
      which part of Hibernate Search is misconfigured. And that may be
important
      to some users, since not all the people working on an application
      know the details of every part of the application...


Of course, in the meantime in Search 5, there will be some confusion due to
the fact "backend" has a different meaning in Search 5.

If you are worried about that, I'm not opposed to slightly altering the
module names between Search 5 and Search 6: users will have to make changes
when migrating anyway.
In particular, a lot of APIs will change, some class may be moved to
different packages to comply the "no split package" constraint of Java 9,
Maven coordinates will change to use the "org.hibernate.search" group ID
instead of "org.hibernate", and people using the Lucene backend will have
to depend on a new module (both in their Maven dependencies and in their
Java 9 module dependencies).

So we could just use "org.hibernate.elasticsearch" in Search 5, and switch
to "org.hibernate.backend.elasticsearch" in Search 6. It's not even a big
deal, since the Elastisearch module is openly advertised as experimental.

On Tue, 13 Feb 2018 at 22:51 Sanne Grinovero <sanne at hibernate.org> wrote:

> On 13 February 2018 at 11:48, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
> > On Tue, Feb 13, 2018 at 11:59 AM, Yoann Rodiere <yoann at hibernate.org>
> wrote:
> >>
> >> >   - org.hibernate.search.jms-support
> >>
> >> Not sure it's a valid name (aren't hyphens forbidden in package names,
> and
> >> aren't module names constrained by the same rules?), but apart from that
> >> it
> >> looks good. Maybe "jms_support" instead, if "jms-support" is not
> allowed.
> >> I would like to find a name for what the JMS and JGroups modules provide
> >> in
> >> Hibernate Search 6 though, something less misleading than "backend".
> >> Something like "work routing" or "clustering support" or "distribution
> >> support" or whatever. Would you be ok with changing the module name in
> 6?
> >> If not, maybe we have to think about it now... Note that we'll change
> the
> >> Maven group ID anyway, so it's arguably just another breaking change.
> >
> >
> > +1 to find a distinctive name for JGroups and JMS artifacts and same for
> > Lucene and Elasticsearch (either this round or for 6).
> >
> > org.hibernate.search.clustering.jms
> > org.hibernate.search.clustering.jgroups
> >
> > and
> >
> > org.hibernate.search.indexing.lucene
> > org.hibernate.search.indexing.elasticsearch
> >
> > would be my choice as it's very understandable by the end user.
>
> Great names! I'll take them. These will allow us to gracefully phase
> out the backend terminology, and also suggest the additional
> dependency tree they will pull in.
>
> >
> > It might be an orthogonal discussion so feel free to ignore me :).
> >
> > --
> > 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 guillaume.smet at gmail.com  Thu May  3 08:26:56 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 3 May 2018 14:26:56 +0200
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CAEqagpoBX77w56YOZb7x=enQ+FQjQm74zgVGfbhtQbuqNjjmmA@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
	<CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
	<CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
	<CAEqagpoObS3DvgXkwg0xwu0D20LX4sQRupHc6fMfND2u1O_82Q@mail.gmail.com>
	<CAFm4XO26EK-8qHyXwSMtbp6eYi-hfs7uwPThTBYdpcy4m92tLA@mail.gmail.com>
	<CAEqagpppLa7YhQ63oeQuYSRoPvNSfBWzEdEbAFosmCVWqLWteA@mail.gmail.com>
	<CALt0+o8Z8THJc7cPhnXHquqX-qn4kKHKya7V2902CjYdgk+PyQ@mail.gmail.com>
	<CAFm4XO0HmE60s+ZK=mYc-TbeOmfU5b8LKqvV=5cpdyKjnT6PHw@mail.gmail.com>
	<CAEqagpoBX77w56YOZb7x=enQ+FQjQm74zgVGfbhtQbuqNjjmmA@mail.gmail.com>
Message-ID: <CALt0+o-cnXWs6OnnsohsdvOnQPXC2pWVLoJsVmggMUPjjECVdA@mail.gmail.com>

On Thu, May 3, 2018 at 2:17 PM, Yoann Rodiere <yoann at hibernate.org> wrote:

> Still, there are several reasons because of which I'd rather use
> "org.hibernate.search.backend.<elasticsearch/lucene>":
>
>    - It is closer to how we will probably refer to the module on a
>    day-to-day basis: I don't know about you, but I'll probably talk about "the
>    Elasticsearch backend" rather than "Elasticsearch indexing" or "the
>    Elasticsearch module".
>
>
So, you might remember that I was the one proposing
"indexing.elasticsearch" and this is the main argument that convinced me.


>
>    - It is consistent with our architecture and APIs in Search 6:
>       - The main component (and entry point) in those modules will be an
>       object implementing BackendImplementor (SPI)
>       - We will actually expose "backends" as part of our Java APIs, for
>       instance to allow users to retrieve the Elasticsearch client, or to query
>       some backend-scoped metadata.
>       - We will also use the word "backend" in the user configuration,
>       where the user will have to define a backend, its type and its options
>       using the "hibernate.search.backends.<backendName>.*" properties
>
>
+ this one.

We can use whatever name we want for Search 5 but I think the "backend"
choice is pretty obvious for Search 6.

-- 
Guillaume

From guillaume.smet at gmail.com  Thu May  3 08:47:54 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 3 May 2018 14:47:54 +0200
Subject: [hibernate-dev] Releases and CI setup
In-Reply-To: <CAFm4XO25PaBV0fojvg-GNGM1ZEAXDO+vb1A2fbbOm+pXUhKU3Q@mail.gmail.com>
References: <CALt0+o9vioLiLrhpk64F1=7d2=1ujZ=je_LERmAWEGoqdE0Zvw@mail.gmail.com>
	<CALt0+o93eTEzcsLmwJVu2iT7hK2zxR=a_Wh2-BUA5SXCyZbg=Q@mail.gmail.com>
	<CAFm4XO25PaBV0fojvg-GNGM1ZEAXDO+vb1A2fbbOm+pXUhKU3Q@mail.gmail.com>
Message-ID: <CALt0+o8ebW3VT7i+4kt1i0cqs_gxfYiExcGmNg3EyxM4Fe5xbg@mail.gmail.com>

On Thu, May 3, 2018 at 1:17 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Very cool!
>
> Feel free to build it and deploy on ci.hibernate.org ?
>

I deployed it on ci.hibernate.org just now.

It would be nice if you could check which jobs get triggered when you push
something to master/a specific branch.

-- 
Guillaume

From guillaume.smet at gmail.com  Thu May  3 09:04:09 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 3 May 2018 15:04:09 +0200
Subject: [hibernate-dev] Releases and CI setup
In-Reply-To: <CALt0+o8ebW3VT7i+4kt1i0cqs_gxfYiExcGmNg3EyxM4Fe5xbg@mail.gmail.com>
References: <CALt0+o9vioLiLrhpk64F1=7d2=1ujZ=je_LERmAWEGoqdE0Zvw@mail.gmail.com>
	<CALt0+o93eTEzcsLmwJVu2iT7hK2zxR=a_Wh2-BUA5SXCyZbg=Q@mail.gmail.com>
	<CAFm4XO25PaBV0fojvg-GNGM1ZEAXDO+vb1A2fbbOm+pXUhKU3Q@mail.gmail.com>
	<CALt0+o8ebW3VT7i+4kt1i0cqs_gxfYiExcGmNg3EyxM4Fe5xbg@mail.gmail.com>
Message-ID: <CALt0+o96S82VYe+AsT3m05bGrs4e5DH3YCzjLvLGDkj4hzn6ew@mail.gmail.com>

On Thu, May 3, 2018 at 2:47 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> On Thu, May 3, 2018 at 1:17 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> Very cool!
>>
>> Feel free to build it and deploy on ci.hibernate.org ?
>>
>
> I deployed it on ci.hibernate.org just now.
>
> It would be nice if you could check which jobs get triggered when you push
> something to master/a specific branch.
>

I did a test with HV, deploying something to master and then to 6.0 and it
works as expected \o/.

Please refrain from updating the GitHub plugin (it has a snapshot version
with my login as a suffix).

If you encounter any surprising behavior, feel free to ping me.

-- 
Guillaume

From sanne at hibernate.org  Thu May  3 09:29:27 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 3 May 2018 14:29:27 +0100
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CALt0+o-cnXWs6OnnsohsdvOnQPXC2pWVLoJsVmggMUPjjECVdA@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
	<CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
	<CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
	<CAEqagpoObS3DvgXkwg0xwu0D20LX4sQRupHc6fMfND2u1O_82Q@mail.gmail.com>
	<CAFm4XO26EK-8qHyXwSMtbp6eYi-hfs7uwPThTBYdpcy4m92tLA@mail.gmail.com>
	<CAEqagpppLa7YhQ63oeQuYSRoPvNSfBWzEdEbAFosmCVWqLWteA@mail.gmail.com>
	<CALt0+o8Z8THJc7cPhnXHquqX-qn4kKHKya7V2902CjYdgk+PyQ@mail.gmail.com>
	<CAFm4XO0HmE60s+ZK=mYc-TbeOmfU5b8LKqvV=5cpdyKjnT6PHw@mail.gmail.com>
	<CAEqagpoBX77w56YOZb7x=enQ+FQjQm74zgVGfbhtQbuqNjjmmA@mail.gmail.com>
	<CALt0+o-cnXWs6OnnsohsdvOnQPXC2pWVLoJsVmggMUPjjECVdA@mail.gmail.com>
Message-ID: <CAFm4XO1eGsY5bfk8gJ5j6uyGjST3RcgVwShQ2rjZ2eVCegB9wg@mail.gmail.com>

Ok, I surrender.

so it's going to be `org.hibernate.search.backend.elasticsearch`. Even
if it's not ideal in the context of Hibernate Search 5.x, IMO long
term stability is more important for people.

For the record I still think this tendency to over-qualify things and
add many prefixes should be put under control. I totally understand it
makes sense to "us" but please make an effort to look at how people
use things: for users this is just "the ES stuff", but whatever they
won't care about the prefix anyway :)
Remember this though: when you'll want to include include more than
just the backend bits in this module you will have resistance against
changing the name.

Thanks,
Sanne



On 3 May 2018 at 13:26, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> On Thu, May 3, 2018 at 2:17 PM, Yoann Rodiere <yoann at hibernate.org> wrote:
>>
>> Still, there are several reasons because of which I'd rather use
>> "org.hibernate.search.backend.<elasticsearch/lucene>":
>>
>> It is closer to how we will probably refer to the module on a day-to-day
>> basis: I don't know about you, but I'll probably talk about "the
>> Elasticsearch backend" rather than "Elasticsearch indexing" or "the
>> Elasticsearch module".
>
>
> So, you might remember that I was the one proposing "indexing.elasticsearch"
> and this is the main argument that convinced me.
>
>>
>> It is consistent with our architecture and APIs in Search 6:
>>
>> The main component (and entry point) in those modules will be an object
>> implementing BackendImplementor (SPI)
>> We will actually expose "backends" as part of our Java APIs, for instance
>> to allow users to retrieve the Elasticsearch client, or to query some
>> backend-scoped metadata.
>> We will also use the word "backend" in the user configuration, where the
>> user will have to define a backend, its type and its options using the
>> "hibernate.search.backends.<backendName>.*" properties
>
>
> + this one.
>
> We can use whatever name we want for Search 5 but I think the "backend"
> choice is pretty obvious for Search 6.
>
> --
> Guillaume
>

From sanne at hibernate.org  Thu May  3 09:30:16 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 3 May 2018 14:30:16 +0100
Subject: [hibernate-dev] Releases and CI setup
In-Reply-To: <CALt0+o96S82VYe+AsT3m05bGrs4e5DH3YCzjLvLGDkj4hzn6ew@mail.gmail.com>
References: <CALt0+o9vioLiLrhpk64F1=7d2=1ujZ=je_LERmAWEGoqdE0Zvw@mail.gmail.com>
	<CALt0+o93eTEzcsLmwJVu2iT7hK2zxR=a_Wh2-BUA5SXCyZbg=Q@mail.gmail.com>
	<CAFm4XO25PaBV0fojvg-GNGM1ZEAXDO+vb1A2fbbOm+pXUhKU3Q@mail.gmail.com>
	<CALt0+o8ebW3VT7i+4kt1i0cqs_gxfYiExcGmNg3EyxM4Fe5xbg@mail.gmail.com>
	<CALt0+o96S82VYe+AsT3m05bGrs4e5DH3YCzjLvLGDkj4hzn6ew@mail.gmail.com>
Message-ID: <CAFm4XO11BN+OObKvi0oYMYn83DAS3x5Kx3ay7oCo4K+9V-YDTQ@mail.gmail.com>

Awesome job!

On 3 May 2018 at 14:04, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> On Thu, May 3, 2018 at 2:47 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>>
>> On Thu, May 3, 2018 at 1:17 PM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>>
>>> Very cool!
>>>
>>> Feel free to build it and deploy on ci.hibernate.org ?
>>
>>
>> I deployed it on ci.hibernate.org just now.
>>
>> It would be nice if you could check which jobs get triggered when you push
>> something to master/a specific branch.
>
>
> I did a test with HV, deploying something to master and then to 6.0 and it
> works as expected \o/.
>
> Please refrain from updating the GitHub plugin (it has a snapshot version
> with my login as a suffix).
>
> If you encounter any surprising behavior, feel free to ping me.
>
> --
> Guillaume
>

From gbadner at redhat.com  Thu May  3 13:54:14 2018
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 3 May 2018 10:54:14 -0700
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
Message-ID: <CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>

I just looked at that thread and it's comparing 3.6 to 5.3.CR2...

On Thu, May 3, 2018 at 4:17 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I asked because someone might have an idea about some change that was doe
> in 5.3 that might affect it.
> For the moment, I haven't started doing anything about it.
>
> Vlad
>
> On Thu, May 3, 2018 at 2:01 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
> > On Thu, May 3, 2018 at 9:35 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > wrote:
> >
> >> I think it's worth investigating the cause and see how we could address
> it
> >> in the next release.
> >>
> >
> > Sure, something looks fishy there.
> >
> > Will you do it or do you expect someone else to do it? It's not very
> clear
> > from your email.
> >
> > --
> > Guillaume
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Thu May  3 13:58:25 2018
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 3 May 2018 10:58:25 -0700
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
Message-ID: <CAFDzhiR7_Lh974TtNgYpPZWLAZ6z+h7hBo4H_D1Uq7G_dUMKeg@mail.gmail.com>

FYI, those batch loaders were updated to use "load plans" in 4.3. I suspect
that might have something to do with it.

Please let me know if I should look into this.

On Thu, May 3, 2018 at 10:54 AM, Gail Badner <gbadner at redhat.com> wrote:

> I just looked at that thread and it's comparing 3.6 to 5.3.CR2...
>
> On Thu, May 3, 2018 at 4:17 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> I asked because someone might have an idea about some change that was doe
>> in 5.3 that might affect it.
>> For the moment, I haven't started doing anything about it.
>>
>> Vlad
>>
>> On Thu, May 3, 2018 at 2:01 PM, Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>>
>> > On Thu, May 3, 2018 at 9:35 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> > wrote:
>> >
>> >> I think it's worth investigating the cause and see how we could
>> address it
>> >> in the next release.
>> >>
>> >
>> > Sure, something looks fishy there.
>> >
>> > Will you do it or do you expect someone else to do it? It's not very
>> clear
>> > from your email.
>> >
>> > --
>> > Guillaume
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Thu May  3 13:59:24 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 03 May 2018 17:59:24 +0000
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
Message-ID: <CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>

Yeah, we have been having a chat about this on HipChat

On Thu, May 3, 2018 at 12:54 PM Gail Badner <gbadner at redhat.com> wrote:

> I just looked at that thread and it's comparing 3.6 to 5.3.CR2...
>
> On Thu, May 3, 2018 at 4:17 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
> > I asked because someone might have an idea about some change that was doe
> > in 5.3 that might affect it.
> > For the moment, I haven't started doing anything about it.
> >
> > Vlad
> >
> > On Thu, May 3, 2018 at 2:01 PM, Guillaume Smet <guillaume.smet at gmail.com
> >
> > wrote:
> >
> > > On Thu, May 3, 2018 at 9:35 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com
> >
> > > wrote:
> > >
> > >> I think it's worth investigating the cause and see how we could
> address
> > it
> > >> in the next release.
> > >>
> > >
> > > Sure, something looks fishy there.
> > >
> > > Will you do it or do you expect someone else to do it? It's not very
> > clear
> > > from your email.
> > >
> > > --
> > > 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 gbadner at redhat.com  Thu May  3 14:33:57 2018
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 3 May 2018 11:33:57 -0700
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
Message-ID: <CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>

OK, let me know if I should jump in...

On Thu, May 3, 2018 at 10:59 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Yeah, we have been having a chat about this on HipChat
>
> On Thu, May 3, 2018 at 12:54 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> I just looked at that thread and it's comparing 3.6 to 5.3.CR2...
>>
>> On Thu, May 3, 2018 at 4:17 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>> > I asked because someone might have an idea about some change that was
>> doe
>> > in 5.3 that might affect it.
>> > For the moment, I haven't started doing anything about it.
>> >
>> > Vlad
>> >
>> > On Thu, May 3, 2018 at 2:01 PM, Guillaume Smet <
>> guillaume.smet at gmail.com>
>> > wrote:
>> >
>> > > On Thu, May 3, 2018 at 9:35 AM, Vlad Mihalcea <
>> mihalcea.vlad at gmail.com>
>> > > wrote:
>> > >
>> > >> I think it's worth investigating the cause and see how we could
>> address
>> > it
>> > >> in the next release.
>> > >>
>> > >
>> > > Sure, something looks fishy there.
>> > >
>> > > Will you do it or do you expect someone else to do it? It's not very
>> > clear
>> > > from your email.
>> > >
>> > > --
>> > > 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 sanne at hibernate.org  Thu May  3 14:57:06 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 3 May 2018 19:57:06 +0100
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
Message-ID: <CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>

On 3 May 2018 at 19:33, Gail Badner <gbadner at redhat.com> wrote:
> OK, let me know if I should jump in...

Thanks Gail, I think you can relax for now :)
 - knowing that 4.3 introduced the load plans explains a good deal of
the difference
 - Guillaume is checking details too
 - the Red Hat performance team is going to check general allocation
with the usual benchmarks (not specifically this issue, but still
reassuring enough)

>
> On Thu, May 3, 2018 at 10:59 AM, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Yeah, we have been having a chat about this on HipChat
>>
>> On Thu, May 3, 2018 at 12:54 PM Gail Badner <gbadner at redhat.com> wrote:
>>
>>> I just looked at that thread and it's comparing 3.6 to 5.3.CR2...
>>>
>>> On Thu, May 3, 2018 at 4:17 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>> > I asked because someone might have an idea about some change that was
>>> doe
>>> > in 5.3 that might affect it.
>>> > For the moment, I haven't started doing anything about it.
>>> >
>>> > Vlad
>>> >
>>> > On Thu, May 3, 2018 at 2:01 PM, Guillaume Smet <
>>> guillaume.smet at gmail.com>
>>> > wrote:
>>> >
>>> > > On Thu, May 3, 2018 at 9:35 AM, Vlad Mihalcea <
>>> mihalcea.vlad at gmail.com>
>>> > > wrote:
>>> > >
>>> > >> I think it's worth investigating the cause and see how we could
>>> address
>>> > it
>>> > >> in the next release.
>>> > >>
>>> > >
>>> > > Sure, something looks fishy there.
>>> > >
>>> > > Will you do it or do you expect someone else to do it? It's not very
>>> > clear
>>> > > from your email.
>>> > >
>>> > > --
>>> > > 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
>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Fri May  4 05:06:26 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 4 May 2018 11:06:26 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
Message-ID: <CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>

Hi,

So, I analyzed the dumps yesterday evening. The problem is real, meaning
his SessionFactory is consuming more than 1GB of memory for 600+ tables,
some with a lot of attributes. So for sure, the model is a big one, but it
would be nice to be more gentle with this type of configuration. I don't
think it's something new to 5.3 though as it's not the first time we have
this type of reports.

>From my observations, the problem mostly comes from:
LegacyBatchingEntityLoader
 \_ loaders - EntityLoader
     \_ staticLoadQuery - EntityLoadQueryDetails
         \_ rootReturn - EntityReturnImpl

The largest LegacyBatchingEntityLoader I have in the dump takes more than 2
MB.

Keep in mind that with a batch size of 50, we have 13 EntityLoaders for
batch sizes of 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 20 and 50, each loader
taking ~ 200 KB.

We discussed some ideas yesterday with Steve.

I'll try to experiment a few ideas next week to see if I can come up with
some mitigation. I'm not that familiar with the ORM source code so I'm full
of crazy ideas to try - most of them will probably prove to be bad (Steve
already shut some of them) but maybe one will survive and be beneficial to
the problem at hand.

I'll keep you posted if I can come up with something.

-- 
Guillaume

From sanne at hibernate.org  Fri May  4 05:48:57 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 4 May 2018 10:48:57 +0100
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
Message-ID: <CAFm4XO1vfkAEW4V=EhT2hLUA7=A_e7cqGG3BNVGT-DwXgYXUAw@mail.gmail.com>

Hi Guillaume,

thanks for investigating. Steve in chat mentioned the option of
creating these EntityLoaders lazily: as while they need to be reused,
it's possible many of them are never really used.

I think that's a very interesting observation, is that what you plan to explore?

I see two difficulties:
 - you'd need thredsafe code, yet we don't want barriers on this area.
Will probably need features such as lazy set, yet these would need
even more objects allocated if you're not careful.
 - we always prefer fail-at-boot validation, so we'd need to make sure
even if you don't build them all, we can at least make sure we'll be
able to build them later.

It's worth remembering that the JVM can actually optimise ORM quite
well as there are not many memory barriers in the most complex areas.

Additionally there's the idea to see if any such Loader instance could
be reused - probably using a cache which we clear at end of bootstrap
- yet since Steve mentioned this would be a significant change let's
not try to push it in 5.3.

Finally, a simple one: I have the impression that loader's Map could
be made into a plain array, or a custom structure which would then be
ideal to support lazy creation of loaders. With the exception of two
special strings - which will needt to be treated specially - all other
keys are enums.

Whatever you choose to try, let's keep significant changes for 6 only :)

Thanks,
Sanne



On 4 May 2018 at 10:06, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi,
>
> So, I analyzed the dumps yesterday evening. The problem is real, meaning his
> SessionFactory is consuming more than 1GB of memory for 600+ tables, some
> with a lot of attributes. So for sure, the model is a big one, but it would
> be nice to be more gentle with this type of configuration. I don't think
> it's something new to 5.3 though as it's not the first time we have this
> type of reports.
>
> From my observations, the problem mostly comes from:
> LegacyBatchingEntityLoader
>  \_ loaders - EntityLoader
>      \_ staticLoadQuery - EntityLoadQueryDetails
>          \_ rootReturn - EntityReturnImpl
>
> The largest LegacyBatchingEntityLoader I have in the dump takes more than 2
> MB.
>
> Keep in mind that with a batch size of 50, we have 13 EntityLoaders for
> batch sizes of 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 20 and 50, each loader
> taking ~ 200 KB.
>
> We discussed some ideas yesterday with Steve.
>
> I'll try to experiment a few ideas next week to see if I can come up with
> some mitigation. I'm not that familiar with the ORM source code so I'm full
> of crazy ideas to try - most of them will probably prove to be bad (Steve
> already shut some of them) but maybe one will survive and be beneficial to
> the problem at hand.
>
> I'll keep you posted if I can come up with something.
>
> --
> Guillaume
>

From guillaume.smet at gmail.com  Fri May  4 08:41:21 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 4 May 2018 14:41:21 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAFm4XO1vfkAEW4V=EhT2hLUA7=A_e7cqGG3BNVGT-DwXgYXUAw@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<CAFm4XO1vfkAEW4V=EhT2hLUA7=A_e7cqGG3BNVGT-DwXgYXUAw@mail.gmail.com>
Message-ID: <CALt0+o9AmqJqw_VUmy+Hr8xkLCzWfRdXDpv7DUu_+WkW1KpCoQ@mail.gmail.com>

On Fri, May 4, 2018 at 11:48 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> thanks for investigating. Steve in chat mentioned the option of
> creating these EntityLoaders lazily: as while they need to be reused,
> it's possible many of them are never really used.
>
> I think that's a very interesting observation, is that what you plan to
> explore?
>

Yes, it's one of the things we should explore.


> I see two difficulties:
>  - you'd need thredsafe code, yet we don't want barriers on this area.
> Will probably need features such as lazy set, yet these would need
> even more objects allocated if you're not careful.
>  - we always prefer fail-at-boot validation, so we'd need to make sure
> even if you don't build them all, we can at least make sure we'll be
> able to build them later.
>

Well, the idea is to prototype something on the memory usage front, then we
can discuss further what we want to do with it and if it's worth refining
it and spending more time on it.

If we end up choosing this path, be sure we'll be bugging you for advice on
concurrency and performance :).


> Additionally there's the idea to see if any such Loader instance could
> be reused - probably using a cache which we clear at end of bootstrap
> - yet since Steve mentioned this would be a significant change let's
> not try to push it in 5.3.
>
> Finally, a simple one: I have the impression that loader's Map could
> be made into a plain array, or a custom structure which would then be
> ideal to support lazy creation of loaders. With the exception of two
> special strings - which will needt to be treated specially - all other
> keys are enums.
>

Yeah, I'll play with a few ideas and see what I can do. I'm not yet sure if
not knowing the code base will be a thing in my favor or not. At least I
don't have preconceived ideas :].


> Whatever you choose to try, let's keep significant changes for 6 only :)
>

Steve was saying that this whole thing wouldn't be an issue in 6.

-- 
Guillaume

From gbadner at redhat.com  Fri May  4 14:45:49 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 4 May 2018 11:45:49 -0700
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CALt0+o9AmqJqw_VUmy+Hr8xkLCzWfRdXDpv7DUu_+WkW1KpCoQ@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<CAFm4XO1vfkAEW4V=EhT2hLUA7=A_e7cqGG3BNVGT-DwXgYXUAw@mail.gmail.com>
	<CALt0+o9AmqJqw_VUmy+Hr8xkLCzWfRdXDpv7DUu_+WkW1KpCoQ@mail.gmail.com>
Message-ID: <CAFDzhiQ1WbhoL_UADba-cfsk3pUkiypK46Q8Xi6bm65vPMXXmg@mail.gmail.com>

I don't think the batching strategies actually changed when we moved to
load plans.

Is the problem that each loader is taking considerably more memory?

On Fri, May 4, 2018 at 5:41 AM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> On Fri, May 4, 2018 at 11:48 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > thanks for investigating. Steve in chat mentioned the option of
> > creating these EntityLoaders lazily: as while they need to be reused,
> > it's possible many of them are never really used.
> >
> > I think that's a very interesting observation, is that what you plan to
> > explore?
> >
>
> Yes, it's one of the things we should explore.
>
>
> > I see two difficulties:
> >  - you'd need thredsafe code, yet we don't want barriers on this area.
> > Will probably need features such as lazy set, yet these would need
> > even more objects allocated if you're not careful.
> >  - we always prefer fail-at-boot validation, so we'd need to make sure
> > even if you don't build them all, we can at least make sure we'll be
> > able to build them later.
> >
>
> Well, the idea is to prototype something on the memory usage front, then we
> can discuss further what we want to do with it and if it's worth refining
> it and spending more time on it.
>
> If we end up choosing this path, be sure we'll be bugging you for advice on
> concurrency and performance :).
>
>
> > Additionally there's the idea to see if any such Loader instance could
> > be reused - probably using a cache which we clear at end of bootstrap
> > - yet since Steve mentioned this would be a significant change let's
> > not try to push it in 5.3.
> >
> > Finally, a simple one: I have the impression that loader's Map could
> > be made into a plain array, or a custom structure which would then be
> > ideal to support lazy creation of loaders. With the exception of two
> > special strings - which will needt to be treated specially - all other
> > keys are enums.
> >
>
> Yeah, I'll play with a few ideas and see what I can do. I'm not yet sure if
> not knowing the code base will be a thing in my favor or not. At least I
> don't have preconceived ideas :].
>
>
> > Whatever you choose to try, let's keep significant changes for 6 only :)
> >
>
> Steve was saying that this whole thing wouldn't be an issue in 6.
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri May  4 15:15:57 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 4 May 2018 20:15:57 +0100
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAFDzhiQ1WbhoL_UADba-cfsk3pUkiypK46Q8Xi6bm65vPMXXmg@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<CAFm4XO1vfkAEW4V=EhT2hLUA7=A_e7cqGG3BNVGT-DwXgYXUAw@mail.gmail.com>
	<CALt0+o9AmqJqw_VUmy+Hr8xkLCzWfRdXDpv7DUu_+WkW1KpCoQ@mail.gmail.com>
	<CAFDzhiQ1WbhoL_UADba-cfsk3pUkiypK46Q8Xi6bm65vPMXXmg@mail.gmail.com>
Message-ID: <CAFm4XO1uU3AfdBo9W_--7BuH4zZQA8W8s1RXbZdiCAvs6aRW-w@mail.gmail.com>

On 4 May 2018 at 19:45, Gail Badner <gbadner at redhat.com> wrote:
> I don't think the batching strategies actually changed when we moved to load
> plans.
>
> Is the problem that each loader is taking considerably more memory?

Yes that's right.

>
> On Fri, May 4, 2018 at 5:41 AM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>>
>> On Fri, May 4, 2018 at 11:48 AM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>> > thanks for investigating. Steve in chat mentioned the option of
>> > creating these EntityLoaders lazily: as while they need to be reused,
>> > it's possible many of them are never really used.
>> >
>> > I think that's a very interesting observation, is that what you plan to
>> > explore?
>> >
>>
>> Yes, it's one of the things we should explore.
>>
>>
>> > I see two difficulties:
>> >  - you'd need thredsafe code, yet we don't want barriers on this area.
>> > Will probably need features such as lazy set, yet these would need
>> > even more objects allocated if you're not careful.
>> >  - we always prefer fail-at-boot validation, so we'd need to make sure
>> > even if you don't build them all, we can at least make sure we'll be
>> > able to build them later.
>> >
>>
>> Well, the idea is to prototype something on the memory usage front, then
>> we
>> can discuss further what we want to do with it and if it's worth refining
>> it and spending more time on it.
>>
>> If we end up choosing this path, be sure we'll be bugging you for advice
>> on
>> concurrency and performance :).
>>
>>
>> > Additionally there's the idea to see if any such Loader instance could
>> > be reused - probably using a cache which we clear at end of bootstrap
>> > - yet since Steve mentioned this would be a significant change let's
>> > not try to push it in 5.3.
>> >
>> > Finally, a simple one: I have the impression that loader's Map could
>> > be made into a plain array, or a custom structure which would then be
>> > ideal to support lazy creation of loaders. With the exception of two
>> > special strings - which will needt to be treated specially - all other
>> > keys are enums.
>> >
>>
>> Yeah, I'll play with a few ideas and see what I can do. I'm not yet sure
>> if
>> not knowing the code base will be a thing in my favor or not. At least I
>> don't have preconceived ideas :].
>>
>>
>> > Whatever you choose to try, let's keep significant changes for 6 only :)
>> >
>>
>> Steve was saying that this whole thing wouldn't be an issue in 6.
>>
>> --
>> 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  Fri May  4 15:30:26 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 4 May 2018 21:30:26 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAFm4XO1uU3AfdBo9W_--7BuH4zZQA8W8s1RXbZdiCAvs6aRW-w@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<CAFm4XO1vfkAEW4V=EhT2hLUA7=A_e7cqGG3BNVGT-DwXgYXUAw@mail.gmail.com>
	<CALt0+o9AmqJqw_VUmy+Hr8xkLCzWfRdXDpv7DUu_+WkW1KpCoQ@mail.gmail.com>
	<CAFDzhiQ1WbhoL_UADba-cfsk3pUkiypK46Q8Xi6bm65vPMXXmg@mail.gmail.com>
	<CAFm4XO1uU3AfdBo9W_--7BuH4zZQA8W8s1RXbZdiCAvs6aRW-w@mail.gmail.com>
Message-ID: <CALt0+o-gV8Wv47OtNyLRNjf5i1v77zv8qdittdNrf2YW1=JWKQ@mail.gmail.com>

Don't know about the history but with the entity I checked out in the OP's
case, each EntityLoader is approximately 200 KB.

The entity contains a lot of columns so that's no surprise.

What doesn't help is that I don't think the 13 EntityLoaders/entity share a
lot of things so they are just adding up.

On Fri, May 4, 2018 at 9:15 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> On 4 May 2018 at 19:45, Gail Badner <gbadner at redhat.com> wrote:
> > I don't think the batching strategies actually changed when we moved to
> load
> > plans.
> >
> > Is the problem that each loader is taking considerably more memory?
>
> Yes that's right.
>
> >
> > On Fri, May 4, 2018 at 5:41 AM, Guillaume Smet <guillaume.smet at gmail.com
> >
> > wrote:
> >>
> >> On Fri, May 4, 2018 at 11:48 AM, Sanne Grinovero <sanne at hibernate.org>
> >> wrote:
> >>
> >> > thanks for investigating. Steve in chat mentioned the option of
> >> > creating these EntityLoaders lazily: as while they need to be reused,
> >> > it's possible many of them are never really used.
> >> >
> >> > I think that's a very interesting observation, is that what you plan
> to
> >> > explore?
> >> >
> >>
> >> Yes, it's one of the things we should explore.
> >>
> >>
> >> > I see two difficulties:
> >> >  - you'd need thredsafe code, yet we don't want barriers on this area.
> >> > Will probably need features such as lazy set, yet these would need
> >> > even more objects allocated if you're not careful.
> >> >  - we always prefer fail-at-boot validation, so we'd need to make sure
> >> > even if you don't build them all, we can at least make sure we'll be
> >> > able to build them later.
> >> >
> >>
> >> Well, the idea is to prototype something on the memory usage front, then
> >> we
> >> can discuss further what we want to do with it and if it's worth
> refining
> >> it and spending more time on it.
> >>
> >> If we end up choosing this path, be sure we'll be bugging you for advice
> >> on
> >> concurrency and performance :).
> >>
> >>
> >> > Additionally there's the idea to see if any such Loader instance could
> >> > be reused - probably using a cache which we clear at end of bootstrap
> >> > - yet since Steve mentioned this would be a significant change let's
> >> > not try to push it in 5.3.
> >> >
> >> > Finally, a simple one: I have the impression that loader's Map could
> >> > be made into a plain array, or a custom structure which would then be
> >> > ideal to support lazy creation of loaders. With the exception of two
> >> > special strings - which will needt to be treated specially - all other
> >> > keys are enums.
> >> >
> >>
> >> Yeah, I'll play with a few ideas and see what I can do. I'm not yet sure
> >> if
> >> not knowing the code base will be a thing in my favor or not. At least I
> >> don't have preconceived ideas :].
> >>
> >>
> >> > Whatever you choose to try, let's keep significant changes for 6 only
> :)
> >> >
> >>
> >> Steve was saying that this whole thing wouldn't be an issue in 6.
> >>
> >> --
> >> 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 gbadner at redhat.com  Fri May  4 16:31:15 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 4 May 2018 13:31:15 -0700
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CALt0+o-gV8Wv47OtNyLRNjf5i1v77zv8qdittdNrf2YW1=JWKQ@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<CAFm4XO1vfkAEW4V=EhT2hLUA7=A_e7cqGG3BNVGT-DwXgYXUAw@mail.gmail.com>
	<CALt0+o9AmqJqw_VUmy+Hr8xkLCzWfRdXDpv7DUu_+WkW1KpCoQ@mail.gmail.com>
	<CAFDzhiQ1WbhoL_UADba-cfsk3pUkiypK46Q8Xi6bm65vPMXXmg@mail.gmail.com>
	<CAFm4XO1uU3AfdBo9W_--7BuH4zZQA8W8s1RXbZdiCAvs6aRW-w@mail.gmail.com>
	<CALt0+o-gV8Wv47OtNyLRNjf5i1v77zv8qdittdNrf2YW1=JWKQ@mail.gmail.com>
Message-ID: <CAFDzhiTfdnzSpAWJM1FH475jTP6BgF718x014Qn+0ebENf-VYA@mail.gmail.com>

I *think* that most, if not all, of the loaders for a particular entity
could be reworked to share most of the same information.

IIRC, the only real differences are the batch size and the actual query
that gets generated.

I'm happy to look into this, but I don't want to duplicate what others are
doing. It a bit difficult collaborating on this since our time zones don't
overlap very well (and, unfortunately, I'm not a morning person).

I have some other work I need to attend to today. Please let me know if I
should dig into this next week.

On Fri, May 4, 2018 at 12:30 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Don't know about the history but with the entity I checked out in the OP's
> case, each EntityLoader is approximately 200 KB.
>
> The entity contains a lot of columns so that's no surprise.
>
> What doesn't help is that I don't think the 13 EntityLoaders/entity share
> a lot of things so they are just adding up.
>
> On Fri, May 4, 2018 at 9:15 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 4 May 2018 at 19:45, Gail Badner <gbadner at redhat.com> wrote:
>> > I don't think the batching strategies actually changed when we moved to
>> load
>> > plans.
>> >
>> > Is the problem that each loader is taking considerably more memory?
>>
>> Yes that's right.
>>
>> >
>> > On Fri, May 4, 2018 at 5:41 AM, Guillaume Smet <
>> guillaume.smet at gmail.com>
>> > wrote:
>> >>
>> >> On Fri, May 4, 2018 at 11:48 AM, Sanne Grinovero <sanne at hibernate.org>
>> >> wrote:
>> >>
>> >> > thanks for investigating. Steve in chat mentioned the option of
>> >> > creating these EntityLoaders lazily: as while they need to be reused,
>> >> > it's possible many of them are never really used.
>> >> >
>> >> > I think that's a very interesting observation, is that what you plan
>> to
>> >> > explore?
>> >> >
>> >>
>> >> Yes, it's one of the things we should explore.
>> >>
>> >>
>> >> > I see two difficulties:
>> >> >  - you'd need thredsafe code, yet we don't want barriers on this
>> area.
>> >> > Will probably need features such as lazy set, yet these would need
>> >> > even more objects allocated if you're not careful.
>> >> >  - we always prefer fail-at-boot validation, so we'd need to make
>> sure
>> >> > even if you don't build them all, we can at least make sure we'll be
>> >> > able to build them later.
>> >> >
>> >>
>> >> Well, the idea is to prototype something on the memory usage front,
>> then
>> >> we
>> >> can discuss further what we want to do with it and if it's worth
>> refining
>> >> it and spending more time on it.
>> >>
>> >> If we end up choosing this path, be sure we'll be bugging you for
>> advice
>> >> on
>> >> concurrency and performance :).
>> >>
>> >>
>> >> > Additionally there's the idea to see if any such Loader instance
>> could
>> >> > be reused - probably using a cache which we clear at end of bootstrap
>> >> > - yet since Steve mentioned this would be a significant change let's
>> >> > not try to push it in 5.3.
>> >> >
>> >> > Finally, a simple one: I have the impression that loader's Map could
>> >> > be made into a plain array, or a custom structure which would then be
>> >> > ideal to support lazy creation of loaders. With the exception of two
>> >> > special strings - which will needt to be treated specially - all
>> other
>> >> > keys are enums.
>> >> >
>> >>
>> >> Yeah, I'll play with a few ideas and see what I can do. I'm not yet
>> sure
>> >> if
>> >> not knowing the code base will be a thing in my favor or not. At least
>> I
>> >> don't have preconceived ideas :].
>> >>
>> >>
>> >> > Whatever you choose to try, let's keep significant changes for 6
>> only :)
>> >> >
>> >>
>> >> Steve was saying that this whole thing wouldn't be an issue in 6.
>> >>
>> >> --
>> >> 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 guillaume.smet at gmail.com  Fri May  4 16:37:15 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 4 May 2018 22:37:15 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAFDzhiTfdnzSpAWJM1FH475jTP6BgF718x014Qn+0ebENf-VYA@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<CAFm4XO1vfkAEW4V=EhT2hLUA7=A_e7cqGG3BNVGT-DwXgYXUAw@mail.gmail.com>
	<CALt0+o9AmqJqw_VUmy+Hr8xkLCzWfRdXDpv7DUu_+WkW1KpCoQ@mail.gmail.com>
	<CAFDzhiQ1WbhoL_UADba-cfsk3pUkiypK46Q8Xi6bm65vPMXXmg@mail.gmail.com>
	<CAFm4XO1uU3AfdBo9W_--7BuH4zZQA8W8s1RXbZdiCAvs6aRW-w@mail.gmail.com>
	<CALt0+o-gV8Wv47OtNyLRNjf5i1v77zv8qdittdNrf2YW1=JWKQ@mail.gmail.com>
	<CAFDzhiTfdnzSpAWJM1FH475jTP6BgF718x014Qn+0ebENf-VYA@mail.gmail.com>
Message-ID: <CALt0+o-mskxXXiXP9NyCG-idPtPDStp1UbY3ACt+p9YgcbCUrA@mail.gmail.com>

As already mentioned, I plan to take a look at this next week.

I also thought we could share most of the info between loaders but Steve
was thinking it might not be possible without massive changes.

I'll take a look and report back to all of you. I might be way over my head
as I don't know the codebase very well but I already did a very similar
work for HV with great results so it's worth a shot.

-- 
Guillaume

On Fri, May 4, 2018 at 10:31 PM, Gail Badner <gbadner at redhat.com> wrote:

> I *think* that most, if not all, of the loaders for a particular entity
> could be reworked to share most of the same information.
>
> IIRC, the only real differences are the batch size and the actual query
> that gets generated.
>
> I'm happy to look into this, but I don't want to duplicate what others are
> doing. It a bit difficult collaborating on this since our time zones don't
> overlap very well (and, unfortunately, I'm not a morning person).
>
> I have some other work I need to attend to today. Please let me know if I
> should dig into this next week.
>
> On Fri, May 4, 2018 at 12:30 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> Don't know about the history but with the entity I checked out in the
>> OP's case, each EntityLoader is approximately 200 KB.
>>
>> The entity contains a lot of columns so that's no surprise.
>>
>> What doesn't help is that I don't think the 13 EntityLoaders/entity share
>> a lot of things so they are just adding up.
>>
>> On Fri, May 4, 2018 at 9:15 PM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>>> On 4 May 2018 at 19:45, Gail Badner <gbadner at redhat.com> wrote:
>>> > I don't think the batching strategies actually changed when we moved
>>> to load
>>> > plans.
>>> >
>>> > Is the problem that each loader is taking considerably more memory?
>>>
>>> Yes that's right.
>>>
>>> >
>>> > On Fri, May 4, 2018 at 5:41 AM, Guillaume Smet <
>>> guillaume.smet at gmail.com>
>>> > wrote:
>>> >>
>>> >> On Fri, May 4, 2018 at 11:48 AM, Sanne Grinovero <sanne at hibernate.org
>>> >
>>> >> wrote:
>>> >>
>>> >> > thanks for investigating. Steve in chat mentioned the option of
>>> >> > creating these EntityLoaders lazily: as while they need to be
>>> reused,
>>> >> > it's possible many of them are never really used.
>>> >> >
>>> >> > I think that's a very interesting observation, is that what you
>>> plan to
>>> >> > explore?
>>> >> >
>>> >>
>>> >> Yes, it's one of the things we should explore.
>>> >>
>>> >>
>>> >> > I see two difficulties:
>>> >> >  - you'd need thredsafe code, yet we don't want barriers on this
>>> area.
>>> >> > Will probably need features such as lazy set, yet these would need
>>> >> > even more objects allocated if you're not careful.
>>> >> >  - we always prefer fail-at-boot validation, so we'd need to make
>>> sure
>>> >> > even if you don't build them all, we can at least make sure we'll be
>>> >> > able to build them later.
>>> >> >
>>> >>
>>> >> Well, the idea is to prototype something on the memory usage front,
>>> then
>>> >> we
>>> >> can discuss further what we want to do with it and if it's worth
>>> refining
>>> >> it and spending more time on it.
>>> >>
>>> >> If we end up choosing this path, be sure we'll be bugging you for
>>> advice
>>> >> on
>>> >> concurrency and performance :).
>>> >>
>>> >>
>>> >> > Additionally there's the idea to see if any such Loader instance
>>> could
>>> >> > be reused - probably using a cache which we clear at end of
>>> bootstrap
>>> >> > - yet since Steve mentioned this would be a significant change let's
>>> >> > not try to push it in 5.3.
>>> >> >
>>> >> > Finally, a simple one: I have the impression that loader's Map could
>>> >> > be made into a plain array, or a custom structure which would then
>>> be
>>> >> > ideal to support lazy creation of loaders. With the exception of two
>>> >> > special strings - which will needt to be treated specially - all
>>> other
>>> >> > keys are enums.
>>> >> >
>>> >>
>>> >> Yeah, I'll play with a few ideas and see what I can do. I'm not yet
>>> sure
>>> >> if
>>> >> not knowing the code base will be a thing in my favor or not. At
>>> least I
>>> >> don't have preconceived ideas :].
>>> >>
>>> >>
>>> >> > Whatever you choose to try, let's keep significant changes for 6
>>> only :)
>>> >> >
>>> >>
>>> >> Steve was saying that this whole thing wouldn't be an issue in 6.
>>> >>
>>> >> --
>>> >> 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 guillaume.smet at gmail.com  Fri May  4 16:40:52 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 4 May 2018 22:40:52 +0200
Subject: [hibernate-dev] Small change to the ORM Travis configuration
Message-ID: <CALt0+o9nJxeh7NiByfA9N0knJts6=XtXW9drnkGudwTWNDgcGA@mail.gmail.com>

Hi,

The Travis cache behaves this way:
- try to get a cache specific to the PR
- then try to get a cache for master
- if none found, start without cache

The ORM Travis build was configured to not build the branches so master was
never build thus each PR starts with an empty cache (but subsequent pushes
to the same PR will use the PR cache).

I enabled the build for branches (Settings > Build pushed branches) so that
you have a cache for master. This should speed up the builds significantly.

-- 
Guillaume

From gbadner at redhat.com  Fri May  4 16:57:38 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 4 May 2018 13:57:38 -0700
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CALt0+o-mskxXXiXP9NyCG-idPtPDStp1UbY3ACt+p9YgcbCUrA@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<CAFm4XO1vfkAEW4V=EhT2hLUA7=A_e7cqGG3BNVGT-DwXgYXUAw@mail.gmail.com>
	<CALt0+o9AmqJqw_VUmy+Hr8xkLCzWfRdXDpv7DUu_+WkW1KpCoQ@mail.gmail.com>
	<CAFDzhiQ1WbhoL_UADba-cfsk3pUkiypK46Q8Xi6bm65vPMXXmg@mail.gmail.com>
	<CAFm4XO1uU3AfdBo9W_--7BuH4zZQA8W8s1RXbZdiCAvs6aRW-w@mail.gmail.com>
	<CALt0+o-gV8Wv47OtNyLRNjf5i1v77zv8qdittdNrf2YW1=JWKQ@mail.gmail.com>
	<CAFDzhiTfdnzSpAWJM1FH475jTP6BgF718x014Qn+0ebENf-VYA@mail.gmail.com>
	<CALt0+o-mskxXXiXP9NyCG-idPtPDStp1UbY3ACt+p9YgcbCUrA@mail.gmail.com>
Message-ID: <CAFDzhiT7neD6FQyO2TH_e1U4hf2o5+WDUGS04Y95kBGnybrBXg@mail.gmail.com>

OK, that's fine. I did a lot of the work converting to load plans, so feel
free to ask if you have questions.

On Fri, May 4, 2018 at 1:37 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> As already mentioned, I plan to take a look at this next week.
>
> I also thought we could share most of the info between loaders but Steve
> was thinking it might not be possible without massive changes.
>
> I'll take a look and report back to all of you. I might be way over my
> head as I don't know the codebase very well but I already did a very
> similar work for HV with great results so it's worth a shot.
>
> --
> Guillaume
>
> On Fri, May 4, 2018 at 10:31 PM, Gail Badner <gbadner at redhat.com> wrote:
>
>> I *think* that most, if not all, of the loaders for a particular entity
>> could be reworked to share most of the same information.
>>
>> IIRC, the only real differences are the batch size and the actual query
>> that gets generated.
>>
>> I'm happy to look into this, but I don't want to duplicate what others
>> are doing. It a bit difficult collaborating on this since our time zones
>> don't overlap very well (and, unfortunately, I'm not a morning person).
>>
>> I have some other work I need to attend to today. Please let me know if I
>> should dig into this next week.
>>
>> On Fri, May 4, 2018 at 12:30 PM, Guillaume Smet <guillaume.smet at gmail.com
>> > wrote:
>>
>>> Don't know about the history but with the entity I checked out in the
>>> OP's case, each EntityLoader is approximately 200 KB.
>>>
>>> The entity contains a lot of columns so that's no surprise.
>>>
>>> What doesn't help is that I don't think the 13 EntityLoaders/entity
>>> share a lot of things so they are just adding up.
>>>
>>> On Fri, May 4, 2018 at 9:15 PM, Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>>
>>>> On 4 May 2018 at 19:45, Gail Badner <gbadner at redhat.com> wrote:
>>>> > I don't think the batching strategies actually changed when we moved
>>>> to load
>>>> > plans.
>>>> >
>>>> > Is the problem that each loader is taking considerably more memory?
>>>>
>>>> Yes that's right.
>>>>
>>>> >
>>>> > On Fri, May 4, 2018 at 5:41 AM, Guillaume Smet <
>>>> guillaume.smet at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> On Fri, May 4, 2018 at 11:48 AM, Sanne Grinovero <
>>>> sanne at hibernate.org>
>>>> >> wrote:
>>>> >>
>>>> >> > thanks for investigating. Steve in chat mentioned the option of
>>>> >> > creating these EntityLoaders lazily: as while they need to be
>>>> reused,
>>>> >> > it's possible many of them are never really used.
>>>> >> >
>>>> >> > I think that's a very interesting observation, is that what you
>>>> plan to
>>>> >> > explore?
>>>> >> >
>>>> >>
>>>> >> Yes, it's one of the things we should explore.
>>>> >>
>>>> >>
>>>> >> > I see two difficulties:
>>>> >> >  - you'd need thredsafe code, yet we don't want barriers on this
>>>> area.
>>>> >> > Will probably need features such as lazy set, yet these would need
>>>> >> > even more objects allocated if you're not careful.
>>>> >> >  - we always prefer fail-at-boot validation, so we'd need to make
>>>> sure
>>>> >> > even if you don't build them all, we can at least make sure we'll
>>>> be
>>>> >> > able to build them later.
>>>> >> >
>>>> >>
>>>> >> Well, the idea is to prototype something on the memory usage front,
>>>> then
>>>> >> we
>>>> >> can discuss further what we want to do with it and if it's worth
>>>> refining
>>>> >> it and spending more time on it.
>>>> >>
>>>> >> If we end up choosing this path, be sure we'll be bugging you for
>>>> advice
>>>> >> on
>>>> >> concurrency and performance :).
>>>> >>
>>>> >>
>>>> >> > Additionally there's the idea to see if any such Loader instance
>>>> could
>>>> >> > be reused - probably using a cache which we clear at end of
>>>> bootstrap
>>>> >> > - yet since Steve mentioned this would be a significant change
>>>> let's
>>>> >> > not try to push it in 5.3.
>>>> >> >
>>>> >> > Finally, a simple one: I have the impression that loader's Map
>>>> could
>>>> >> > be made into a plain array, or a custom structure which would then
>>>> be
>>>> >> > ideal to support lazy creation of loaders. With the exception of
>>>> two
>>>> >> > special strings - which will needt to be treated specially - all
>>>> other
>>>> >> > keys are enums.
>>>> >> >
>>>> >>
>>>> >> Yeah, I'll play with a few ideas and see what I can do. I'm not yet
>>>> sure
>>>> >> if
>>>> >> not knowing the code base will be a thing in my favor or not. At
>>>> least I
>>>> >> don't have preconceived ideas :].
>>>> >>
>>>> >>
>>>> >> > Whatever you choose to try, let's keep significant changes for 6
>>>> only :)
>>>> >> >
>>>> >>
>>>> >> Steve was saying that this whole thing wouldn't be an issue in 6.
>>>> >>
>>>> >> --
>>>> >> 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 steve at hibernate.org  Fri May  4 16:58:17 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 04 May 2018 20:58:17 +0000
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CALt0+o-mskxXXiXP9NyCG-idPtPDStp1UbY3ACt+p9YgcbCUrA@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<CAFm4XO1vfkAEW4V=EhT2hLUA7=A_e7cqGG3BNVGT-DwXgYXUAw@mail.gmail.com>
	<CALt0+o9AmqJqw_VUmy+Hr8xkLCzWfRdXDpv7DUu_+WkW1KpCoQ@mail.gmail.com>
	<CAFDzhiQ1WbhoL_UADba-cfsk3pUkiypK46Q8Xi6bm65vPMXXmg@mail.gmail.com>
	<CAFm4XO1uU3AfdBo9W_--7BuH4zZQA8W8s1RXbZdiCAvs6aRW-w@mail.gmail.com>
	<CALt0+o-gV8Wv47OtNyLRNjf5i1v77zv8qdittdNrf2YW1=JWKQ@mail.gmail.com>
	<CAFDzhiTfdnzSpAWJM1FH475jTP6BgF718x014Qn+0ebENf-VYA@mail.gmail.com>
	<CALt0+o-mskxXXiXP9NyCG-idPtPDStp1UbY3ACt+p9YgcbCUrA@mail.gmail.com>
Message-ID: <CAFdSV9vtLaqRVKT70Jjo7ny+EmNKQuV-XshBGUk-2LRSu-5cRA@mail.gmail.com>

Loaders were designed to be an encapsulation of the query (the SQL, how to
build and execute the PreparedStatement) and the "load plan" (how the
ResultSet is processed).  4.2 changed how this last part is represented,
but overall the design is the same it always has been.  The problem is that
Loader was designed such that it itself builds all of these pieces.

This is what you'd have to change - specifically to split the creation of
the "load plan" outside of the Loader, or at least have the ability to pass
in an externally built one

On Fri, May 4, 2018 at 3:50 PM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> As already mentioned, I plan to take a look at this next week.
>
> I also thought we could share most of the info between loaders but Steve
> was thinking it might not be possible without massive changes.
>
> I'll take a look and report back to all of you. I might be way over my head
> as I don't know the codebase very well but I already did a very similar
> work for HV with great results so it's worth a shot.
>
> --
> Guillaume
>
> On Fri, May 4, 2018 at 10:31 PM, Gail Badner <gbadner at redhat.com> wrote:
>
> > I *think* that most, if not all, of the loaders for a particular entity
> > could be reworked to share most of the same information.
> >
> > IIRC, the only real differences are the batch size and the actual query
> > that gets generated.
> >
> > I'm happy to look into this, but I don't want to duplicate what others
> are
> > doing. It a bit difficult collaborating on this since our time zones
> don't
> > overlap very well (and, unfortunately, I'm not a morning person).
> >
> > I have some other work I need to attend to today. Please let me know if I
> > should dig into this next week.
> >
> > On Fri, May 4, 2018 at 12:30 PM, Guillaume Smet <
> guillaume.smet at gmail.com>
> > wrote:
> >
> >> Don't know about the history but with the entity I checked out in the
> >> OP's case, each EntityLoader is approximately 200 KB.
> >>
> >> The entity contains a lot of columns so that's no surprise.
> >>
> >> What doesn't help is that I don't think the 13 EntityLoaders/entity
> share
> >> a lot of things so they are just adding up.
> >>
> >> On Fri, May 4, 2018 at 9:15 PM, Sanne Grinovero <sanne at hibernate.org>
> >> wrote:
> >>
> >>> On 4 May 2018 at 19:45, Gail Badner <gbadner at redhat.com> wrote:
> >>> > I don't think the batching strategies actually changed when we moved
> >>> to load
> >>> > plans.
> >>> >
> >>> > Is the problem that each loader is taking considerably more memory?
> >>>
> >>> Yes that's right.
> >>>
> >>> >
> >>> > On Fri, May 4, 2018 at 5:41 AM, Guillaume Smet <
> >>> guillaume.smet at gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> On Fri, May 4, 2018 at 11:48 AM, Sanne Grinovero <
> sanne at hibernate.org
> >>> >
> >>> >> wrote:
> >>> >>
> >>> >> > thanks for investigating. Steve in chat mentioned the option of
> >>> >> > creating these EntityLoaders lazily: as while they need to be
> >>> reused,
> >>> >> > it's possible many of them are never really used.
> >>> >> >
> >>> >> > I think that's a very interesting observation, is that what you
> >>> plan to
> >>> >> > explore?
> >>> >> >
> >>> >>
> >>> >> Yes, it's one of the things we should explore.
> >>> >>
> >>> >>
> >>> >> > I see two difficulties:
> >>> >> >  - you'd need thredsafe code, yet we don't want barriers on this
> >>> area.
> >>> >> > Will probably need features such as lazy set, yet these would need
> >>> >> > even more objects allocated if you're not careful.
> >>> >> >  - we always prefer fail-at-boot validation, so we'd need to make
> >>> sure
> >>> >> > even if you don't build them all, we can at least make sure we'll
> be
> >>> >> > able to build them later.
> >>> >> >
> >>> >>
> >>> >> Well, the idea is to prototype something on the memory usage front,
> >>> then
> >>> >> we
> >>> >> can discuss further what we want to do with it and if it's worth
> >>> refining
> >>> >> it and spending more time on it.
> >>> >>
> >>> >> If we end up choosing this path, be sure we'll be bugging you for
> >>> advice
> >>> >> on
> >>> >> concurrency and performance :).
> >>> >>
> >>> >>
> >>> >> > Additionally there's the idea to see if any such Loader instance
> >>> could
> >>> >> > be reused - probably using a cache which we clear at end of
> >>> bootstrap
> >>> >> > - yet since Steve mentioned this would be a significant change
> let's
> >>> >> > not try to push it in 5.3.
> >>> >> >
> >>> >> > Finally, a simple one: I have the impression that loader's Map
> could
> >>> >> > be made into a plain array, or a custom structure which would then
> >>> be
> >>> >> > ideal to support lazy creation of loaders. With the exception of
> two
> >>> >> > special strings - which will needt to be treated specially - all
> >>> other
> >>> >> > keys are enums.
> >>> >> >
> >>> >>
> >>> >> Yeah, I'll play with a few ideas and see what I can do. I'm not yet
> >>> sure
> >>> >> if
> >>> >> not knowing the code base will be a thing in my favor or not. At
> >>> least I
> >>> >> don't have preconceived ideas :].
> >>> >>
> >>> >>
> >>> >> > Whatever you choose to try, let's keep significant changes for 6
> >>> only :)
> >>> >> >
> >>> >>
> >>> >> Steve was saying that this whole thing wouldn't be an issue in 6.
> >>> >>
> >>> >> --
> >>> >> 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
> >>>
> >>
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From golovnin at gmx.net  Sun May  6 17:04:56 2018
From: golovnin at gmx.net (Andrej Golovnin)
Date: Sun, 6 May 2018 23:04:56 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
 5.3
In-Reply-To: <CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
Message-ID: <4D857263-1C41-4BE8-8B21-6EACFDC1D686@gmx.net>

Hi,

> So, I analyzed the dumps yesterday evening. The problem is real, meaning
> his SessionFactory is consuming more than 1GB of memory for 600+ tables,
> some with a lot of attributes. So for sure, the model is a big one, ?

No, it is still a small one. I work on a project with 2145 tables. And the SessionFactory
consumes on production systems ca 300-400MB with Hibernate 5.2. I haven?t
tested the project with Hibernate 5.3. But I doubt it would consume more memory.
Except the Hibernate team broke something again.

> but it
> would be nice to be more gentle with this type of configuration. I don't
> think it's something new to 5.3 though as it's not the first time we have
> this type of reports.
> 
>> From my observations, the problem mostly comes from:
> LegacyBatchingEntityLoader
> \_ loaders - EntityLoader
>    \_ staticLoadQuery - EntityLoadQueryDetails
>        \_ rootReturn - EntityReturnImpl
> 
> The largest LegacyBatchingEntityLoader I have in the dump takes more than 2
> MB.
> 
> Keep in mind that with a batch size of 50, we have 13 EntityLoaders for
> batch sizes of 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 20 and 50, each loader
> taking ~ 200 KB.
> 
> We discussed some ideas yesterday with Steve.

And I have discussed it with the Hibernate team 6 years ago:

http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008341.html

And my suggestion to create things lazily were ignored/rejected.
And I have ignored the opinion of the Hibernate team and implemented
my suggestions in my version of Hibernate and saved a lot of memory
in my project.

Btw. please ask the user whether he has a lot of abstract entity classes.
When yes, then ask him if it would be possible to convert this entity classes
to mapped supper-classes. This may help to reduce memory consumption too.

Best regards,
Andrej Golovnin

From guillaume.smet at gmail.com  Mon May  7 04:28:35 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 7 May 2018 10:28:35 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <6FE10FC1-C1E4-47D8-BDFB-B77CCE861789@gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<6FE10FC1-C1E4-47D8-BDFB-B77CCE861789@gmail.com>
Message-ID: <CALt0+o_24YDkV2p-OZVbwdgzU7-ctfm+kFv42+NSgsYzSn=Xiw@mail.gmail.com>

Hi Andrej,

On Sun, May 6, 2018 at 11:03 PM, Andrej Golovnin <andrej.golovnin at gmail.com>
wrote:

> > So, I analyzed the dumps yesterday evening. The problem is real, meaning
> > his SessionFactory is consuming more than 1GB of memory for 600+ tables,
> > some with a lot of attributes. So for sure, the model is a big one, ?
>
> No, it is still a small one. I work on a project with 2145 tables. And the
> SessionFactory
> consumes on production systems ca 300-400MB with Hibernate 5.2. I haven?t
> tested the project with Hibernate 5.3. But I doubt it would consume more
> memory.
> Except the Hibernate team broke something again
>

It's not only the number of tables but also the number of columns per
table. The table I take as an example in my tests has 200+ columns, which
definitely doesn't help.

And I have discussed it with the Hibernate team 6 years ago:
>
> http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008341.html
>
> And my suggestion to create things lazily were ignored/rejected.
> And I have ignored the opinion of the Hibernate team and implemented
> my suggestions in my version of Hibernate and saved a lot of memory
> in my project.
>

See, we are improving.

I see a lot of conjectures in the thread but we should have analyzed the
memory dump more closely to understand exactly what was going on.

I think it would have led to a different outcome.


> Btw. please ask the user whether he has a lot of abstract entity classes.
> When yes, then ask him if it would be possible to convert this entity
> classes
> to mapped supper-classes. This may help to reduce memory consumption too.
>

Yeah, first, I would like to see if we can improve the situation by
changing the ORM code. I'm more for us improving the situation globally
rather than tweaking the model of each user.

If we can come up with some patches, it would be nice if you could test
them with your workload.

-- 
Guillaume

From andrej.golovnin at gmail.com  Mon May  7 08:52:31 2018
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Mon, 7 May 2018 14:52:31 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CALt0+o_24YDkV2p-OZVbwdgzU7-ctfm+kFv42+NSgsYzSn=Xiw@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<6FE10FC1-C1E4-47D8-BDFB-B77CCE861789@gmail.com>
	<CALt0+o_24YDkV2p-OZVbwdgzU7-ctfm+kFv42+NSgsYzSn=Xiw@mail.gmail.com>
Message-ID: <CAM6ZMz_Kivo0fnS_5Rb2fyaH89_J9TkbzWHOKoi8_YVnNVbmoQ@mail.gmail.com>

Hi Guillaume,

> It's not only the number of tables but also the number of columns per table.
> The table I take as an example in my tests has 200+ columns, which
> definitely doesn't help.

I have also a lot of tables with high number of columns. The biggest
one has 254 columns. So what?

>
> If we can come up with some patches, it would be nice if you could test them
> with your workload.

When you are ready, sent me links to the pull requests and I'll test them.

Best regards,
Andrej Golovnin

From guillaume.smet at gmail.com  Mon May  7 09:37:02 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 7 May 2018 15:37:02 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAM6ZMz_Kivo0fnS_5Rb2fyaH89_J9TkbzWHOKoi8_YVnNVbmoQ@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<6FE10FC1-C1E4-47D8-BDFB-B77CCE861789@gmail.com>
	<CALt0+o_24YDkV2p-OZVbwdgzU7-ctfm+kFv42+NSgsYzSn=Xiw@mail.gmail.com>
	<CAM6ZMz_Kivo0fnS_5Rb2fyaH89_J9TkbzWHOKoi8_YVnNVbmoQ@mail.gmail.com>
Message-ID: <CALt0+o_dvU-pRGQDbL2o=SQkFLYw=Tim2q_4e29b-tqJxDrp-Q@mail.gmail.com>

On Mon, May 7, 2018 at 2:52 PM, Andrej Golovnin <andrej.golovnin at gmail.com>
wrote:

> > It's not only the number of tables but also the number of columns per
> table.
> > The table I take as an example in my tests has 200+ columns, which
> > definitely doesn't help.
>
> I have also a lot of tables with high number of columns. The biggest
> one has 254 columns. So what?
>

So it's not the average 20 columns table.

Not saying it's not a case we should be grateful with.

-- 
Guillaume

From andrej.golovnin at gmail.com  Tue May  8 02:11:31 2018
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Tue, 8 May 2018 08:11:31 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CALt0+o_dvU-pRGQDbL2o=SQkFLYw=Tim2q_4e29b-tqJxDrp-Q@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<6FE10FC1-C1E4-47D8-BDFB-B77CCE861789@gmail.com>
	<CALt0+o_24YDkV2p-OZVbwdgzU7-ctfm+kFv42+NSgsYzSn=Xiw@mail.gmail.com>
	<CAM6ZMz_Kivo0fnS_5Rb2fyaH89_J9TkbzWHOKoi8_YVnNVbmoQ@mail.gmail.com>
	<CALt0+o_dvU-pRGQDbL2o=SQkFLYw=Tim2q_4e29b-tqJxDrp-Q@mail.gmail.com>
Message-ID: <CAM6ZMz_6AV+xNmTk0c1hBydQ9vmoAjZScKy+6HSymHUWv=PExA@mail.gmail.com>

Hi Guillaume,

>> > It's not only the number of tables but also the number of columns per
>> > table.
>> > The table I take as an example in my tests has 200+ columns, which
>> > definitely doesn't help.
>>
>> I have also a lot of tables with high number of columns. The biggest
>> one has 254 columns. So what?
>
>
> So it's not the average 20 columns table.
>
> Not saying it's not a case we should be grateful with.
>
> --
> Guillaume
>

What you should really do is write a generator that would generate
models with a configurable number of entities, abstract entities,
mapped supper-classes, embeddables, relationships, fields, and so on.
You could integrate it into the build process to verify memory
consumption after every change in the Hibernate code. This would allow
you to find problems before you ship a new version of Hibernate.

It should be a good job for a student. :-)

Best regards,
Andrej Golovnin

From rory.odonnell at oracle.com  Tue May  8 04:05:20 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 8 May 2018 09:05:20 +0100
Subject: [hibernate-dev] JDK 11 Early Access build 12 available
Message-ID: <d4d41cd1-9906-11e8-d15f-20284016c610@oracle.com>

Hi Sanne,


**JDK 11 EA build 12 , *****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 https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html

*Notable changes in JDK 11 EA builds since last email:*

  * Build 11 - see Release Notes for details.
      o JDK-8201315 : SelectableChannel.register may be invoked while a
        selection operation is in progress
  * Build 10 - see Release Notes for details.
      o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class
      o JDK-8189997 (not public) :? Enhanced KeyStore Mechanisms
      o JDK-8175075 (not public) : 3DES Cipher Suites Disabled
  * Build 9: - see Release Notes for details.
      o JDK-8200152 : KerberosString uses UTF-8 encoding by default
      o JDK-8200458 : Readiness information previously recorded in
        SelectionKey ready set not preserved

**


*Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1]
*
This draft JEP [2] proposes to deprecate the pack200 APIs and tools in 
the JDK. As outlined in the JEP, the usefulness of this technology
have diminishing returns, the components using them are being removed 
and connectivity speeds have improved by leaps and bounds,
since its inception.? Feedback appreciated via 
http://mail.openjdk.java.net/pipermail/jdk-dev

Regards,
Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html
[2] https://bugs.openjdk.java.net/browse/JDK-8200752

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


From sanne at hibernate.org  Tue May  8 05:14:47 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 8 May 2018 10:14:47 +0100
Subject: [hibernate-dev] JDK 11 Early Access build 12 available
In-Reply-To: <d4d41cd1-9906-11e8-d15f-20284016c610@oracle.com>
References: <d4d41cd1-9906-11e8-d15f-20284016c610@oracle.com>
Message-ID: <CAFm4XO1MK486a79J4tqhLcH9_zyDr=N0WwtKax0wHwsPwFAQxw@mail.gmail.com>

Hi Rory,

thanks for the regular updates!

Unfortunately many tools we need are still unable to run properly on
JDK11 so I can't run our comprehensive tests.

For the record, a common issue seems to be the inability to parse the
'11-ea' version number.

The few modules I can run "manually" in isolation didn't highlight any
specific problem with Hibernate libraries so far, but such testing has
been quite limited. I hope to be able to tell you more soon.

Regards,
Sanne




On 8 May 2018 at 09:05, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
> Hi Sanne,
>
>
> **JDK 11 EA build 12 , *****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 https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html
>
> *Notable changes in JDK 11 EA builds since last email:*
>
>   * Build 11 - see Release Notes for details.
>       o JDK-8201315 : SelectableChannel.register may be invoked while a
>         selection operation is in progress
>   * Build 10 - see Release Notes for details.
>       o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class
>       o JDK-8189997 (not public) :  Enhanced KeyStore Mechanisms
>       o JDK-8175075 (not public) : 3DES Cipher Suites Disabled
>   * Build 9: - see Release Notes for details.
>       o JDK-8200152 : KerberosString uses UTF-8 encoding by default
>       o JDK-8200458 : Readiness information previously recorded in
>         SelectionKey ready set not preserved
>
> **
>
>
> *Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1]
> *
> This draft JEP [2] proposes to deprecate the pack200 APIs and tools in
> the JDK. As outlined in the JEP, the usefulness of this technology
> have diminishing returns, the components using them are being removed
> and connectivity speeds have improved by leaps and bounds,
> since its inception.  Feedback appreciated via
> http://mail.openjdk.java.net/pipermail/jdk-dev
>
> Regards,
> Rory
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8200752
>
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin,Ireland
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From dreborier at gmail.com  Tue May  8 05:31:16 2018
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 08 May 2018 09:31:16 +0000
Subject: [hibernate-dev] PTO
Message-ID: <CAL00eSTLW+XLamqLAG+Qtty74v4G2OQc8KzqS2zA75Viio0hdA@mail.gmail.com>

This afternoon I will be on PTO. Sorry for the late notice but it was due
to an unexpected event.

Andrea

From sanne at hibernate.org  Tue May  8 05:42:32 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 8 May 2018 10:42:32 +0100
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <6FE10FC1-C1E4-47D8-BDFB-B77CCE861789@gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<6FE10FC1-C1E4-47D8-BDFB-B77CCE861789@gmail.com>
Message-ID: <CAFm4XO05hVFXSo5wmTqyc257YUv9QMK4ZYFWVakrcevrHfybSQ@mail.gmail.com>

Hi Andrej,

you're right, I found the most interesting email from you now (reading
the whole thread) :
 - http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008410.html

I'm not sure why the discussion stopped, I'm sorry.
Let's try to fix it this time, to make sure of that we need a JIRA.
Someone created one? Guillaume?

summary:
 - problem introduced by https://hibernate.atlassian.net/browse/HHH-4546
 - great results applying Andrej's
https://github.com/golovnin/hibernate-orm/commit/1cc8a23d1d5f4079fb090cca63a44e8660f05c7f
 - the patch could be improved today with Java8
   -- I'd like to have some degree of upfront validation at boostrap still
   -- hopefully explore an array based structure
   -- do not extend CHM
   -- ideally have no read barriers at all at runtime

Thanks,
Sanne


On 6 May 2018 at 22:03, Andrej Golovnin <andrej.golovnin at gmail.com> wrote:
> Hi,
>
>> So, I analyzed the dumps yesterday evening. The problem is real, meaning
>> his SessionFactory is consuming more than 1GB of memory for 600+ tables,
>> some with a lot of attributes. So for sure, the model is a big one, ?
>
> No, it is still a small one. I work on a project with 2145 tables. And the SessionFactory
> consumes on production systems ca 300-400MB with Hibernate 5.2. I haven?t
> tested the project with Hibernate 5.3. But I doubt it would consume more memory.
> Except the Hibernate team broke something again.
>
>> but it
>> would be nice to be more gentle with this type of configuration. I don't
>> think it's something new to 5.3 though as it's not the first time we have
>> this type of reports.
>>
>>> From my observations, the problem mostly comes from:
>> LegacyBatchingEntityLoader
>> \_ loaders - EntityLoader
>>     \_ staticLoadQuery - EntityLoadQueryDetails
>>         \_ rootReturn - EntityReturnImpl
>>
>> The largest LegacyBatchingEntityLoader I have in the dump takes more than 2
>> MB.
>>
>> Keep in mind that with a batch size of 50, we have 13 EntityLoaders for
>> batch sizes of 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 20 and 50, each loader
>> taking ~ 200 KB.
>>
>> We discussed some ideas yesterday with Steve.
>
> And I have discussed it with the Hibernate team 6 years ago:
>
> http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008341.html
>
> And my suggestion to create things lazily were ignored/rejected.
> And I have ignored the opinion of the Hibernate team and implemented
> my suggestions in my version of Hibernate and saved a lot of memory
> in my project.
>
> Btw. please ask the user whether he has a lot of abstract entity classes.
> When yes, then ask him if it would be possible to convert this entity classes
> to mapped supper-classes. This may help to reduce memory consumption too.
>
> Best regards,
> Andrej Golovnin


From rory.odonnell at oracle.com  Tue May  8 06:25:13 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 8 May 2018 11:25:13 +0100
Subject: [hibernate-dev] JDK 11 Early Access build 12 available
In-Reply-To: <CAFm4XO1MK486a79J4tqhLcH9_zyDr=N0WwtKax0wHwsPwFAQxw@mail.gmail.com>
References: <d4d41cd1-9906-11e8-d15f-20284016c610@oracle.com>
	<CAFm4XO1MK486a79J4tqhLcH9_zyDr=N0WwtKax0wHwsPwFAQxw@mail.gmail.com>
Message-ID: <041200a6-295d-fa5d-d49c-8211167b7488@oracle.com>

Thanks Sanne !


On 08/05/2018 10:14, Sanne Grinovero wrote:
> Hi Rory,
>
> thanks for the regular updates!
>
> Unfortunately many tools we need are still unable to run properly on
> JDK11 so I can't run our comprehensive tests.
>
> For the record, a common issue seems to be the inability to parse the
> '11-ea' version number.
>
> The few modules I can run "manually" in isolation didn't highlight any
> specific problem with Hibernate libraries so far, but such testing has
> been quite limited. I hope to be able to tell you more soon.
>
> Regards,
> Sanne
>
>
>
>
> On 8 May 2018 at 09:05, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
>> Hi Sanne,
>>
>>
>> **JDK 11 EA build 12 , *****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 https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html
>>
>> *Notable changes in JDK 11 EA builds since last email:*
>>
>>    * Build 11 - see Release Notes for details.
>>        o JDK-8201315 : SelectableChannel.register may be invoked while a
>>          selection operation is in progress
>>    * Build 10 - see Release Notes for details.
>>        o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class
>>        o JDK-8189997 (not public) :  Enhanced KeyStore Mechanisms
>>        o JDK-8175075 (not public) : 3DES Cipher Suites Disabled
>>    * Build 9: - see Release Notes for details.
>>        o JDK-8200152 : KerberosString uses UTF-8 encoding by default
>>        o JDK-8200458 : Readiness information previously recorded in
>>          SelectionKey ready set not preserved
>>
>> **
>>
>>
>> *Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1]
>> *
>> This draft JEP [2] proposes to deprecate the pack200 APIs and tools in
>> the JDK. As outlined in the JEP, the usefulness of this technology
>> have diminishing returns, the components using them are being removed
>> and connectivity speeds have improved by leaps and bounds,
>> since its inception.  Feedback appreciated via
>> http://mail.openjdk.java.net/pipermail/jdk-dev
>>
>> Regards,
>> Rory
>>
>> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html
>> [2] https://bugs.openjdk.java.net/browse/JDK-8200752
>>
>> 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 andrej.golovnin at gmail.com  Tue May  8 07:06:58 2018
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Tue, 8 May 2018 13:06:58 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAFm4XO05hVFXSo5wmTqyc257YUv9QMK4ZYFWVakrcevrHfybSQ@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<6FE10FC1-C1E4-47D8-BDFB-B77CCE861789@gmail.com>
	<CAFm4XO05hVFXSo5wmTqyc257YUv9QMK4ZYFWVakrcevrHfybSQ@mail.gmail.com>
Message-ID: <CAM6ZMz8vRDvEtT8WS6ODaR=Ry_4YK_HHJKC7jhvjwyrPMvVfng@mail.gmail.com>

Hi Sanne,

> you're right, I found the most interesting email from you now (reading
> the whole thread) :
>  - http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008410.html
>
> I'm not sure why the discussion stopped, I'm sorry.
> Let's try to fix it this time, to make sure of that we need a JIRA.
> Someone created one? Guillaume?
>
> summary:
>  - problem introduced by https://hibernate.atlassian.net/browse/HHH-4546
>  - great results applying Andrej's
> https://github.com/golovnin/hibernate-orm/commit/1cc8a23d1d5f4079fb090cca63a44e8660f05c7f
>  - the patch could be improved today with Java8
>    -- I'd like to have some degree of upfront validation at boostrap still
>    -- hopefully explore an array based structure
>    -- do not extend CHM
>    -- ideally have no read barriers at all at runtime
>

This is an old patch. The current version does not extend CHM and even
does not use it. It adds ca. 30 lines of code and modifies two classes
to achieve the most memory savings.

And Sanne, it is not needed to be sorry. Thanks to GIT I can apply my
patches to the new version of Hibernate without big problems and have
the best Hibernate version ever. :-)

Best regards,
Andrej Golovnin

From sanne at hibernate.org  Tue May  8 07:16:24 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 8 May 2018 12:16:24 +0100
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAM6ZMz8vRDvEtT8WS6ODaR=Ry_4YK_HHJKC7jhvjwyrPMvVfng@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<6FE10FC1-C1E4-47D8-BDFB-B77CCE861789@gmail.com>
	<CAFm4XO05hVFXSo5wmTqyc257YUv9QMK4ZYFWVakrcevrHfybSQ@mail.gmail.com>
	<CAM6ZMz8vRDvEtT8WS6ODaR=Ry_4YK_HHJKC7jhvjwyrPMvVfng@mail.gmail.com>
Message-ID: <CAFm4XO2v_dzkvZ9pr-xnpxqRNwWZL+8SG_ASVCYrwf2QWTVw3w@mail.gmail.com>

Hi Andrej,

sounds great. Do you plan to contribute your updated patch version?

Thanks,
Sanne

On 8 May 2018 at 12:06, Andrej Golovnin <andrej.golovnin at gmail.com> wrote:
> Hi Sanne,
>
>> you're right, I found the most interesting email from you now (reading
>> the whole thread) :
>>  - http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008410.html
>>
>> I'm not sure why the discussion stopped, I'm sorry.
>> Let's try to fix it this time, to make sure of that we need a JIRA.
>> Someone created one? Guillaume?
>>
>> summary:
>>  - problem introduced by https://hibernate.atlassian.net/browse/HHH-4546
>>  - great results applying Andrej's
>> https://github.com/golovnin/hibernate-orm/commit/1cc8a23d1d5f4079fb090cca63a44e8660f05c7f
>>  - the patch could be improved today with Java8
>>    -- I'd like to have some degree of upfront validation at boostrap still
>>    -- hopefully explore an array based structure
>>    -- do not extend CHM
>>    -- ideally have no read barriers at all at runtime
>>
>
> This is an old patch. The current version does not extend CHM and even
> does not use it. It adds ca. 30 lines of code and modifies two classes
> to achieve the most memory savings.
>
> And Sanne, it is not needed to be sorry. Thanks to GIT I can apply my
> patches to the new version of Hibernate without big problems and have
> the best Hibernate version ever. :-)
>
> Best regards,
> Andrej Golovnin

From guillaume.smet at hibernate.org  Tue May  8 07:21:37 2018
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Tue, 8 May 2018 13:21:37 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAFm4XO05hVFXSo5wmTqyc257YUv9QMK4ZYFWVakrcevrHfybSQ@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<6FE10FC1-C1E4-47D8-BDFB-B77CCE861789@gmail.com>
	<CAFm4XO05hVFXSo5wmTqyc257YUv9QMK4ZYFWVakrcevrHfybSQ@mail.gmail.com>
Message-ID: <CALt0+o8DYDscngCPCQ+YJV9JKYKyEHLjmO5p_-wSWOBN_DkcLQ@mail.gmail.com>

Hi,

On Tue, May 8, 2018 at 11:42 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> I'm not sure why the discussion stopped, I'm sorry.
> Let's try to fix it this time, to make sure of that we need a JIRA.
> Someone created one? Guillaume?
>

No, I didn't. I plan to work on it tomorrow (today is a public holiday
here... and well Thursday too so I have my Friday booked for it too) and
will create the appropriate JIRAs once I have a good grasp of what needs to
be done.

Lazy loading the loaders is one thing but I think we should also try to
reduce the amount of memory consumed by them. Otherwise you can still have
the same issue under load. And it might be even more problematic as you
don't see the issue at startup.

As mentioned, I'll get back to you soon.

-- 
Guillaume

From andrej.golovnin at gmail.com  Tue May  8 08:18:50 2018
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Tue, 8 May 2018 14:18:50 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAFm4XO2v_dzkvZ9pr-xnpxqRNwWZL+8SG_ASVCYrwf2QWTVw3w@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<6FE10FC1-C1E4-47D8-BDFB-B77CCE861789@gmail.com>
	<CAFm4XO05hVFXSo5wmTqyc257YUv9QMK4ZYFWVakrcevrHfybSQ@mail.gmail.com>
	<CAM6ZMz8vRDvEtT8WS6ODaR=Ry_4YK_HHJKC7jhvjwyrPMvVfng@mail.gmail.com>
	<CAFm4XO2v_dzkvZ9pr-xnpxqRNwWZL+8SG_ASVCYrwf2QWTVw3w@mail.gmail.com>
Message-ID: <CAM6ZMz-v1RYDLGnQK0h0fW8QZGP0Yds1vGjoo45Y3vXfLEOKug@mail.gmail.com>

Hi Sanne,

> sounds great. Do you plan to contribute your updated patch version?

I don't think it is needed. I'm sure Guillaume will provide a good
solution. And if not, then I will still have the best Hibernate
version ever. :-) (OK, I will have in any case the best Hibernate
version ever because I have more patches. But this is another story.
:-) )

Best regards,
Andrej Golovnin

From steve at hibernate.org  Tue May  8 09:20:56 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 08 May 2018 13:20:56 +0000
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CAM6ZMz-v1RYDLGnQK0h0fW8QZGP0Yds1vGjoo45Y3vXfLEOKug@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<6FE10FC1-C1E4-47D8-BDFB-B77CCE861789@gmail.com>
	<CAFm4XO05hVFXSo5wmTqyc257YUv9QMK4ZYFWVakrcevrHfybSQ@mail.gmail.com>
	<CAM6ZMz8vRDvEtT8WS6ODaR=Ry_4YK_HHJKC7jhvjwyrPMvVfng@mail.gmail.com>
	<CAFm4XO2v_dzkvZ9pr-xnpxqRNwWZL+8SG_ASVCYrwf2QWTVw3w@mail.gmail.com>
	<CAM6ZMz-v1RYDLGnQK0h0fW8QZGP0Yds1vGjoo45Y3vXfLEOKug@mail.gmail.com>
Message-ID: <CAFdSV9sgbRuHW=749vBj5TP+XFQwwA3aBLFR5D9Y7_46g+-2_A@mail.gmail.com>

<quote>
>> Deferring initialization of these batch loaders is one option, but that
just really delays the memory consumption.  Personally, if it were my app
I'd rather that sizing be done up front rather than over the course of the
next few hours or weeks as the system continues to run.
</quote>

Not sure how that is advocating that we delay the generation ;)

Anyway, that email thread is what led me to add the different batch modes.
That helps with the memory consumption (I think - I was waiting on someone
to test it).  Have you tried one of the alternative batch modes?  I think
DYNAMIC is the only one that will improve memory usage, however it incurs
the overhead of calculating the SQL each and every time.

I have always had the idea to come back and delay the creation of these.
IMO we could calculate the most likely used Loaders up-front
(LockMode.NONE, LockMode.READ) and delay the more less-used ones.  I think
this is part of the solution.

I think the bigger solution is along the lines of what Guillaume is
planning on looking at.  In fact this is one of the design aspects of 6.0.
Loader is designed to bind the SQL and the "load plan" into one
representation.  The problem here is that it is designed to do this by
doing both tasks internally - it templates building the SQL via its
JoinWalkers, which also builds the "load plan".  So both happen at the same
time as part of the  same process.  The real solution is to break this up
so that generation of the SQL and determination of the "load plan" can be
separate operations - namely so that we can share the "load plan" graph
with all of the nested loaders for a given batch loader (sharing the load
plan across all batch loaders for a given entity is not feasible - some
different fetch grapghs.

Anyway, like I said - this is one of the design goals with 6.0 and is
actually already in place there.

I think ultimately a combination of delayed (and then cached) generation of
these <things responsible for loading> and separately creatable and
passable "load plans" (especially in combination with batch strategies) is
the ultimate solution.  I'm just not sure how feasible the "separately
creatable and passable load plans" portion is in 5.x.  Hopefully Guillaume
has luck solving that one.



On Tue, May 8, 2018 at 7:27 AM Andrej Golovnin <andrej.golovnin at gmail.com>
wrote:

> Hi Sanne,
>
> > sounds great. Do you plan to contribute your updated patch version?
>
> I don't think it is needed. I'm sure Guillaume will provide a good
> solution. And if not, then I will still have the best Hibernate
> version ever. :-) (OK, I will have in any case the best Hibernate
> version ever because I have more patches. But this is another story.
> :-) )
>
> Best regards,
> Andrej Golovnin
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.smet at hibernate.org  Tue May  8 09:56:27 2018
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Tue, 8 May 2018 15:56:27 +0200
Subject: [hibernate-dev] Hibernate NoORM IRC meeting minutes
Message-ID: <CALt0+o9zacm5TtnBLxbzLPORfBzgPRqZz__1jXpi8VXRsk0sSA@mail.gmail.com>

Hi,

Here are the minutes of our NoORM IRC meeting:

5:52 < jbott> Meeting ended Tue May  8 13:52:19 2018 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:52 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-08-13.02.html
15:52 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-08-13.02.txt
15:52 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-08-13.02.log.html

Cheers,

-- 
Guillaume

From guillaume.smet at hibernate.org  Tue May  8 10:18:20 2018
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Tue, 8 May 2018 16:18:20 +0200
Subject: [hibernate-dev] Hibernate Search 5.10.0.CR1 released!
Message-ID: <CALt0+o82nD0ktytvG99nB2m4kJnG47ZJT=Eqsxz8KiCahJjtyw@mail.gmail.com>

Hi,

We just released the first release candidate of Hibernate Search 5.10 with
support for Hibernate ORM 5.3.0.CR2 (and thus JPA 2.2).

Test it and report any issues you might encounter!

Thanks.

-- 
Guillaume

From guillaume.smet at hibernate.org  Tue May  8 10:32:40 2018
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Tue, 8 May 2018 16:32:40 +0200
Subject: [hibernate-dev] Hibernate Search 5.10.0.CR1 released!
In-Reply-To: <CALt0+o82nD0ktytvG99nB2m4kJnG47ZJT=Eqsxz8KiCahJjtyw@mail.gmail.com>
References: <CALt0+o82nD0ktytvG99nB2m4kJnG47ZJT=Eqsxz8KiCahJjtyw@mail.gmail.com>
Message-ID: <CALt0+o8YGMb5poq5V_b4GFumA5XRDuzsFafbQN+DsvgGTQK-iA@mail.gmail.com>

Better with the link:
http://in.relation.to/2018/05/09/hibernate-search-5-10-0-CR1/

Cheers.

On Tue, May 8, 2018 at 4:18 PM, Guillaume Smet <guillaume.smet at hibernate.org
> wrote:

> Hi,
>
> We just released the first release candidate of Hibernate Search 5.10 with
> support for Hibernate ORM 5.3.0.CR2 (and thus JPA 2.2).
>
> Test it and report any issues you might encounter!
>
> Thanks.
>
> --
> Guillaume
>

From gbadner at redhat.com  Tue May  8 18:13:47 2018
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 8 May 2018 15:13:47 -0700
Subject: [hibernate-dev] JPA XML ORM descriptors id-class and id
Message-ID: <CAFDzhiTVd5XD8WYVi45DmjaAX10oGHJZPnM=kN4OmS3V2+yeLQ@mail.gmail.com>

When an entity with an IdClass is mapped using XML ORM descriptors,
Hibernate requires the Id properties to be mapped as well, as in the
following example:

<entity class="Employee">

   <table name="entityobject"/>
   <id-class class="EmployeeId"/>
   <attributes>
      <id name="fname"/>
      <id name="lname"/>
   </attributes>
</entity>

If the <id> elements are not included, an exception is thrown:

"No identifier specified for entity: ..."

Should Hibernate require the <id> elements to be explicitly mapped, or
should it be able to determine this information by reflection from the
class configured by <id-class>?

Regards,
Gail

From andrea at hibernate.org  Wed May  9 06:09:51 2018
From: andrea at hibernate.org (andrea boriero)
Date: Wed, 9 May 2018 11:09:51 +0100
Subject: [hibernate-dev] JPA XML ORM descriptors id-class and id
In-Reply-To: <CAFDzhiTVd5XD8WYVi45DmjaAX10oGHJZPnM=kN4OmS3V2+yeLQ@mail.gmail.com>
References: <CAFDzhiTVd5XD8WYVi45DmjaAX10oGHJZPnM=kN4OmS3V2+yeLQ@mail.gmail.com>
Message-ID: <CAL00eSR4i1pvTh8WrQiu5JusBfmA4ZOZm6maZe8frOPhKRdj8Q@mail.gmail.com>

For the IdClass annotation the spec states that the "The Id annotation must
also be applied to the corresponding fields or properties of the entity.".
So in my opinion the XML ORM should follow the same rule.

On 8 May 2018 at 23:13, Gail Badner <gbadner at redhat.com> wrote:

> When an entity with an IdClass is mapped using XML ORM descriptors,
> Hibernate requires the Id properties to be mapped as well, as in the
> following example:
>
> <entity class="Employee">
>
>    <table name="entityobject"/>
>    <id-class class="EmployeeId"/>
>    <attributes>
>       <id name="fname"/>
>       <id name="lname"/>
>    </attributes>
> </entity>
>
> If the <id> elements are not included, an exception is thrown:
>
> "No identifier specified for entity: ..."
>
> Should Hibernate require the <id> elements to be explicitly mapped, or
> should it be able to determine this information by reflection from the
> class configured by <id-class>?
>
> Regards,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.smet at hibernate.org  Wed May  9 10:46:47 2018
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Wed, 9 May 2018 16:46:47 +0200
Subject: [hibernate-dev] SingleTableEntityPersister memory footprint in
	5.3
In-Reply-To: <CALt0+o8DYDscngCPCQ+YJV9JKYKyEHLjmO5p_-wSWOBN_DkcLQ@mail.gmail.com>
References: <CA+gWKMBDKKHtBhGCzojidZx_HN7tbXXhw1eYqYiGx=RF53e0iQ@mail.gmail.com>
	<CALt0+o_s6u87yp_fWG5p1QnNLLfSc5s_=1spjK6kRJ8DkckN-Q@mail.gmail.com>
	<CA+gWKMAiL_K4PE3zP-p+94ZkFEYhYKPNEtWQkF4cEAte6zZqLQ@mail.gmail.com>
	<CAFDzhiQMfqc9zBTaVVfdToPpCUbcn71TJiryxakCHi2nhXcfLg@mail.gmail.com>
	<CAFdSV9sfGoDfPMJXny3PgJadkJB0nQjz3Owas9kNnZg4FQ7Dag@mail.gmail.com>
	<CAFDzhiTxM+JJWAc6s7=o9pPKG6TMhHvtJQ5SJgkHRdrrFMgWHA@mail.gmail.com>
	<CAFm4XO0=tKee67kNRqq5eNuj=3Ho+QbLtxwtbTvigFGnGfq3ag@mail.gmail.com>
	<CALt0+o-9-+3aX2CdV-Zx76Rk-aS9=TXWsU4jVep31yEKZMnbuQ@mail.gmail.com>
	<6FE10FC1-C1E4-47D8-BDFB-B77CCE861789@gmail.com>
	<CAFm4XO05hVFXSo5wmTqyc257YUv9QMK4ZYFWVakrcevrHfybSQ@mail.gmail.com>
	<CALt0+o8DYDscngCPCQ+YJV9JKYKyEHLjmO5p_-wSWOBN_DkcLQ@mail.gmail.com>
Message-ID: <CALt0+o8kQ7brtietYxGV3qi8L9NLZ4LKF9y5xx+6a1VZk_Vw4g@mail.gmail.com>

Hi folks,

On Tue, May 8, 2018 at 1:21 PM, Guillaume Smet <guillaume.smet at hibernate.org
> wrote:

> As mentioned, I'll get back to you soon.
>

I know you were all impatiently waiting for me to start working on this so
here we are.

I created 2 PRs:
1/ https://github.com/hibernate/hibernate-orm/pull/2277
2/ https://github.com/hibernate/hibernate-orm/pull/2278

1/ was my initial idea before y'all told me what I should do ;). I think
it's pretty safe.
2/ contains 2 other changes, one to generalize 1/ and the other to lazy
load the loaders per lock mode that might be more risky

I added a lot of explanations/comments in the PRs (especially the second
one) so let's continue the discussion in the PRs (as long as it's related
to these PRs of course).

Feel free to shout other ideas here, they are obviously very welcome.

Thanks.

-- 
Guillaume

From sanne at hibernate.org  Wed May  9 17:30:38 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 9 May 2018 22:30:38 +0100
Subject: [hibernate-dev] JDK 11 Early Access build 12 available
In-Reply-To: <68891f8c-6fb9-6b22-8a0d-46588fc61394@oracle.com>
References: <d4d41cd1-9906-11e8-d15f-20284016c610@oracle.com>
	<CAFm4XO1MK486a79J4tqhLcH9_zyDr=N0WwtKax0wHwsPwFAQxw@mail.gmail.com>
	<68891f8c-6fb9-6b22-8a0d-46588fc61394@oracle.com>
Message-ID: <CAFm4XO1RRRpr0GfigVY8CQQd8kiNU_MRQ8rZr79NUFx3niNusQ@mail.gmail.com>

Hi Dalibor!

specifically about the version parsing we have hit some in Apache Karaf:
 - https://issues.apache.org/jira/browse/KARAF-5725
I previously reported the same for JDK10:
 - https://issues.apache.org/jira/browse/KARAF-5641

(the JDK10 related issue was resolved but it needs further changes to
deal with JDK11)

Even solving those it's a problem for OSGi testing as e.g. Pax Exam,
the integration testing tool we use to test with Karaf, was not
updated to match the latest Karaf issues. So to summarize currently
I'm not sure how to test anything on OSGi, we probably should look at
alternative integration testing tools.

Gradle is affected by the "version parsing" issue as well; it's fixed
now but wasn't released yet:
 - https://github.com/gradle/gradle/issues/4515

I've tested the nightly builds and it's ok, however even the nightly
builds only aim at JDK10 compatibility; JDK11 is scheduled for future
work.
We used the nightlies to test on both JDK10 and JDK11 and it seems to
work quite well, yet I have several other failures which I believe are
not related to Gradle nor specifically to the version format, so it's
all a bit premature to evaluate.
We will of course report issues to Gradle and/or others when things get clearer.

Next, coming from our Maven projects we have Surefire also chocking on
the version:
 - https://issues.apache.org/jira/browse/SUREFIRE-1439

this one was worrying me most as it took a long time to be fixed; as
you can see I reported it back in November 2017, during our JDK10
early access testing period.

Ironically some of those issues won't be triggered by the JDK11 final
release as the "-ea" part is the problem trigger, so maybe it will be
fine but it's having me disable large portions of our testsuites.

I guess the fact that JDK10 is no longer flagged as "ea" is what is
causing most of these issues to get reported in pairs: some libraries
fixed without the postfix first and then need a second patch when
people start looking at -ea versions; may I suggest to not change it
further for the LTS, or maybe even consider an enhancement: provide an
alternative to "-version" meant to facilitate machine parsing. Having
a prefix of two "--" while at it :)

I'll spare you details of the issues not related to versions at this
stage, we still have much work to do.

Thanks and regards,
Sanne





On 9 May 2018 at 19:30, dalibor topic <dalibor.topic at oracle.com> wrote:
> Hi Sanne,
>
> thank you for testing! Do you have a few URLs to share about the 11-ea
> version parsing issues you've seen with other tools?
>
> cheers,
> dalibor topic
>
>
> On 08.05.2018 11:14, Sanne Grinovero wrote:
>>
>> Hi Rory,
>>
>> thanks for the regular updates!
>>
>> Unfortunately many tools we need are still unable to run properly on
>> JDK11 so I can't run our comprehensive tests.
>>
>> For the record, a common issue seems to be the inability to parse the
>> '11-ea' version number.
>>
>> The few modules I can run "manually" in isolation didn't highlight any
>> specific problem with Hibernate libraries so far, but such testing has
>> been quite limited. I hope to be able to tell you more soon.
>>
>> Regards,
>> Sanne
>>
>>
>>
>>
>> On 8 May 2018 at 09:05, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
>>>
>>> Hi Sanne,
>>>
>>>
>>> **JDK 11 EA build 12 , *****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
>>> https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html
>>>
>>> *Notable changes in JDK 11 EA builds since last email:*
>>>
>>>    * Build 11 - see Release Notes for details.
>>>        o JDK-8201315 : SelectableChannel.register may be invoked while a
>>>          selection operation is in progress
>>>    * Build 10 - see Release Notes for details.
>>>        o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class
>>>        o JDK-8189997 (not public) :  Enhanced KeyStore Mechanisms
>>>        o JDK-8175075 (not public) : 3DES Cipher Suites Disabled
>>>    * Build 9: - see Release Notes for details.
>>>        o JDK-8200152 : KerberosString uses UTF-8 encoding by default
>>>        o JDK-8200458 : Readiness information previously recorded in
>>>          SelectionKey ready set not preserved
>>>
>>> **
>>>
>>>
>>> *Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1]
>>> *
>>> This draft JEP [2] proposes to deprecate the pack200 APIs and tools in
>>> the JDK. As outlined in the JEP, the usefulness of this technology
>>> have diminishing returns, the components using them are being removed
>>> and connectivity speeds have improved by leaps and bounds,
>>> since its inception.  Feedback appreciated via
>>> http://mail.openjdk.java.net/pipermail/jdk-dev
>>>
>>> Regards,
>>> Rory
>>>
>>> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8200752
>>>
>>> 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
>
>
> --
> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+491737185961>
>
> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
> Registergericht: Amtsgericht M?nchen, HRA 95603
>
> Komplement?rin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
>
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment


From steve at hibernate.org  Fri May 11 11:42:56 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 11 May 2018 10:42:56 -0500
Subject: [hibernate-dev] Scheduling issues
Message-ID: <CAFdSV9uZVQhkNWird-xsobHAgKMshKhcuhqaM3JsxzrR+ev6rA@mail.gmail.com>

I am trying to determine where we are with 5.3 Final.  So I look in Jira
and the original 4 issues I added to Final (mainly verification tasks) have
jumped to 19.  This makes it impossible to plan.  So please, if you are not
actively working on an issue or are not planning on finishing it within a
few days do not schedule it for 5.3.0.Final.  Feel free to create a 5.3.1
and schedule it there *if* you are planning on working on it.  If you are
not planning on working on it do not schedule it.

Thanks

From guillaume.smet at gmail.com  Fri May 11 14:02:21 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 11 May 2018 20:02:21 +0200
Subject: [hibernate-dev] Changes to the ORM Travis configuration
Message-ID: <CALt0+o_a1LfAA9A+Ug-sRbKxdyVmac4Cq9JBOBzs2Mq0=uNX9w@mail.gmail.com>

Hi,

I committed a few changes to the ORM Travis configuration to hopefully make
the builds more stable - we had a lot of failures due to timeouts.

As Gradle can spend a lot of time on a specific step without any output,
the ORM jobs often timed out.

I added a travis_wait 45 to allow the Gradle command to run for 45 minutes.
It should be used by the new PRs as soon as you're based on current master.

There is one drawback: you only see the command output when it's either
finished or timed out but I thought you are probably not spending your time
looking at the jobs in progress.

Hopefully, it will help.

-- 
Guillaume

From gbadner at redhat.com  Fri May 11 18:10:01 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 11 May 2018 15:10:01 -0700
Subject: [hibernate-dev] Hibernate ORM 5.1.14.Final released
Message-ID: <CAFDzhiQ9k6jsm6JPfOhrRhw9jTcPcxUKJXH9nndxNHNrx-iboQ@mail.gmail.com>

http://in.relation.to/2018/05/11/hibernate-orm-5114-final-release/

From steve at hibernate.org  Mon May 14 19:47:42 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 14 May 2018 18:47:42 -0500
Subject: [hibernate-dev] Hibernate ORM 5.3.0.Final release
Message-ID: <CAFdSV9utL7q4MOypFcLnTNv=6JkRvQ9maUUX=ZgoWSBCpmR56w@mail.gmail.com>

I am finishing up the 5.3.0.Final release tasks -
http://in.relation.to/2018/05/14/hibernate-orm-530-final-release/

From guillaume.smet at hibernate.org  Tue May 15 09:53:27 2018
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Tue, 15 May 2018 15:53:27 +0200
Subject: [hibernate-dev] Hibernate Validator 6.0.10.Final released
Message-ID: <CALt0+o_zKH8_2n1jZGQ70JcM+wEDq6jJqOFDqrO58nCEdcK_ZQ@mail.gmail.com>

Hi,

We just released Hibernate Validator 6.0.10.Final with some important
bugfixes and a Dutch translation.

More information here:
http://in.relation.to/2018/05/15/hibernate-validator-6010-final-out/ .

Have a nice day.

-- 
Guillaume

From gbadner at redhat.com  Tue May 15 14:52:04 2018
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 15 May 2018 11:52:04 -0700
Subject: [hibernate-dev] Differences in ORM exception handling in 5.1 vs 5.3
Message-ID: <CAFDzhiRMTWA30EYN6HKrWzJMo_2WKX-fFOJrz4y-KhKYzh4OAQ@mail.gmail.com>

I've been looking at differences in Hibernate exception handling for
applications that uses "native" (non-JPA) Hibernate when moving from 5.1 to
5.3.

As you know, exception handling changed in 5.2 when hibernate-entitymanager
was merged into hibernate-core. This change is documented in the 5.2
migration guide. [1]

Here is the relevant text:

"org.hibernate.HibernateException now extends
javax.persistence.PersistenceExceptions.
Hibernate methods that "override" methods from their JPA counterparts now
will also throw various JDK defined RuntimeExceptions (such as
IllegalArgumentException, IllegalStateException, etc) as required by the
JPA contract."

While digging into this, I see that a HibernateException thrown when using
5.1 may, in 5.3, be unwrapped, or may be wrapped by a PersistenceException
(or a subclass), IllegalArgumentException, or IllegalStateException,
depending on the particular operation being performed when the
HibernateException is thrown.

The reason why the exceptions may be wrapped or unwrapped is because
Hibernate converts exceptions  (via
AbstractSharedSessionContract#exceptionConverter)
for JPA operations which may wrap the HibernateException or throw a
different exception. Hibernate does not convert exceptions from strictly
"native" operations, so those exceptions remain unwrapped.

Here are a couple of examples to illustrate:

1) A HibernateException (org.hibernate.TransientObjectException) was thrown
in 5.1. In 5.3, the same condition can result in
org.hibernate.TransientObjectException
that is either unwrapped, or wrapped by IllegalStateException. I've pushed
a test to my fork to illustrate. [2]

Thrown during Session#save, #saveOrUpdate
In 5.1: org.hibernate.TransientObjectException (unwrapped)
In 5.3: org.hibernate.TransientObjectException (unwrapped)

Thrown during Session#persist, #merge, #flush
In 5.1, org.hibernate.TransientObjectException (unwrapped)
In 5.3, org.hibernate.TransientObjectException wrapped by
IllegalStateException

2) A HibernateException thrown when using 5.1 may be wrapped by a
PersistenceException, even though HibernateException already extends
PersistenceException.

For example, see TransactionTimeoutTest#testTransactionTimeoutFailure:
https://github.com/hibernate/hibernate-orm/blob/master/
hibernate-core/src/test/java/org/hibernate/test/tm/
TransactionTimeoutTest.java#L60-L82

The exception thrown by the test indicates that the transaction timed out.
This exception is important enough that an application might retry the
operation, or at least log for future investigation.

Thrown during Session#persist (or when changed to use Session#merge or
Session#flush):
In 5.1: org.hibernate.TransactionException (unwrapped)
In 5.3: org.hibernate.TransactionException wrapped by javax.persistence.
PersistenceException

Thrown if the test is changed to use Session#save or #saveOrUpdate instead:
In 5.1: org.hibernate.TransactionException (unwrapped)
In 5.3: org.hibernate.TransactionException (unwrapped)

Similarly, by adding some logging, I see that HibernateException objects
can be wrapped by PersistenceException when running the 5.3 hibernate-core
unit tests. Depending on the context, I see that some of the following
exceptions can be wrapped or unwrapped.

org.hibernate.exception.ConstraintViolationException
org.hibernate.exception.DataException
org.hibernate.exception.GenericJDBCException
org.hibernate.exception.SQLGrammarException
org.hibernate.id.IdentifierGenerationException
org.hibernate.loader.custom.NonUniqueDiscoveredSqlAliasException
org.hibernate.PersistentObjectException
org.hibernate.PropertyAccessException
org.hibernate.PropertyValueException
org.hibernate.TransactionException

You can see an example using
org.hibernate.exception.ConstraintViolationException
at [3].

In order to deal with these differences, an application could change the
following (which was appropriate for 5.1):

try {
    ...
}
catch (HibernateException ex) {
    procressHibernateException( ex );
}

to the following for 5.3:

try {
    ...
}
catch (PersistenceException | IllegalStateException |
IllegalArgumentException ex) {
    if ( HibernateException.class.isInstance( ex ) ) {
        handleHibernateException( (HibernateException) ex );
    }
    else if ( HibernateException.class.isInstance( ex.getCause() ) ) {
        handleHibernateException( (HibernateException) ex.getCause() );
    }
}

IMO, it's a little clumsy having to deal with both wrapped and unwrapped
exceptions. It would be better if exceptions were consistently wrapped, or
consistently unwrapped.

I haven't had much of a chance to think about how we can deal with this,
but one thing that comes to mind is to allow an application to choose a
particular ExceptionConverter implementation. Hibernate would need to be
changed to always convert exceptions (including for strictly native
operations) before returning to the application.

For example, a property, hibernate.exception_converter could be added with
the following values:

jpa - default for JPA applications (org.hibernate.internal.
ExceptionConverterImpl)
native (or legacy?) - default for native applications  that does not wrap
HibernateException
fully-qualified class name that implements ExceptionConverter

If users have to make changes to exception handling for 5.3, do you think
they would be willing to change their application to use JPA exceptions
(i.e., hibernate.exception_converter=jpa)?

Comments?

Regards,
Gail

[1] https://github.com/hibernate/hibernate-orm/blob/5.2/migration-guide.adoc
[2] https://github.com/gbadner/hibernate-core/blob/exception-
compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
ORMTransientObjectExceptionUnitTestCase.java
[3] https://github.com/gbadner/hibernate-core/blob/exception-
compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
ORMConstraintViolationExceptionUnitTestCase.java

From steve at hibernate.org  Tue May 15 15:21:00 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 15 May 2018 14:21:00 -0500
Subject: [hibernate-dev] Differences in ORM exception handling in 5.1 vs
	5.3
In-Reply-To: <CAFDzhiRMTWA30EYN6HKrWzJMo_2WKX-fFOJrz4y-KhKYzh4OAQ@mail.gmail.com>
References: <CAFDzhiRMTWA30EYN6HKrWzJMo_2WKX-fFOJrz4y-KhKYzh4OAQ@mail.gmail.com>
Message-ID: <CAFdSV9saY2azhP7_jk5eFaLiWN13MbLXJFNS5pFTgTCZ_U7jUg@mail.gmail.com>

I'd really rather not get into supporting arbitrary ExceptionConverter
strategies.. JPA-compliant and then "native"-compliant are plenty.

I thought we had added a `hibernate.jpa.compliance.exception` setting, but
I see it is not there.



On Tue, May 15, 2018 at 1:52 PM Gail Badner <gbadner at redhat.com> wrote:

> I've been looking at differences in Hibernate exception handling for
> applications that uses "native" (non-JPA) Hibernate when moving from 5.1 to
> 5.3.
>
> As you know, exception handling changed in 5.2 when
> hibernate-entitymanager was merged into hibernate-core. This change is
> documented in the 5.2 migration guide. [1]
>
> Here is the relevant text:
>
> "org.hibernate.HibernateException now extends
> javax.persistence.PersistenceExceptions. Hibernate methods that "override"
> methods from their JPA counterparts now will also throw various JDK defined
> RuntimeExceptions (such as IllegalArgumentException, IllegalStateException,
> etc) as required by the JPA contract."
>
> While digging into this, I see that a HibernateException thrown when using
> 5.1 may, in 5.3, be unwrapped, or may be wrapped by a PersistenceException
> (or a subclass), IllegalArgumentException, or IllegalStateException,
> depending on the particular operation being performed when the
> HibernateException is thrown.
>
> The reason why the exceptions may be wrapped or unwrapped is because
> Hibernate converts exceptions  (via
> AbstractSharedSessionContract#exceptionConverter) for JPA operations which
> may wrap the HibernateException or throw a different exception. Hibernate
> does not convert exceptions from strictly "native" operations, so those
> exceptions remain unwrapped.
>
> Here are a couple of examples to illustrate:
>
> 1) A HibernateException (org.hibernate.TransientObjectException) was
> thrown in 5.1. In 5.3, the same condition can result in
> org.hibernate.TransientObjectException that is either unwrapped, or wrapped
> by IllegalStateException. I've pushed a test to my fork to illustrate. [2]
>
> Thrown during Session#save, #saveOrUpdate
> In 5.1: org.hibernate.TransientObjectException (unwrapped)
> In 5.3: org.hibernate.TransientObjectException (unwrapped)
>
> Thrown during Session#persist, #merge, #flush
> In 5.1, org.hibernate.TransientObjectException (unwrapped)
> In 5.3, org.hibernate.TransientObjectException wrapped by
> IllegalStateException
>
> 2) A HibernateException thrown when using 5.1 may be wrapped by a
> PersistenceException, even though HibernateException already extends
> PersistenceException.
>
> For example, see TransactionTimeoutTest#testTransactionTimeoutFailure:
>
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/test/tm/TransactionTimeoutTest.java#L60-L82
>
> The exception thrown by the test indicates that the transaction timed out.
> This exception is important enough that an application might retry the
> operation, or at least log for future investigation.
>
> Thrown during Session#persist (or when changed to use Session#merge or
> Session#flush):
> In 5.1: org.hibernate.TransactionException (unwrapped)
> In 5.3: org.hibernate.TransactionException wrapped by
> javax.persistence.PersistenceException
>
> Thrown if the test is changed to use Session#save or #saveOrUpdate instead:
> In 5.1: org.hibernate.TransactionException (unwrapped)
> In 5.3: org.hibernate.TransactionException (unwrapped)
>
> Similarly, by adding some logging, I see that HibernateException objects
> can be wrapped by PersistenceException when running the 5.3 hibernate-core
> unit tests. Depending on the context, I see that some of the following
> exceptions can be wrapped or unwrapped.
>
> org.hibernate.exception.ConstraintViolationException
> org.hibernate.exception.DataException
> org.hibernate.exception.GenericJDBCException
> org.hibernate.exception.SQLGrammarException
> org.hibernate.id.IdentifierGenerationException
> org.hibernate.loader.custom.NonUniqueDiscoveredSqlAliasException
> org.hibernate.PersistentObjectException
> org.hibernate.PropertyAccessException
> org.hibernate.PropertyValueException
> org.hibernate.TransactionException
>
> You can see an example using
> org.hibernate.exception.ConstraintViolationException at [3].
>
> In order to deal with these differences, an application could change the
> following (which was appropriate for 5.1):
>
> try {
>     ...
> }
> catch (HibernateException ex) {
>     procressHibernateException( ex );
> }
>
> to the following for 5.3:
>
> try {
>     ...
> }
> catch (PersistenceException | IllegalStateException |
> IllegalArgumentException ex) {
>     if ( HibernateException.class.isInstance( ex ) ) {
>         handleHibernateException( (HibernateException) ex );
>     }
>     else if ( HibernateException.class.isInstance( ex.getCause() ) ) {
>         handleHibernateException( (HibernateException) ex.getCause() );
>     }
> }
>
> IMO, it's a little clumsy having to deal with both wrapped and unwrapped
> exceptions. It would be better if exceptions were consistently wrapped, or
> consistently unwrapped.
>
> I haven't had much of a chance to think about how we can deal with this,
> but one thing that comes to mind is to allow an application to choose a
> particular ExceptionConverter implementation. Hibernate would need to be
> changed to always convert exceptions (including for strictly native
> operations) before returning to the application.
>
> For example, a property, hibernate.exception_converter could be added with
> the following values:
>
> jpa - default for JPA applications
> (org.hibernate.internal.ExceptionConverterImpl)
> native (or legacy?) - default for native applications  that does not wrap
> HibernateException
> fully-qualified class name that implements ExceptionConverter
>
> If users have to make changes to exception handling for 5.3, do you think
> they would be willing to change their application to use JPA exceptions
> (i.e., hibernate.exception_converter=jpa)?
>
> Comments?
>
> Regards,
> Gail
>
> [1]
> https://github.com/hibernate/hibernate-orm/blob/5.2/migration-guide.adoc
> [2]
> https://github.com/gbadner/hibernate-core/blob/exception-compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/ORMTransientObjectExceptionUnitTestCase.java
> [3]
> https://github.com/gbadner/hibernate-core/blob/exception-compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/ORMConstraintViolationExceptionUnitTestCase.java
>
>
>

From postmaster at lists.jboss.org  Wed May 16 02:58:24 2018
From: postmaster at lists.jboss.org (MAILER-DAEMON)
Date: Wed, 16 May 2018 14:58:24 +0800
Subject: [hibernate-dev] Mail System Error - Returned Mail
Message-ID: <201805160700.w4G701Iu003239@lists01.dmz-a.mwc.hst.phx2.redhat.com>

<?>?y????W????<jr?R??e??8n??rn?I?????S????)"pt?????yT
???qxk??y?Zx]t????b?^??r???b??U???0l{??4??
??M??XE?A#???XO%?~?????\?|-U???5o:?.~K??&???T?????Z?]F?q?????%??y?iV?????b???????md?n???:?}???m"L??h
rI?????Qp:??K??\$?H?,??)??V0???t?3Mn ??_0??b???{??<~??zNpB?&Y
B?v>!#A;?Q?rZ6????c????? ?\?-??????\
?u&&??sV???\??z?}???`????bX???pTAk?J??:,y????qq){???3X?%;]:d??!t??l??v??C-p???J??!&X?;m;u?-_*>??
???iOr1?0???h6??U??TJ?w)???_1?[C2b
?????g?5s,??Wy?SR??{?r?l6???K?'C9A??????r?jP?Q??^Z;???????M???????H???5?M?????????
%, G?i???Q
???)H??3zl1???-??q?3v??-?-??9??f?v3?aP????


From mihalcea.vlad at gmail.com  Wed May 16 07:33:38 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 16 May 2018 14:33:38 +0300
Subject: [hibernate-dev] Simplify SQL function registration when
	bootstrapping via JPA
Message-ID: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>

Hi,

I realized that only the native Hibernate bootstrapping mechanism allows
for passing custom SQL functions.

For JPA, we can extend the Dialect to register, but that's not always
desirable as it requires a code change
every time the user switches to a new Dialect version.

For this reason, I created this Jira issue:

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

Let me know if anyone has anything against implementing this feature.

Vlad

From steve at hibernate.org  Wed May 16 07:41:34 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 16 May 2018 06:41:34 -0500
Subject: [hibernate-dev] Simplify SQL function registration when
 bootstrapping via JPA
In-Reply-To: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>
References: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>
Message-ID: <CAFdSV9uQZ6f7HMw1kPBcuNpySV1GF1E2mLu9uZh9Y+mBWtWJog@mail.gmail.com>

This should maybe wait for 6.0.  We are ditching SQLFunction in favor of a
more AST-friendly contract.

Beyond that, go for it.


On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> Hi,
>
> I realized that only the native Hibernate bootstrapping mechanism allows
> for passing custom SQL functions.
>
> For JPA, we can extend the Dialect to register, but that's not always
> desirable as it requires a code change
> every time the user switches to a new Dialect version.
>
> For this reason, I created this Jira issue:
>
> https://hibernate.atlassian.net/browse/HHH-12589
>
> Let me know if anyone has anything against implementing this feature.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed May 16 07:51:04 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 16 May 2018 14:51:04 +0300
Subject: [hibernate-dev] Simplify SQL function registration when
 bootstrapping via JPA
In-Reply-To: <CAFdSV9uQZ6f7HMw1kPBcuNpySV1GF1E2mLu9uZh9Y+mBWtWJog@mail.gmail.com>
References: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>
	<CAFdSV9uQZ6f7HMw1kPBcuNpySV1GF1E2mLu9uZh9Y+mBWtWJog@mail.gmail.com>
Message-ID: <CA+gWKMDb9F5B-UMM8YH_UZw5PtOryFdN5-D6SLy3dCYJ2MtcCQ@mail.gmail.com>

I suppose this will be refactored considerably in 6.x.

However, it's just a small change and I don't think it will hinder any 6.x
changes.

I'm thinking of defining an SqlFunctionContributor interface
(@FunctionalInterface)
which can be provided via the properties  Map that's supplied when using
the Persistence#createEntityManagerFactory method.

In EntityManagerFactoryBuilder, I can just inspect that and pass it further
to MetamodelBuilder.

So, it does not take any effort to implement it and users can benefit from
it. I recently answered a question on the forum on this topic:

https://discourse.hibernate.org/t/i-cant-use-group-concat-in-queries/752/14

And, realized that I was wrong about suggesting doing it via the Integrator
mechanism (since the Metamodel is already frozen by the time we execute the
Integrator).

Vlad

On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole <steve at hibernate.org> wrote:

> This should maybe wait for 6.0.  We are ditching SQLFunction in favor of a
> more AST-friendly contract.
>
> Beyond that, go for it.
>
>
> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> I realized that only the native Hibernate bootstrapping mechanism allows
>> for passing custom SQL functions.
>>
>> For JPA, we can extend the Dialect to register, but that's not always
>> desirable as it requires a code change
>> every time the user switches to a new Dialect version.
>>
>> For this reason, I created this Jira issue:
>>
>> https://hibernate.atlassian.net/browse/HHH-12589
>>
>> Let me know if anyone has anything against implementing this feature.
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Wed May 16 08:55:57 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 16 May 2018 07:55:57 -0500
Subject: [hibernate-dev] Simplify SQL function registration when
 bootstrapping via JPA
In-Reply-To: <CA+gWKMDb9F5B-UMM8YH_UZw5PtOryFdN5-D6SLy3dCYJ2MtcCQ@mail.gmail.com>
References: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>
	<CAFdSV9uQZ6f7HMw1kPBcuNpySV1GF1E2mLu9uZh9Y+mBWtWJog@mail.gmail.com>
	<CA+gWKMDb9F5B-UMM8YH_UZw5PtOryFdN5-D6SLy3dCYJ2MtcCQ@mail.gmail.com>
Message-ID: <CAFdSV9uO6oeELSh52Bad9ik3VSrCydinPjw6DiefmPK4Krd_5w@mail.gmail.com>

Its not so much hindering 6.0 that I am concerned with.  The problem is
updatability for the user.  The more things they use that change = the more
work to upgrade.

On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I suppose this will be refactored considerably in 6.x.
>
> However, it's just a small change and I don't think it will hinder any 6.x
> changes.
>
> I'm thinking of defining an SqlFunctionContributor interface
> (@FunctionalInterface)
> which can be provided via the properties  Map that's supplied when using
> the Persistence#createEntityManagerFactory method.
>
> In EntityManagerFactoryBuilder, I can just inspect that and pass it
> further to MetamodelBuilder.
>
> So, it does not take any effort to implement it and users can benefit from
> it. I recently answered a question on the forum on this topic:
>
> https://discourse.hibernate.org/t/i-cant-use-group-concat-in-queries/752/14
>
> And, realized that I was wrong about suggesting doing it via the
> Integrator mechanism (since the Metamodel is already frozen by the time we
> execute the Integrator).
>
> Vlad
>
> On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> This should maybe wait for 6.0.  We are ditching SQLFunction in favor of
>> a more AST-friendly contract.
>>
>> Beyond that, go for it.
>>
>>
>> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I realized that only the native Hibernate bootstrapping mechanism allows
>>> for passing custom SQL functions.
>>>
>>> For JPA, we can extend the Dialect to register, but that's not always
>>> desirable as it requires a code change
>>> every time the user switches to a new Dialect version.
>>>
>>> For this reason, I created this Jira issue:
>>>
>>> https://hibernate.atlassian.net/browse/HHH-12589
>>>
>>> Let me know if anyone has anything against implementing this feature.
>>>
>>> Vlad
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>

From gbadner at redhat.com  Thu May 17 01:34:16 2018
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 16 May 2018 22:34:16 -0700
Subject: [hibernate-dev] Cache region names are not prefixed in 5.3
Message-ID: <CAFDzhiS4YA4X6HSSwsni96Sn-=JOqZhOJXc1dxf6EZFJYWaq5Q@mail.gmail.com>

I see that cache region names are not being prefixed in 5.3.

EnabledCaching sets the TimestampsRegion region name
to TimestampsRegion.class.getName(), and sets the QueryResultsRegion region
name to QueryResultsRegion.class.getName(). [1]

Without a prefix, WildFly is failing intermittently when there are 2
persistence units with the query cache enabled due to:

org.infinispan.commons.CacheConfigurationException: ISPN000453: Attempt to
define configuration for cache org.hibernate.cache.spi.TimestampsRegion
which already exists

Entity region names are not being prefixed either.

Should they be prefixed by Hibernate or by the RegionFactory?

Regards,
Gail

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92

From yoann at hibernate.org  Thu May 17 03:30:29 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Thu, 17 May 2018 09:30:29 +0200
Subject: [hibernate-dev] Hibernate Search 5.10.0.Final released
Message-ID: <CAEqagpq+10+GMoaQDon_AgmOeJM6YgW2WMna0dQsASwGYFMYLg@mail.gmail.com>

Hello,

We just published Hibernate Search 5.10.0.Final, the first stable release
in the 5.10 branch. This release mainly brings an upgrade to Hibernate ORM
5.3 and JPA 2.2, but also an integration to dependency injection frameworks
through Hibernate ORM 5.3, an upgrade to WildFly 12 and JGroups 4, and Java
9 automatic module names.

Check out our blog for more information about this release:

http://in.relation.to/2018/05/17/hibernate-search-5-10-0-Final/
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From mihalcea.vlad at gmail.com  Thu May 17 05:20:16 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 17 May 2018 12:20:16 +0300
Subject: [hibernate-dev] Simplify SQL function registration when
 bootstrapping via JPA
In-Reply-To: <CAFdSV9uO6oeELSh52Bad9ik3VSrCydinPjw6DiefmPK4Krd_5w@mail.gmail.com>
References: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>
	<CAFdSV9uQZ6f7HMw1kPBcuNpySV1GF1E2mLu9uZh9Y+mBWtWJog@mail.gmail.com>
	<CA+gWKMDb9F5B-UMM8YH_UZw5PtOryFdN5-D6SLy3dCYJ2MtcCQ@mail.gmail.com>
	<CAFdSV9uO6oeELSh52Bad9ik3VSrCydinPjw6DiefmPK4Krd_5w@mail.gmail.com>
Message-ID: <CA+gWKMCEAxyDBNKhG0LUnLpsJZ3ZBob3K=z-Sd51m7iTueg8Gg@mail.gmail.com>

In the end, I thought of a more generic approach to for JPA bootstrapping
which, not only allows us to register SqlFunctions, but we can apply other
changes on the MetadataBuilder object used during bootstrap.

This is the Pull Request:

https://github.com/hibernate/hibernate-orm/pull/2288

Let me know what you think.

Vlad

On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Its not so much hindering 6.0 that I am concerned with.  The problem is
> updatability for the user.  The more things they use that change = the more
> work to upgrade.
>
> On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> I suppose this will be refactored considerably in 6.x.
>>
>> However, it's just a small change and I don't think it will hinder any
>> 6.x changes.
>>
>> I'm thinking of defining an SqlFunctionContributor interface
>> (@FunctionalInterface)
>> which can be provided via the properties  Map that's supplied when using
>> the Persistence#createEntityManagerFactory method.
>>
>> In EntityManagerFactoryBuilder, I can just inspect that and pass it
>> further to MetamodelBuilder.
>>
>> So, it does not take any effort to implement it and users can benefit
>> from it. I recently answered a question on the forum on this topic:
>>
>> https://discourse.hibernate.org/t/i-cant-use-group-concat-
>> in-queries/752/14
>>
>> And, realized that I was wrong about suggesting doing it via the
>> Integrator mechanism (since the Metamodel is already frozen by the time we
>> execute the Integrator).
>>
>> Vlad
>>
>> On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> This should maybe wait for 6.0.  We are ditching SQLFunction in favor of
>>> a more AST-friendly contract.
>>>
>>> Beyond that, go for it.
>>>
>>>
>>> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I realized that only the native Hibernate bootstrapping mechanism allows
>>>> for passing custom SQL functions.
>>>>
>>>> For JPA, we can extend the Dialect to register, but that's not always
>>>> desirable as it requires a code change
>>>> every time the user switches to a new Dialect version.
>>>>
>>>> For this reason, I created this Jira issue:
>>>>
>>>> https://hibernate.atlassian.net/browse/HHH-12589
>>>>
>>>> Let me know if anyone has anything against implementing this feature.
>>>>
>>>> Vlad
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>

From sanne at hibernate.org  Thu May 17 06:11:15 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 17 May 2018 11:11:15 +0100
Subject: [hibernate-dev] Cache region names are not prefixed in 5.3
In-Reply-To: <CAFDzhiS4YA4X6HSSwsni96Sn-=JOqZhOJXc1dxf6EZFJYWaq5Q@mail.gmail.com>
References: <CAFDzhiS4YA4X6HSSwsni96Sn-=JOqZhOJXc1dxf6EZFJYWaq5Q@mail.gmail.com>
Message-ID: <CAFm4XO29YAVEpzEr7M4B_CQHFbDPMSuPTiD=o4_trgBUiANFzA@mail.gmail.com>

I think this is the RegionFactory's responsibility, as Hibernate ORM
alone can't know if this is necessary.

Prefixing is one of many options to isolate caches; a Cache technology
might wish to use a different approach by implementing a custom
`org.hibernate.cache.spi.CacheKeysFactory`.

Not least the server / deployer might be able to hint the Cache
provider to tell if isolation is at all necessary.

In conclusion, by having Hibernate ORM not messing with prefixes
allows other technologies to implement more efficient solutions. Our
own code also ends up being more efficient by not needing to add a
prefix during each and every access to the cache.

Thanks,
Sanne

On 17 May 2018 at 06:34, Gail Badner <gbadner at redhat.com> wrote:
> I see that cache region names are not being prefixed in 5.3.
>
> EnabledCaching sets the TimestampsRegion region name
> to TimestampsRegion.class.getName(), and sets the QueryResultsRegion region
> name to QueryResultsRegion.class.getName(). [1]
>
> Without a prefix, WildFly is failing intermittently when there are 2
> persistence units with the query cache enabled due to:
>
> org.infinispan.commons.CacheConfigurationException: ISPN000453: Attempt to
> define configuration for cache org.hibernate.cache.spi.TimestampsRegion
> which already exists
>
> Entity region names are not being prefixed either.
>
> Should they be prefixed by Hibernate or by the RegionFactory?
>
> Regards,
> Gail
>
> [1]
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Thu May 17 06:23:09 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 17 May 2018 11:23:09 +0100
Subject: [hibernate-dev] Cache region names are not prefixed in 5.3
In-Reply-To: <CAFm4XO29YAVEpzEr7M4B_CQHFbDPMSuPTiD=o4_trgBUiANFzA@mail.gmail.com>
References: <CAFDzhiS4YA4X6HSSwsni96Sn-=JOqZhOJXc1dxf6EZFJYWaq5Q@mail.gmail.com>
	<CAFm4XO29YAVEpzEr7M4B_CQHFbDPMSuPTiD=o4_trgBUiANFzA@mail.gmail.com>
Message-ID: <CAFm4XO3BMjQ--e5xc2azge7YcLZ__1rbN-bDj6GyLLiohj8OdA@mail.gmail.com>

On 17 May 2018 at 11:11, Sanne Grinovero <sanne at hibernate.org> wrote:
> I think this is the RegionFactory's responsibility, as Hibernate ORM
> alone can't know if this is necessary.
>
> Prefixing is one of many options to isolate caches; a Cache technology
> might wish to use a different approach by implementing a custom
> `org.hibernate.cache.spi.CacheKeysFactory`.

Hum, I regret how I wrote the above paragraph.

I actually meant that a Cache technology could implement isolation in
many different ways.
Using a custom `CacheKeysFactory` is just an example, there are many
other options as well. In fact, I believe a good choice for
application servers would be to have an independent CacheManager for
each deployment. Then it can safely inspect the deployment, see if
there are multiple Persistence Units using the same caching
technology, and implement further isolation only if necessary.

These thoughts are a consequence of a chat I had with Paul Ferraro
from the WildFly team, as he mentioned the size of the keys becoming
problematic with all the additional prefixing they need to apply. I
hope this will make it possible to e.g. create an "as small as
possible" unique identifier for the deployments to replace the
deployment name during serialization (to identify the CacheManager)
followed by a numeric id indexing the PUs within the deployment - or
nothing altogether in case of single PUs.

Of course, I don't expect that to be needed right away; the
RegionFactory could just do good old prefixing for now but I hope
we'll explore such improvements in the near future.

Thanks,
Sanne

>
> Not least the server / deployer might be able to hint the Cache
> provider to tell if isolation is at all necessary.
>
> In conclusion, by having Hibernate ORM not messing with prefixes
> allows other technologies to implement more efficient solutions. Our
> own code also ends up being more efficient by not needing to add a
> prefix during each and every access to the cache.
>
> Thanks,
> Sanne
>
> On 17 May 2018 at 06:34, Gail Badner <gbadner at redhat.com> wrote:
>> I see that cache region names are not being prefixed in 5.3.
>>
>> EnabledCaching sets the TimestampsRegion region name
>> to TimestampsRegion.class.getName(), and sets the QueryResultsRegion region
>> name to QueryResultsRegion.class.getName(). [1]
>>
>> Without a prefix, WildFly is failing intermittently when there are 2
>> persistence units with the query cache enabled due to:
>>
>> org.infinispan.commons.CacheConfigurationException: ISPN000453: Attempt to
>> define configuration for cache org.hibernate.cache.spi.TimestampsRegion
>> which already exists
>>
>> Entity region names are not being prefixed either.
>>
>> Should they be prefixed by Hibernate or by the RegionFactory?
>>
>> Regards,
>> Gail
>>
>> [1]
>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From rvansa at redhat.com  Thu May 17 07:09:00 2018
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 17 May 2018 13:09:00 +0200
Subject: [hibernate-dev] Cache region names are not prefixed in 5.3
In-Reply-To: <CAFm4XO3BMjQ--e5xc2azge7YcLZ__1rbN-bDj6GyLLiohj8OdA@mail.gmail.com>
References: <CAFDzhiS4YA4X6HSSwsni96Sn-=JOqZhOJXc1dxf6EZFJYWaq5Q@mail.gmail.com>
	<CAFm4XO29YAVEpzEr7M4B_CQHFbDPMSuPTiD=o4_trgBUiANFzA@mail.gmail.com>
	<CAFm4XO3BMjQ--e5xc2azge7YcLZ__1rbN-bDj6GyLLiohj8OdA@mail.gmail.com>
Message-ID: <6a55397b-14d6-5484-219f-1e93e5c5d45b@redhat.com>

I basically agree with Sanne here that having the prefix isolated opens 
space for performance improvements, though if certain call is prefixed, 
RegionFactory can always drop that prefix. The important thing is to 
mention if the region name is prefixed or not in javadocs. I would also 
prefer if *all* region names that RegionFactory is supposed to access 
followed the same strategy (prefixed/not-prefixed).

5.1 included method

 ??? QueryResultsRegion buildQueryResultsRegion(String regionName, 
Properties properties)

where StandardQueryCache did the prefix for us, the change in 5.3 to

 ??? QueryResultsRegion buildQueryResultsRegion(String regionName, 
SessionFactoryImplementor sessionFactory)

does not indicate that the prefix won't be there and the javadoc is 
missing completely.

Also, DomainDataRegionConfig.getRegionName() has no javadoc and 
RegionFactory does not add the prefix.

@Steve could you please amend the javadoc and confirm if RF should 
prefix region names?

@Sanne while cache manager per deployment is an obvious way to 
distinguish regions at deployments, CM holds some heavy resources (e.g. 
threads) - so I while we are supposed to scale number of caches up to 
thousands (and we've fixed some problems that arise when you have for 
example ~3k caches), ATM you're not supposed to scale CMs. And I don't 
think that we'll focus in this direction since the bright future lies in 
microservices :)

Radim

On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
> On 17 May 2018 at 11:11, Sanne Grinovero <sanne at hibernate.org> wrote:
>> I think this is the RegionFactory's responsibility, as Hibernate ORM
>> alone can't know if this is necessary.
>>
>> Prefixing is one of many options to isolate caches; a Cache technology
>> might wish to use a different approach by implementing a custom
>> `org.hibernate.cache.spi.CacheKeysFactory`.
> Hum, I regret how I wrote the above paragraph.
>
> I actually meant that a Cache technology could implement isolation in
> many different ways.
> Using a custom `CacheKeysFactory` is just an example, there are many
> other options as well. In fact, I believe a good choice for
> application servers would be to have an independent CacheManager for
> each deployment. Then it can safely inspect the deployment, see if
> there are multiple Persistence Units using the same caching
> technology, and implement further isolation only if necessary.
>
> These thoughts are a consequence of a chat I had with Paul Ferraro
> from the WildFly team, as he mentioned the size of the keys becoming
> problematic with all the additional prefixing they need to apply. I
> hope this will make it possible to e.g. create an "as small as
> possible" unique identifier for the deployments to replace the
> deployment name during serialization (to identify the CacheManager)
> followed by a numeric id indexing the PUs within the deployment - or
> nothing altogether in case of single PUs.
>
> Of course, I don't expect that to be needed right away; the
> RegionFactory could just do good old prefixing for now but I hope
> we'll explore such improvements in the near future.
>
> Thanks,
> Sanne
>
>> Not least the server / deployer might be able to hint the Cache
>> provider to tell if isolation is at all necessary.
>>
>> In conclusion, by having Hibernate ORM not messing with prefixes
>> allows other technologies to implement more efficient solutions. Our
>> own code also ends up being more efficient by not needing to add a
>> prefix during each and every access to the cache.
>>
>> Thanks,
>> Sanne
>>
>> On 17 May 2018 at 06:34, Gail Badner <gbadner at redhat.com> wrote:
>>> I see that cache region names are not being prefixed in 5.3.
>>>
>>> EnabledCaching sets the TimestampsRegion region name
>>> to TimestampsRegion.class.getName(), and sets the QueryResultsRegion region
>>> name to QueryResultsRegion.class.getName(). [1]
>>>
>>> Without a prefix, WildFly is failing intermittently when there are 2
>>> persistence units with the query cache enabled due to:
>>>
>>> org.infinispan.commons.CacheConfigurationException: ISPN000453: Attempt to
>>> define configuration for cache org.hibernate.cache.spi.TimestampsRegion
>>> which already exists
>>>
>>> Entity region names are not being prefixed either.
>>>
>>> Should they be prefixed by Hibernate or by the RegionFactory?
>>>
>>> Regards,
>>> Gail
>>>
>>> [1]
>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


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


From sanne at hibernate.org  Thu May 17 07:55:34 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 17 May 2018 12:55:34 +0100
Subject: [hibernate-dev] Cache region names are not prefixed in 5.3
In-Reply-To: <6a55397b-14d6-5484-219f-1e93e5c5d45b@redhat.com>
References: <CAFDzhiS4YA4X6HSSwsni96Sn-=JOqZhOJXc1dxf6EZFJYWaq5Q@mail.gmail.com>
	<CAFm4XO29YAVEpzEr7M4B_CQHFbDPMSuPTiD=o4_trgBUiANFzA@mail.gmail.com>
	<CAFm4XO3BMjQ--e5xc2azge7YcLZ__1rbN-bDj6GyLLiohj8OdA@mail.gmail.com>
	<6a55397b-14d6-5484-219f-1e93e5c5d45b@redhat.com>
Message-ID: <CAFm4XO2AuHb5xH10C16qQN6Ws+s1e3bi8wmieZ9POVEqyOMDtw@mail.gmail.com>

On 17 May 2018 at 12:09, Radim Vansa <rvansa at redhat.com> wrote:
> I basically agree with Sanne here that having the prefix isolated opens
> space for performance improvements, though if certain call is prefixed,
> RegionFactory can always drop that prefix. The important thing is to mention
> if the region name is prefixed or not in javadocs. I would also prefer if
> *all* region names that RegionFactory is supposed to access followed the
> same strategy (prefixed/not-prefixed).
>
> 5.1 included method
>
>     QueryResultsRegion buildQueryResultsRegion(String regionName, Properties
> properties)
>
> where StandardQueryCache did the prefix for us, the change in 5.3 to
>
>     QueryResultsRegion buildQueryResultsRegion(String regionName,
> SessionFactoryImplementor sessionFactory)
>
> does not indicate that the prefix won't be there and the javadoc is missing
> completely.
>
> Also, DomainDataRegionConfig.getRegionName() has no javadoc and
> RegionFactory does not add the prefix.
>
> @Steve could you please amend the javadoc and confirm if RF should prefix
> region names?
>
> @Sanne while cache manager per deployment is an obvious way to distinguish
> regions at deployments, CM holds some heavy resources (e.g. threads) - so I
> while we are supposed to scale number of caches up to thousands (and we've
> fixed some problems that arise when you have for example ~3k caches), ATM
> you're not supposed to scale CMs. And I don't think that we'll focus in this
> direction since the bright future lies in microservices :)

Right, good points. It's a possible optimization I'd like to see
eventually but it's not trivial to get there yet.

Yet assuming a microservices scenario, this does become trivial to
benefit from: the container knows there's a single deployment, a
single CM. So no need to isolate them at all, just need to possibly
isolate multiple PUs defined in the same service.

So it will be easy to run hundreds of isolated microservices on the
same physical CPU and kill each other via process contention :P

>
> Radim
>
>
> On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
>>
>> On 17 May 2018 at 11:11, Sanne Grinovero <sanne at hibernate.org> wrote:
>>>
>>> I think this is the RegionFactory's responsibility, as Hibernate ORM
>>> alone can't know if this is necessary.
>>>
>>> Prefixing is one of many options to isolate caches; a Cache technology
>>> might wish to use a different approach by implementing a custom
>>> `org.hibernate.cache.spi.CacheKeysFactory`.
>>
>> Hum, I regret how I wrote the above paragraph.
>>
>> I actually meant that a Cache technology could implement isolation in
>> many different ways.
>> Using a custom `CacheKeysFactory` is just an example, there are many
>> other options as well. In fact, I believe a good choice for
>> application servers would be to have an independent CacheManager for
>> each deployment. Then it can safely inspect the deployment, see if
>> there are multiple Persistence Units using the same caching
>> technology, and implement further isolation only if necessary.
>>
>> These thoughts are a consequence of a chat I had with Paul Ferraro
>> from the WildFly team, as he mentioned the size of the keys becoming
>> problematic with all the additional prefixing they need to apply. I
>> hope this will make it possible to e.g. create an "as small as
>> possible" unique identifier for the deployments to replace the
>> deployment name during serialization (to identify the CacheManager)
>> followed by a numeric id indexing the PUs within the deployment - or
>> nothing altogether in case of single PUs.
>>
>> Of course, I don't expect that to be needed right away; the
>> RegionFactory could just do good old prefixing for now but I hope
>> we'll explore such improvements in the near future.
>>
>> Thanks,
>> Sanne
>>
>>> Not least the server / deployer might be able to hint the Cache
>>> provider to tell if isolation is at all necessary.
>>>
>>> In conclusion, by having Hibernate ORM not messing with prefixes
>>> allows other technologies to implement more efficient solutions. Our
>>> own code also ends up being more efficient by not needing to add a
>>> prefix during each and every access to the cache.
>>>
>>> Thanks,
>>> Sanne
>>>
>>> On 17 May 2018 at 06:34, Gail Badner <gbadner at redhat.com> wrote:
>>>>
>>>> I see that cache region names are not being prefixed in 5.3.
>>>>
>>>> EnabledCaching sets the TimestampsRegion region name
>>>> to TimestampsRegion.class.getName(), and sets the QueryResultsRegion
>>>> region
>>>> name to QueryResultsRegion.class.getName(). [1]
>>>>
>>>> Without a prefix, WildFly is failing intermittently when there are 2
>>>> persistence units with the query cache enabled due to:
>>>>
>>>> org.infinispan.commons.CacheConfigurationException: ISPN000453: Attempt
>>>> to
>>>> define configuration for cache org.hibernate.cache.spi.TimestampsRegion
>>>> which already exists
>>>>
>>>> Entity region names are not being prefixed either.
>>>>
>>>> Should they be prefixed by Hibernate or by the RegionFactory?
>>>>
>>>> Regards,
>>>> Gail
>>>>
>>>> [1]
>>>>
>>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>

From christian.beikov at gmail.com  Thu May 17 10:22:20 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 17 May 2018 16:22:20 +0200
Subject: [hibernate-dev] Simplify SQL function registration when
 bootstrapping via JPA
In-Reply-To: <CA+gWKMCEAxyDBNKhG0LUnLpsJZ3ZBob3K=z-Sd51m7iTueg8Gg@mail.gmail.com>
References: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>
	<CAFdSV9uQZ6f7HMw1kPBcuNpySV1GF1E2mLu9uZh9Y+mBWtWJog@mail.gmail.com>
	<CA+gWKMDb9F5B-UMM8YH_UZw5PtOryFdN5-D6SLy3dCYJ2MtcCQ@mail.gmail.com>
	<CAFdSV9uO6oeELSh52Bad9ik3VSrCydinPjw6DiefmPK4Krd_5w@mail.gmail.com>
	<CA+gWKMCEAxyDBNKhG0LUnLpsJZ3ZBob3K=z-Sd51m7iTueg8Gg@mail.gmail.com>
Message-ID: <69110219-7c69-a82b-675d-1a5dd2f3902e@gmail.com>

It looks ok to me although I'm not sure if it wouldn't be more 
appropriate to instantiate the contributor via ManagedBeanRegistry.


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea:
> In the end, I thought of a more generic approach to for JPA bootstrapping
> which, not only allows us to register SqlFunctions, but we can apply other
> changes on the MetadataBuilder object used during bootstrap.
>
> This is the Pull Request:
>
> https://github.com/hibernate/hibernate-orm/pull/2288
>
> Let me know what you think.
>
> Vlad
>
> On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Its not so much hindering 6.0 that I am concerned with.  The problem is
>> updatability for the user.  The more things they use that change = the more
>> work to upgrade.
>>
>> On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> I suppose this will be refactored considerably in 6.x.
>>>
>>> However, it's just a small change and I don't think it will hinder any
>>> 6.x changes.
>>>
>>> I'm thinking of defining an SqlFunctionContributor interface
>>> (@FunctionalInterface)
>>> which can be provided via the properties  Map that's supplied when using
>>> the Persistence#createEntityManagerFactory method.
>>>
>>> In EntityManagerFactoryBuilder, I can just inspect that and pass it
>>> further to MetamodelBuilder.
>>>
>>> So, it does not take any effort to implement it and users can benefit
>>> from it. I recently answered a question on the forum on this topic:
>>>
>>> https://discourse.hibernate.org/t/i-cant-use-group-concat-
>>> in-queries/752/14
>>>
>>> And, realized that I was wrong about suggesting doing it via the
>>> Integrator mechanism (since the Metamodel is already frozen by the time we
>>> execute the Integrator).
>>>
>>> Vlad
>>>
>>> On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> This should maybe wait for 6.0.  We are ditching SQLFunction in favor of
>>>> a more AST-friendly contract.
>>>>
>>>> Beyond that, go for it.
>>>>
>>>>
>>>> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I realized that only the native Hibernate bootstrapping mechanism allows
>>>>> for passing custom SQL functions.
>>>>>
>>>>> For JPA, we can extend the Dialect to register, but that's not always
>>>>> desirable as it requires a code change
>>>>> every time the user switches to a new Dialect version.
>>>>>
>>>>> For this reason, I created this Jira issue:
>>>>>
>>>>> https://hibernate.atlassian.net/browse/HHH-12589
>>>>>
>>>>> Let me know if anyone has anything against implementing this feature.
>>>>>
>>>>> Vlad
>>>>> _______________________________________________
>>>>> 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 mihalcea.vlad at gmail.com  Thu May 17 10:49:21 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 17 May 2018 17:49:21 +0300
Subject: [hibernate-dev] Simplify SQL function registration when
 bootstrapping via JPA
In-Reply-To: <69110219-7c69-a82b-675d-1a5dd2f3902e@gmail.com>
References: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>
	<CAFdSV9uQZ6f7HMw1kPBcuNpySV1GF1E2mLu9uZh9Y+mBWtWJog@mail.gmail.com>
	<CA+gWKMDb9F5B-UMM8YH_UZw5PtOryFdN5-D6SLy3dCYJ2MtcCQ@mail.gmail.com>
	<CAFdSV9uO6oeELSh52Bad9ik3VSrCydinPjw6DiefmPK4Krd_5w@mail.gmail.com>
	<CA+gWKMCEAxyDBNKhG0LUnLpsJZ3ZBob3K=z-Sd51m7iTueg8Gg@mail.gmail.com>
	<69110219-7c69-a82b-675d-1a5dd2f3902e@gmail.com>
Message-ID: <CA+gWKMD4viCDXCgeF2HkqknN21KaKQAdD-7_=8EFXyV0XxW0dw@mail.gmail.com>

Hi,

Looking at the SessionFactoryImpl class, the only way to provide an
SqlFunction is either via the Dialect or via the SessionFactoryOptions:

this.sqlFunctionRegistry = new SQLFunctionRegistry(
jdbcServices.getJdbcEnvironment().getDialect(),
options.getCustomSqlFunctionMap() );

I'm not sure if the ManagedBeanRegistry would have helped in this case
without requiring more code changes.

Vlad

On Thu, May 17, 2018 at 5:22 PM, Christian Beikov <
christian.beikov at gmail.com> wrote:

> It looks ok to me although I'm not sure if it wouldn't be more
> appropriate to instantiate the contributor via ManagedBeanRegistry.
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea:
> > In the end, I thought of a more generic approach to for JPA bootstrapping
> > which, not only allows us to register SqlFunctions, but we can apply
> other
> > changes on the MetadataBuilder object used during bootstrap.
> >
> > This is the Pull Request:
> >
> > https://github.com/hibernate/hibernate-orm/pull/2288
> >
> > Let me know what you think.
> >
> > Vlad
> >
> > On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> Its not so much hindering 6.0 that I am concerned with.  The problem is
> >> updatability for the user.  The more things they use that change = the
> more
> >> work to upgrade.
> >>
> >> On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> >> wrote:
> >>
> >>> I suppose this will be refactored considerably in 6.x.
> >>>
> >>> However, it's just a small change and I don't think it will hinder any
> >>> 6.x changes.
> >>>
> >>> I'm thinking of defining an SqlFunctionContributor interface
> >>> (@FunctionalInterface)
> >>> which can be provided via the properties  Map that's supplied when
> using
> >>> the Persistence#createEntityManagerFactory method.
> >>>
> >>> In EntityManagerFactoryBuilder, I can just inspect that and pass it
> >>> further to MetamodelBuilder.
> >>>
> >>> So, it does not take any effort to implement it and users can benefit
> >>> from it. I recently answered a question on the forum on this topic:
> >>>
> >>> https://discourse.hibernate.org/t/i-cant-use-group-concat-
> >>> in-queries/752/14
> >>>
> >>> And, realized that I was wrong about suggesting doing it via the
> >>> Integrator mechanism (since the Metamodel is already frozen by the
> time we
> >>> execute the Integrator).
> >>>
> >>> Vlad
> >>>
> >>> On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>>
> >>>> This should maybe wait for 6.0.  We are ditching SQLFunction in favor
> of
> >>>> a more AST-friendly contract.
> >>>>
> >>>> Beyond that, go for it.
> >>>>
> >>>>
> >>>> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I realized that only the native Hibernate bootstrapping mechanism
> allows
> >>>>> for passing custom SQL functions.
> >>>>>
> >>>>> For JPA, we can extend the Dialect to register, but that's not always
> >>>>> desirable as it requires a code change
> >>>>> every time the user switches to a new Dialect version.
> >>>>>
> >>>>> For this reason, I created this Jira issue:
> >>>>>
> >>>>> https://hibernate.atlassian.net/browse/HHH-12589
> >>>>>
> >>>>> Let me know if anyone has anything against implementing this feature.
> >>>>>
> >>>>> Vlad
> >>>>> _______________________________________________
> >>>>> 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 christian.beikov at gmail.com  Thu May 17 12:25:58 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 17 May 2018 18:25:58 +0200
Subject: [hibernate-dev] Simplify SQL function registration when
 bootstrapping via JPA
In-Reply-To: <CA+gWKMD4viCDXCgeF2HkqknN21KaKQAdD-7_=8EFXyV0XxW0dw@mail.gmail.com>
References: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>
	<CAFdSV9uQZ6f7HMw1kPBcuNpySV1GF1E2mLu9uZh9Y+mBWtWJog@mail.gmail.com>
	<CA+gWKMDb9F5B-UMM8YH_UZw5PtOryFdN5-D6SLy3dCYJ2MtcCQ@mail.gmail.com>
	<CAFdSV9uO6oeELSh52Bad9ik3VSrCydinPjw6DiefmPK4Krd_5w@mail.gmail.com>
	<CA+gWKMCEAxyDBNKhG0LUnLpsJZ3ZBob3K=z-Sd51m7iTueg8Gg@mail.gmail.com>
	<69110219-7c69-a82b-675d-1a5dd2f3902e@gmail.com>
	<CA+gWKMD4viCDXCgeF2HkqknN21KaKQAdD-7_=8EFXyV0XxW0dw@mail.gmail.com>
Message-ID: <eb79893f-82da-2cd8-3da5-b2b6ef45bc64@gmail.com>

The functions could be contributed via a CDI/Spring bean which might not 
be such a bad idea I think. In a test environment there could be a 
different contributor active than in production. Of course, this could 
also be handled by passing in different configuration property values, 
but that's why I was saying I'm not sure about it. Maybe someone else 
has an idea if using ManagedBeanRegistry might make sense?


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 17.05.2018 um 16:49 schrieb Vlad Mihalcea:
> Hi,
>
> Looking at the SessionFactoryImpl class, the only way to provide an 
> SqlFunction is either via the Dialect or via the SessionFactoryOptions:
> this.sqlFunctionRegistry  =new SQLFunctionRegistry( jdbcServices.getJdbcEnvironment().getDialect(), options.getCustomSqlFunctionMap() );
> I'm not sure if the ManagedBeanRegistry would have helped in this case 
> without requiring more code changes.
>
> Vlad
>
> On Thu, May 17, 2018 at 5:22 PM, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     It looks ok to me although I'm not sure if it wouldn't be more
>     appropriate to instantiate the contributor via ManagedBeanRegistry.
>
>
>     Mit freundlichen Gr??en,
>     ------------------------------------------------------------------------
>     *Christian Beikov*
>     Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea:
>     > In the end, I thought of a more generic approach to for JPA
>     bootstrapping
>     > which, not only allows us to register SqlFunctions, but we can
>     apply other
>     > changes on the MetadataBuilder object used during bootstrap.
>     >
>     > This is the Pull Request:
>     >
>     > https://github.com/hibernate/hibernate-orm/pull/2288
>     <https://github.com/hibernate/hibernate-orm/pull/2288>
>     >
>     > Let me know what you think.
>     >
>     > Vlad
>     >
>     > On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole
>     <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>     >
>     >> Its not so much hindering 6.0 that I am concerned with.? The
>     problem is
>     >> updatability for the user.? The more things they use that
>     change = the more
>     >> work to upgrade.
>     >>
>     >> On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea
>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
>     >> wrote:
>     >>
>     >>> I suppose this will be refactored considerably in 6.x.
>     >>>
>     >>> However, it's just a small change and I don't think it will
>     hinder any
>     >>> 6.x changes.
>     >>>
>     >>> I'm thinking of defining an SqlFunctionContributor interface
>     >>> (@FunctionalInterface)
>     >>> which can be provided via the properties Map that's supplied
>     when using
>     >>> the Persistence#createEntityManagerFactory method.
>     >>>
>     >>> In EntityManagerFactoryBuilder, I can just inspect that and
>     pass it
>     >>> further to MetamodelBuilder.
>     >>>
>     >>> So, it does not take any effort to implement it and users can
>     benefit
>     >>> from it. I recently answered a question on the forum on this
>     topic:
>     >>>
>     >>> https://discourse.hibernate.org/t/i-cant-use-group-concat-
>     <https://discourse.hibernate.org/t/i-cant-use-group-concat->
>     >>> in-queries/752/14
>     >>>
>     >>> And, realized that I was wrong about suggesting doing it via the
>     >>> Integrator mechanism (since the Metamodel is already frozen by
>     the time we
>     >>> execute the Integrator).
>     >>>
>     >>> Vlad
>     >>>
>     >>> On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole
>     <steve at hibernate.org <mailto:steve at hibernate.org>>
>     >>> wrote:
>     >>>
>     >>>> This should maybe wait for 6.0.? We are ditching SQLFunction
>     in favor of
>     >>>> a more AST-friendly contract.
>     >>>>
>     >>>> Beyond that, go for it.
>     >>>>
>     >>>>
>     >>>> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea
>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
>     >>>> wrote:
>     >>>>
>     >>>>> Hi,
>     >>>>>
>     >>>>> I realized that only the native Hibernate bootstrapping
>     mechanism allows
>     >>>>> for passing custom SQL functions.
>     >>>>>
>     >>>>> For JPA, we can extend the Dialect to register, but that's
>     not always
>     >>>>> desirable as it requires a code change
>     >>>>> every time the user switches to a new Dialect version.
>     >>>>>
>     >>>>> For this reason, I created this Jira issue:
>     >>>>>
>     >>>>> https://hibernate.atlassian.net/browse/HHH-12589
>     <https://hibernate.atlassian.net/browse/HHH-12589>
>     >>>>>
>     >>>>> Let me know if anyone has anything against implementing this
>     feature.
>     >>>>>
>     >>>>> Vlad
>     >>>>> _______________________________________________
>     >>>>> hibernate-dev mailing list
>     >>>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >>>>>
>     > _______________________________________________
>     > hibernate-dev mailing list
>     > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>


From crancran at gmail.com  Thu May 17 13:07:38 2018
From: crancran at gmail.com (Chris Cranford)
Date: Thu, 17 May 2018 13:07:38 -0400
Subject: [hibernate-dev] Simplify SQL function registration when
 bootstrapping via JPA
In-Reply-To: <eb79893f-82da-2cd8-3da5-b2b6ef45bc64@gmail.com>
References: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>
	<CAFdSV9uQZ6f7HMw1kPBcuNpySV1GF1E2mLu9uZh9Y+mBWtWJog@mail.gmail.com>
	<CA+gWKMDb9F5B-UMM8YH_UZw5PtOryFdN5-D6SLy3dCYJ2MtcCQ@mail.gmail.com>
	<CAFdSV9uO6oeELSh52Bad9ik3VSrCydinPjw6DiefmPK4Krd_5w@mail.gmail.com>
	<CA+gWKMCEAxyDBNKhG0LUnLpsJZ3ZBob3K=z-Sd51m7iTueg8Gg@mail.gmail.com>
	<69110219-7c69-a82b-675d-1a5dd2f3902e@gmail.com>
	<CA+gWKMD4viCDXCgeF2HkqknN21KaKQAdD-7_=8EFXyV0XxW0dw@mail.gmail.com>
	<eb79893f-82da-2cd8-3da5-b2b6ef45bc64@gmail.com>
Message-ID: <d0261511-ed4c-a6e0-94a6-2cddd4ba0a7d@gmail.com>

I personally agree with Christian, I don't see the use of the
ManagedBeanRegistry being a problem.? The new interface certainly opens
the door for a variety of builder settings to be contributed easily and
using the registry allows for a versatile way to provide that bean,
whether it be through some CDI/Spring environment or the fallback
solution where we instantiate it ourselves.? I believe the code as you
have it can easily be adapted to use the registry by replacing the
"newInstance()" call with a call into getting the bean from the
registry.? The registry itself internally should handle getting the bean
from the container or returning you a new instance we instantiate ourselves.

On 05/17/2018 12:25 PM, Christian Beikov wrote:
> The functions could be contributed via a CDI/Spring bean which might not 
> be such a bad idea I think. In a test environment there could be a 
> different contributor active than in production. Of course, this could 
> also be handled by passing in different configuration property values, 
> but that's why I was saying I'm not sure about it. Maybe someone else 
> has an idea if using ManagedBeanRegistry might make sense?
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 17.05.2018 um 16:49 schrieb Vlad Mihalcea:
>> Hi,
>>
>> Looking at the SessionFactoryImpl class, the only way to provide an 
>> SqlFunction is either via the Dialect or via the SessionFactoryOptions:
>> this.sqlFunctionRegistry  =new SQLFunctionRegistry( jdbcServices.getJdbcEnvironment().getDialect(), options.getCustomSqlFunctionMap() );
>> I'm not sure if the ManagedBeanRegistry would have helped in this case 
>> without requiring more code changes.
>>
>> Vlad
>>
>> On Thu, May 17, 2018 at 5:22 PM, Christian Beikov 
>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>>
>>     It looks ok to me although I'm not sure if it wouldn't be more
>>     appropriate to instantiate the contributor via ManagedBeanRegistry.
>>
>>
>>     Mit freundlichen Gr??en,
>>     ------------------------------------------------------------------------
>>     *Christian Beikov*
>>     Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea:
>>     > In the end, I thought of a more generic approach to for JPA
>>     bootstrapping
>>     > which, not only allows us to register SqlFunctions, but we can
>>     apply other
>>     > changes on the MetadataBuilder object used during bootstrap.
>>     >
>>     > This is the Pull Request:
>>     >
>>     > https://github.com/hibernate/hibernate-orm/pull/2288
>>     <https://github.com/hibernate/hibernate-orm/pull/2288>
>>     >
>>     > Let me know what you think.
>>     >
>>     > Vlad
>>     >
>>     > On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole
>>     <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>>     >
>>     >> Its not so much hindering 6.0 that I am concerned with.? The
>>     problem is
>>     >> updatability for the user.? The more things they use that
>>     change = the more
>>     >> work to upgrade.
>>     >>
>>     >> On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea
>>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
>>     >> wrote:
>>     >>
>>     >>> I suppose this will be refactored considerably in 6.x.
>>     >>>
>>     >>> However, it's just a small change and I don't think it will
>>     hinder any
>>     >>> 6.x changes.
>>     >>>
>>     >>> I'm thinking of defining an SqlFunctionContributor interface
>>     >>> (@FunctionalInterface)
>>     >>> which can be provided via the properties Map that's supplied
>>     when using
>>     >>> the Persistence#createEntityManagerFactory method.
>>     >>>
>>     >>> In EntityManagerFactoryBuilder, I can just inspect that and
>>     pass it
>>     >>> further to MetamodelBuilder.
>>     >>>
>>     >>> So, it does not take any effort to implement it and users can
>>     benefit
>>     >>> from it. I recently answered a question on the forum on this
>>     topic:
>>     >>>
>>     >>> https://discourse.hibernate.org/t/i-cant-use-group-concat-
>>     <https://discourse.hibernate.org/t/i-cant-use-group-concat->
>>     >>> in-queries/752/14
>>     >>>
>>     >>> And, realized that I was wrong about suggesting doing it via the
>>     >>> Integrator mechanism (since the Metamodel is already frozen by
>>     the time we
>>     >>> execute the Integrator).
>>     >>>
>>     >>> Vlad
>>     >>>
>>     >>> On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole
>>     <steve at hibernate.org <mailto:steve at hibernate.org>>
>>     >>> wrote:
>>     >>>
>>     >>>> This should maybe wait for 6.0.? We are ditching SQLFunction
>>     in favor of
>>     >>>> a more AST-friendly contract.
>>     >>>>
>>     >>>> Beyond that, go for it.
>>     >>>>
>>     >>>>
>>     >>>> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea
>>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
>>     >>>> wrote:
>>     >>>>
>>     >>>>> Hi,
>>     >>>>>
>>     >>>>> I realized that only the native Hibernate bootstrapping
>>     mechanism allows
>>     >>>>> for passing custom SQL functions.
>>     >>>>>
>>     >>>>> For JPA, we can extend the Dialect to register, but that's
>>     not always
>>     >>>>> desirable as it requires a code change
>>     >>>>> every time the user switches to a new Dialect version.
>>     >>>>>
>>     >>>>> For this reason, I created this Jira issue:
>>     >>>>>
>>     >>>>> https://hibernate.atlassian.net/browse/HHH-12589
>>     <https://hibernate.atlassian.net/browse/HHH-12589>
>>     >>>>>
>>     >>>>> Let me know if anyone has anything against implementing this
>>     feature.
>>     >>>>>
>>     >>>>> Vlad
>>     >>>>> _______________________________________________
>>     >>>>> hibernate-dev mailing list
>>     >>>>> hibernate-dev at lists.jboss.org
>>     <mailto:hibernate-dev at lists.jboss.org>
>>     >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>     >>>>>
>>     > _______________________________________________
>>     > hibernate-dev mailing list
>>     > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>
>>     _______________________________________________
>>     hibernate-dev mailing list
>>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From mihalcea.vlad at gmail.com  Thu May 17 13:50:20 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 17 May 2018 20:50:20 +0300
Subject: [hibernate-dev] Simplify SQL function registration when
 bootstrapping via JPA
In-Reply-To: <d0261511-ed4c-a6e0-94a6-2cddd4ba0a7d@gmail.com>
References: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>
	<CAFdSV9uQZ6f7HMw1kPBcuNpySV1GF1E2mLu9uZh9Y+mBWtWJog@mail.gmail.com>
	<CA+gWKMDb9F5B-UMM8YH_UZw5PtOryFdN5-D6SLy3dCYJ2MtcCQ@mail.gmail.com>
	<CAFdSV9uO6oeELSh52Bad9ik3VSrCydinPjw6DiefmPK4Krd_5w@mail.gmail.com>
	<CA+gWKMCEAxyDBNKhG0LUnLpsJZ3ZBob3K=z-Sd51m7iTueg8Gg@mail.gmail.com>
	<69110219-7c69-a82b-675d-1a5dd2f3902e@gmail.com>
	<CA+gWKMD4viCDXCgeF2HkqknN21KaKQAdD-7_=8EFXyV0XxW0dw@mail.gmail.com>
	<eb79893f-82da-2cd8-3da5-b2b6ef45bc64@gmail.com>
	<d0261511-ed4c-a6e0-94a6-2cddd4ba0a7d@gmail.com>
Message-ID: <CA+gWKMBn-Q9nRS17VMSZBuqfpTLrAaFroc8BahPSEHcD-P_sog@mail.gmail.com>

Sure thing. I'll try to adapt it to using the Bean registry.

Vlad

On Thu, 17 May 2018, 20:07 Chris Cranford, <crancran at gmail.com> wrote:

> I personally agree with Christian, I don't see the use of the
> ManagedBeanRegistry being a problem.  The new interface certainly opens
> the door for a variety of builder settings to be contributed easily and
> using the registry allows for a versatile way to provide that bean,
> whether it be through some CDI/Spring environment or the fallback
> solution where we instantiate it ourselves.  I believe the code as you
> have it can easily be adapted to use the registry by replacing the
> "newInstance()" call with a call into getting the bean from the
> registry.  The registry itself internally should handle getting the bean
> from the container or returning you a new instance we instantiate
> ourselves.
>
> On 05/17/2018 12:25 PM, Christian Beikov wrote:
> > The functions could be contributed via a CDI/Spring bean which might not
> > be such a bad idea I think. In a test environment there could be a
> > different contributor active than in production. Of course, this could
> > also be handled by passing in different configuration property values,
> > but that's why I was saying I'm not sure about it. Maybe someone else
> > has an idea if using ManagedBeanRegistry might make sense?
> >
> >
> > Mit freundlichen Gr??en,
> > ------------------------------------------------------------------------
> > *Christian Beikov*
> > Am 17.05.2018 um 16:49 schrieb Vlad Mihalcea:
> >> Hi,
> >>
> >> Looking at the SessionFactoryImpl class, the only way to provide an
> >> SqlFunction is either via the Dialect or via the SessionFactoryOptions:
> >> this.sqlFunctionRegistry  =new SQLFunctionRegistry(
> jdbcServices.getJdbcEnvironment().getDialect(),
> options.getCustomSqlFunctionMap() );
> >> I'm not sure if the ManagedBeanRegistry would have helped in this case
> >> without requiring more code changes.
> >>
> >> Vlad
> >>
> >> On Thu, May 17, 2018 at 5:22 PM, Christian Beikov
> >> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
> >>
> >>     It looks ok to me although I'm not sure if it wouldn't be more
> >>     appropriate to instantiate the contributor via ManagedBeanRegistry.
> >>
> >>
> >>     Mit freundlichen Gr??en,
> >>
>  ------------------------------------------------------------------------
> >>     *Christian Beikov*
> >>     Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea:
> >>     > In the end, I thought of a more generic approach to for JPA
> >>     bootstrapping
> >>     > which, not only allows us to register SqlFunctions, but we can
> >>     apply other
> >>     > changes on the MetadataBuilder object used during bootstrap.
> >>     >
> >>     > This is the Pull Request:
> >>     >
> >>     > https://github.com/hibernate/hibernate-orm/pull/2288
> >>     <https://github.com/hibernate/hibernate-orm/pull/2288>
> >>     >
> >>     > Let me know what you think.
> >>     >
> >>     > Vlad
> >>     >
> >>     > On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole
> >>     <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
> >>     >
> >>     >> Its not so much hindering 6.0 that I am concerned with.  The
> >>     problem is
> >>     >> updatability for the user.  The more things they use that
> >>     change = the more
> >>     >> work to upgrade.
> >>     >>
> >>     >> On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea
> >>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
> >>     >> wrote:
> >>     >>
> >>     >>> I suppose this will be refactored considerably in 6.x.
> >>     >>>
> >>     >>> However, it's just a small change and I don't think it will
> >>     hinder any
> >>     >>> 6.x changes.
> >>     >>>
> >>     >>> I'm thinking of defining an SqlFunctionContributor interface
> >>     >>> (@FunctionalInterface)
> >>     >>> which can be provided via the properties Map that's supplied
> >>     when using
> >>     >>> the Persistence#createEntityManagerFactory method.
> >>     >>>
> >>     >>> In EntityManagerFactoryBuilder, I can just inspect that and
> >>     pass it
> >>     >>> further to MetamodelBuilder.
> >>     >>>
> >>     >>> So, it does not take any effort to implement it and users can
> >>     benefit
> >>     >>> from it. I recently answered a question on the forum on this
> >>     topic:
> >>     >>>
> >>     >>> https://discourse.hibernate.org/t/i-cant-use-group-concat-
> >>     <https://discourse.hibernate.org/t/i-cant-use-group-concat->
> >>     >>> in-queries/752/14
> >>     >>>
> >>     >>> And, realized that I was wrong about suggesting doing it via the
> >>     >>> Integrator mechanism (since the Metamodel is already frozen by
> >>     the time we
> >>     >>> execute the Integrator).
> >>     >>>
> >>     >>> Vlad
> >>     >>>
> >>     >>> On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole
> >>     <steve at hibernate.org <mailto:steve at hibernate.org>>
> >>     >>> wrote:
> >>     >>>
> >>     >>>> This should maybe wait for 6.0.  We are ditching SQLFunction
> >>     in favor of
> >>     >>>> a more AST-friendly contract.
> >>     >>>>
> >>     >>>> Beyond that, go for it.
> >>     >>>>
> >>     >>>>
> >>     >>>> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea
> >>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
> >>     >>>> wrote:
> >>     >>>>
> >>     >>>>> Hi,
> >>     >>>>>
> >>     >>>>> I realized that only the native Hibernate bootstrapping
> >>     mechanism allows
> >>     >>>>> for passing custom SQL functions.
> >>     >>>>>
> >>     >>>>> For JPA, we can extend the Dialect to register, but that's
> >>     not always
> >>     >>>>> desirable as it requires a code change
> >>     >>>>> every time the user switches to a new Dialect version.
> >>     >>>>>
> >>     >>>>> For this reason, I created this Jira issue:
> >>     >>>>>
> >>     >>>>> https://hibernate.atlassian.net/browse/HHH-12589
> >>     <https://hibernate.atlassian.net/browse/HHH-12589>
> >>     >>>>>
> >>     >>>>> Let me know if anyone has anything against implementing this
> >>     feature.
> >>     >>>>>
> >>     >>>>> Vlad
> >>     >>>>> _______________________________________________
> >>     >>>>> hibernate-dev mailing list
> >>     >>>>> hibernate-dev at lists.jboss.org
> >>     <mailto:hibernate-dev at lists.jboss.org>
> >>     >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >>     >>>>>
> >>     > _______________________________________________
> >>     > hibernate-dev mailing list
> >>     > hibernate-dev at lists.jboss.org <mailto:
> hibernate-dev at lists.jboss.org>
> >>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >>
> >>     _______________________________________________
> >>     hibernate-dev mailing list
> >>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org
> >
> >>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >>
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu May 17 14:03:25 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 17 May 2018 13:03:25 -0500
Subject: [hibernate-dev] Stride
Message-ID: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>

I got an email from Atlassian this morning about the migration from HipChat
to Stride.  Basically they have not gotten Stride feature-complete in terms
of HipChat which is the trigger for the mass migration.  However, they are
reaching out to all waiting teams to see if any want to migrate anyway.
The list of missing features they sent me are:


   1. Guest access
   2. Some admin controls and compliance settings
   3. Integrations with Atlassian server products (the Jira Server app is
   currently in beta and coming soon) and some other popular integrations. See
   all available Stride integrations
   <http://click.mailer.atlassian.com/?qs=6712850cb7a4f2d4a207f46e5f190a454855738b8db6340974f28f3c2e1e6aa7c674a6314ad5df11014e5e2ee39bd3d4326606d2826b241a>
   .
   4. User management via API
   5. Dark mode

I am not really sure exactly what is missing WRT (2).  (3) is nice-to-have,
but not blocker IMO assuming it gets added at some point.

I think (1) is the only one that is concerning.  Though TBH for myself
personally, I do not think registering is a big deal.

Unless I hear otherwise, I plan on asking them to proceed with our
migration to Stride.

From steve at hibernate.org  Thu May 17 14:07:59 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 17 May 2018 13:07:59 -0500
Subject: [hibernate-dev] Simplify SQL function registration when
 bootstrapping via JPA
In-Reply-To: <CA+gWKMBn-Q9nRS17VMSZBuqfpTLrAaFroc8BahPSEHcD-P_sog@mail.gmail.com>
References: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>
	<CAFdSV9uQZ6f7HMw1kPBcuNpySV1GF1E2mLu9uZh9Y+mBWtWJog@mail.gmail.com>
	<CA+gWKMDb9F5B-UMM8YH_UZw5PtOryFdN5-D6SLy3dCYJ2MtcCQ@mail.gmail.com>
	<CAFdSV9uO6oeELSh52Bad9ik3VSrCydinPjw6DiefmPK4Krd_5w@mail.gmail.com>
	<CA+gWKMCEAxyDBNKhG0LUnLpsJZ3ZBob3K=z-Sd51m7iTueg8Gg@mail.gmail.com>
	<69110219-7c69-a82b-675d-1a5dd2f3902e@gmail.com>
	<CA+gWKMD4viCDXCgeF2HkqknN21KaKQAdD-7_=8EFXyV0XxW0dw@mail.gmail.com>
	<eb79893f-82da-2cd8-3da5-b2b6ef45bc64@gmail.com>
	<d0261511-ed4c-a6e0-94a6-2cddd4ba0a7d@gmail.com>
	<CA+gWKMBn-Q9nRS17VMSZBuqfpTLrAaFroc8BahPSEHcD-P_sog@mail.gmail.com>
Message-ID: <CAFdSV9u0BuifLsViw5ss-6e-ssJoQ2QBmc==Hs2UhiRTur5pFg@mail.gmail.com>

Personally I think both a contributor and CDI integration
(ManagedBeanRegitry) make sense here.  Btw, the name for the contributor
should not be SqlFunctionContributor - it should reflect the ultimate goal
here which is SqmFunctionTemplate; I can see SqmFunctionContributor or just
FunctionContributor.  This is an example of what I meant about waiting for
6...

On Thu, May 17, 2018 at 12:50 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Sure thing. I'll try to adapt it to using the Bean registry.
>
> Vlad
>
> On Thu, 17 May 2018, 20:07 Chris Cranford, <crancran at gmail.com> wrote:
>
> > I personally agree with Christian, I don't see the use of the
> > ManagedBeanRegistry being a problem.  The new interface certainly opens
> > the door for a variety of builder settings to be contributed easily and
> > using the registry allows for a versatile way to provide that bean,
> > whether it be through some CDI/Spring environment or the fallback
> > solution where we instantiate it ourselves.  I believe the code as you
> > have it can easily be adapted to use the registry by replacing the
> > "newInstance()" call with a call into getting the bean from the
> > registry.  The registry itself internally should handle getting the bean
> > from the container or returning you a new instance we instantiate
> > ourselves.
> >
> > On 05/17/2018 12:25 PM, Christian Beikov wrote:
> > > The functions could be contributed via a CDI/Spring bean which might
> not
> > > be such a bad idea I think. In a test environment there could be a
> > > different contributor active than in production. Of course, this could
> > > also be handled by passing in different configuration property values,
> > > but that's why I was saying I'm not sure about it. Maybe someone else
> > > has an idea if using ManagedBeanRegistry might make sense?
> > >
> > >
> > > Mit freundlichen Gr??en,
> > >
> ------------------------------------------------------------------------
> > > *Christian Beikov*
> > > Am 17.05.2018 um 16:49 schrieb Vlad Mihalcea:
> > >> Hi,
> > >>
> > >> Looking at the SessionFactoryImpl class, the only way to provide an
> > >> SqlFunction is either via the Dialect or via the
> SessionFactoryOptions:
> > >> this.sqlFunctionRegistry  =new SQLFunctionRegistry(
> > jdbcServices.getJdbcEnvironment().getDialect(),
> > options.getCustomSqlFunctionMap() );
> > >> I'm not sure if the ManagedBeanRegistry would have helped in this case
> > >> without requiring more code changes.
> > >>
> > >> Vlad
> > >>
> > >> On Thu, May 17, 2018 at 5:22 PM, Christian Beikov
> > >> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
> wrote:
> > >>
> > >>     It looks ok to me although I'm not sure if it wouldn't be more
> > >>     appropriate to instantiate the contributor via
> ManagedBeanRegistry.
> > >>
> > >>
> > >>     Mit freundlichen Gr??en,
> > >>
> >  ------------------------------------------------------------------------
> > >>     *Christian Beikov*
> > >>     Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea:
> > >>     > In the end, I thought of a more generic approach to for JPA
> > >>     bootstrapping
> > >>     > which, not only allows us to register SqlFunctions, but we can
> > >>     apply other
> > >>     > changes on the MetadataBuilder object used during bootstrap.
> > >>     >
> > >>     > This is the Pull Request:
> > >>     >
> > >>     > https://github.com/hibernate/hibernate-orm/pull/2288
> > >>     <https://github.com/hibernate/hibernate-orm/pull/2288>
> > >>     >
> > >>     > Let me know what you think.
> > >>     >
> > >>     > Vlad
> > >>     >
> > >>     > On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole
> > >>     <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
> > >>     >
> > >>     >> Its not so much hindering 6.0 that I am concerned with.  The
> > >>     problem is
> > >>     >> updatability for the user.  The more things they use that
> > >>     change = the more
> > >>     >> work to upgrade.
> > >>     >>
> > >>     >> On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea
> > >>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
> > >>     >> wrote:
> > >>     >>
> > >>     >>> I suppose this will be refactored considerably in 6.x.
> > >>     >>>
> > >>     >>> However, it's just a small change and I don't think it will
> > >>     hinder any
> > >>     >>> 6.x changes.
> > >>     >>>
> > >>     >>> I'm thinking of defining an SqlFunctionContributor interface
> > >>     >>> (@FunctionalInterface)
> > >>     >>> which can be provided via the properties Map that's supplied
> > >>     when using
> > >>     >>> the Persistence#createEntityManagerFactory method.
> > >>     >>>
> > >>     >>> In EntityManagerFactoryBuilder, I can just inspect that and
> > >>     pass it
> > >>     >>> further to MetamodelBuilder.
> > >>     >>>
> > >>     >>> So, it does not take any effort to implement it and users can
> > >>     benefit
> > >>     >>> from it. I recently answered a question on the forum on this
> > >>     topic:
> > >>     >>>
> > >>     >>> https://discourse.hibernate.org/t/i-cant-use-group-concat-
> > >>     <https://discourse.hibernate.org/t/i-cant-use-group-concat->
> > >>     >>> in-queries/752/14
> > >>     >>>
> > >>     >>> And, realized that I was wrong about suggesting doing it via
> the
> > >>     >>> Integrator mechanism (since the Metamodel is already frozen by
> > >>     the time we
> > >>     >>> execute the Integrator).
> > >>     >>>
> > >>     >>> Vlad
> > >>     >>>
> > >>     >>> On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole
> > >>     <steve at hibernate.org <mailto:steve at hibernate.org>>
> > >>     >>> wrote:
> > >>     >>>
> > >>     >>>> This should maybe wait for 6.0.  We are ditching SQLFunction
> > >>     in favor of
> > >>     >>>> a more AST-friendly contract.
> > >>     >>>>
> > >>     >>>> Beyond that, go for it.
> > >>     >>>>
> > >>     >>>>
> > >>     >>>> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea
> > >>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
> > >>     >>>> wrote:
> > >>     >>>>
> > >>     >>>>> Hi,
> > >>     >>>>>
> > >>     >>>>> I realized that only the native Hibernate bootstrapping
> > >>     mechanism allows
> > >>     >>>>> for passing custom SQL functions.
> > >>     >>>>>
> > >>     >>>>> For JPA, we can extend the Dialect to register, but that's
> > >>     not always
> > >>     >>>>> desirable as it requires a code change
> > >>     >>>>> every time the user switches to a new Dialect version.
> > >>     >>>>>
> > >>     >>>>> For this reason, I created this Jira issue:
> > >>     >>>>>
> > >>     >>>>> https://hibernate.atlassian.net/browse/HHH-12589
> > >>     <https://hibernate.atlassian.net/browse/HHH-12589>
> > >>     >>>>>
> > >>     >>>>> Let me know if anyone has anything against implementing this
> > >>     feature.
> > >>     >>>>>
> > >>     >>>>> Vlad
> > >>     >>>>> _______________________________________________
> > >>     >>>>> hibernate-dev mailing list
> > >>     >>>>> hibernate-dev at lists.jboss.org
> > >>     <mailto:hibernate-dev at lists.jboss.org>
> > >>     >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> > >>     >>>>>
> > >>     > _______________________________________________
> > >>     > hibernate-dev mailing list
> > >>     > hibernate-dev at lists.jboss.org <mailto:
> > hibernate-dev at lists.jboss.org>
> > >>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> > >>
> > >>     _______________________________________________
> > >>     hibernate-dev mailing list
> > >>     hibernate-dev at lists.jboss.org <mailto:
> hibernate-dev at lists.jboss.org
> > >
> > >>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> > >>
> > >>
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Thu May 17 14:11:15 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 17 May 2018 20:11:15 +0200
Subject: [hibernate-dev] Stride
In-Reply-To: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
Message-ID: <CALt0+o-LpBy1vv60jenTsqpYJW_56vcuVi4orTLF_WdWLDByKg@mail.gmail.com>

Hi Steve,

Hum. I see at least 1/ and 3/ as being annoying. I personally like to have
the JIRA/GitHub/Jenkins notifications on HipChat.

What would be the advantages of migrating so soon?

On Thu, May 17, 2018 at 8:03 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I got an email from Atlassian this morning about the migration from HipChat
> to Stride.  Basically they have not gotten Stride feature-complete in terms
> of HipChat which is the trigger for the mass migration.  However, they are
> reaching out to all waiting teams to see if any want to migrate anyway.
> The list of missing features they sent me are:
>
>
>    1. Guest access
>    2. Some admin controls and compliance settings
>    3. Integrations with Atlassian server products (the Jira Server app is
>    currently in beta and coming soon) and some other popular integrations.
> See
>    all available Stride integrations
>    <http://click.mailer.atlassian.com/?qs=6712850cb7a4f2d4a207f46e5f190a
> 454855738b8db6340974f28f3c2e1e6aa7c674a6314ad5df11014e5e2ee3
> 9bd3d4326606d2826b241a>
>    .
>    4. User management via API
>    5. Dark mode
>
> I am not really sure exactly what is missing WRT (2).  (3) is nice-to-have,
> but not blocker IMO assuming it gets added at some point.
>
> I think (1) is the only one that is concerning.  Though TBH for myself
> personally, I do not think registering is a big deal.
>
> Unless I hear otherwise, I plan on asking them to proceed with our
> migration to Stride.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu May 17 14:16:25 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 17 May 2018 19:16:25 +0100
Subject: [hibernate-dev] Stride
In-Reply-To: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
Message-ID: <CAFm4XO2UzDPv+BnkG_=QT+pLWxVyCK5u1-B8FZPpQfOG7GemLg@mail.gmail.com>

lol, I was writing about the same to the team list.

+1 to have people register, it's better for them anyway. I checked
it's easier to self-register.

+1 to migrate quickly. It's clear we don't want to stay on HipChat, if
this doesn't work out we'll see.

Refer to my parallel email for Fedora instructions.

Thanks,
Sanne


On 17 May 2018 at 19:03, Steve Ebersole <steve at hibernate.org> wrote:
> I got an email from Atlassian this morning about the migration from HipChat
> to Stride.  Basically they have not gotten Stride feature-complete in terms
> of HipChat which is the trigger for the mass migration.  However, they are
> reaching out to all waiting teams to see if any want to migrate anyway.
> The list of missing features they sent me are:
>
>
>    1. Guest access
>    2. Some admin controls and compliance settings
>    3. Integrations with Atlassian server products (the Jira Server app is
>    currently in beta and coming soon) and some other popular integrations. See
>    all available Stride integrations
>    <http://click.mailer.atlassian.com/?qs=6712850cb7a4f2d4a207f46e5f190a454855738b8db6340974f28f3c2e1e6aa7c674a6314ad5df11014e5e2ee39bd3d4326606d2826b241a>
>    .
>    4. User management via API
>    5. Dark mode
>
> I am not really sure exactly what is missing WRT (2).  (3) is nice-to-have,
> but not blocker IMO assuming it gets added at some point.
>
> I think (1) is the only one that is concerning.  Though TBH for myself
> personally, I do not think registering is a big deal.
>
> Unless I hear otherwise, I plan on asking them to proceed with our
> migration to Stride.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Thu May 17 14:20:25 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 17 May 2018 19:20:25 +0100
Subject: [hibernate-dev] Stride
In-Reply-To: <CALt0+o-LpBy1vv60jenTsqpYJW_56vcuVi4orTLF_WdWLDByKg@mail.gmail.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
	<CALt0+o-LpBy1vv60jenTsqpYJW_56vcuVi4orTLF_WdWLDByKg@mail.gmail.com>
Message-ID: <CAFm4XO0x9ePoHrzUWsrj8-DK12SJNy2dDLssJ3A1oRZ73wEUSw@mail.gmail.com>

On 17 May 2018 at 19:11, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi Steve,
>
> Hum. I see at least 1/ and 3/ as being annoying. I personally like to have
> the JIRA/GitHub/Jenkins notifications on HipChat.

JIRA and GitHub integrations are available already.

I'm confident Jenkins won't take long:
 - https://jira.atlassian.com/browse/STRIDE-1973

> What would be the advantages of migrating so soon?

We'll know sooner if we like it :)

From mihalcea.vlad at gmail.com  Thu May 17 14:34:54 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 17 May 2018 21:34:54 +0300
Subject: [hibernate-dev] Simplify SQL function registration when
 bootstrapping via JPA
In-Reply-To: <CAFdSV9u0BuifLsViw5ss-6e-ssJoQ2QBmc==Hs2UhiRTur5pFg@mail.gmail.com>
References: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>
	<CAFdSV9uQZ6f7HMw1kPBcuNpySV1GF1E2mLu9uZh9Y+mBWtWJog@mail.gmail.com>
	<CA+gWKMDb9F5B-UMM8YH_UZw5PtOryFdN5-D6SLy3dCYJ2MtcCQ@mail.gmail.com>
	<CAFdSV9uO6oeELSh52Bad9ik3VSrCydinPjw6DiefmPK4Krd_5w@mail.gmail.com>
	<CA+gWKMCEAxyDBNKhG0LUnLpsJZ3ZBob3K=z-Sd51m7iTueg8Gg@mail.gmail.com>
	<69110219-7c69-a82b-675d-1a5dd2f3902e@gmail.com>
	<CA+gWKMD4viCDXCgeF2HkqknN21KaKQAdD-7_=8EFXyV0XxW0dw@mail.gmail.com>
	<eb79893f-82da-2cd8-3da5-b2b6ef45bc64@gmail.com>
	<d0261511-ed4c-a6e0-94a6-2cddd4ba0a7d@gmail.com>
	<CA+gWKMBn-Q9nRS17VMSZBuqfpTLrAaFroc8BahPSEHcD-P_sog@mail.gmail.com>
	<CAFdSV9u0BuifLsViw5ss-6e-ssJoQ2QBmc==Hs2UhiRTur5pFg@mail.gmail.com>
Message-ID: <CA+gWKMAxzCsSdW2_6e980zUe=-C3bd4bFd9JhAjt0tC90Oojeg@mail.gmail.com>

I named it MetadataBuilderContributor because you can do more than just
registering SqlFunctions. While implementing it, I realized that, this way,
it's going to be very flexible to customize the Hibernate-native Metadata
while doing the JPA bootstrap.

Related to ManagedBeanRegitry, I'm trying to convert to using it, but
stumbled on this issue.

If I try to get a Bean like this:

managedBeanRegistry.getBean( MetadataBuilderContributor.class );

And there is no BeanContainer set via "hibernate.resource.beans.container",
then the FallbackContainedBean is used, which tries to instantiate the
provided interface:

beanType.newInstance();

But since I provide an interface, the call will fail.

The only workaround I found is this:

ManagedBeanRegistry managedBeanRegistry = standardServiceRegistry
.getService( ManagedBeanRegistry.class );

BeanContainer beanContainer = managedBeanRegistry.getBeanContainer();

ManagedBean<MetadataBuilderContributor>
metadataBuilderContributorManagedBean = null;
if ( beanContainer != null ) {
metadataBuilderContributorManagedBean = managedBeanRegistry
.getBean( MetadataBuilderContributor.class );
}

MetadataBuilderContributor metadataBuilderContributor =
metadataBuilderContributorManagedBean
.getBeanInstance();

Am I using it the wrong way, or do we need to check the BeanContainer first
to make sure it's not null before getting a Bean from the
ManagedBeanRegistry?

Vlad


On Thu, May 17, 2018 at 9:07 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Personally I think both a contributor and CDI integration
> (ManagedBeanRegitry) make sense here.  Btw, the name for the contributor
> should not be SqlFunctionContributor - it should reflect the ultimate goal
> here which is SqmFunctionTemplate; I can see SqmFunctionContributor or just
> FunctionContributor.  This is an example of what I meant about waiting for
> 6...
>
> On Thu, May 17, 2018 at 12:50 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Sure thing. I'll try to adapt it to using the Bean registry.
>>
>> Vlad
>>
>> On Thu, 17 May 2018, 20:07 Chris Cranford, <crancran at gmail.com> wrote:
>>
>> > I personally agree with Christian, I don't see the use of the
>> > ManagedBeanRegistry being a problem.  The new interface certainly opens
>> > the door for a variety of builder settings to be contributed easily and
>> > using the registry allows for a versatile way to provide that bean,
>> > whether it be through some CDI/Spring environment or the fallback
>> > solution where we instantiate it ourselves.  I believe the code as you
>> > have it can easily be adapted to use the registry by replacing the
>> > "newInstance()" call with a call into getting the bean from the
>> > registry.  The registry itself internally should handle getting the bean
>> > from the container or returning you a new instance we instantiate
>> > ourselves.
>> >
>> > On 05/17/2018 12:25 PM, Christian Beikov wrote:
>> > > The functions could be contributed via a CDI/Spring bean which might
>> not
>> > > be such a bad idea I think. In a test environment there could be a
>> > > different contributor active than in production. Of course, this could
>> > > also be handled by passing in different configuration property values,
>> > > but that's why I was saying I'm not sure about it. Maybe someone else
>> > > has an idea if using ManagedBeanRegistry might make sense?
>> > >
>> > >
>> > > Mit freundlichen Gr??en,
>> > > ------------------------------------------------------------
>> ------------
>> > > *Christian Beikov*
>> > > Am 17.05.2018 um 16:49 schrieb Vlad Mihalcea:
>> > >> Hi,
>> > >>
>> > >> Looking at the SessionFactoryImpl class, the only way to provide an
>> > >> SqlFunction is either via the Dialect or via the
>> SessionFactoryOptions:
>> > >> this.sqlFunctionRegistry  =new SQLFunctionRegistry(
>> > jdbcServices.getJdbcEnvironment().getDialect(),
>> > options.getCustomSqlFunctionMap() );
>> > >> I'm not sure if the ManagedBeanRegistry would have helped in this
>> case
>> > >> without requiring more code changes.
>> > >>
>> > >> Vlad
>> > >>
>> > >> On Thu, May 17, 2018 at 5:22 PM, Christian Beikov
>> > >> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>> wrote:
>> > >>
>> > >>     It looks ok to me although I'm not sure if it wouldn't be more
>> > >>     appropriate to instantiate the contributor via
>> ManagedBeanRegistry.
>> > >>
>> > >>
>> > >>     Mit freundlichen Gr??en,
>> > >>
>> >  ------------------------------------------------------------
>> ------------
>> > >>     *Christian Beikov*
>> > >>     Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea:
>> > >>     > In the end, I thought of a more generic approach to for JPA
>> > >>     bootstrapping
>> > >>     > which, not only allows us to register SqlFunctions, but we can
>> > >>     apply other
>> > >>     > changes on the MetadataBuilder object used during bootstrap.
>> > >>     >
>> > >>     > This is the Pull Request:
>> > >>     >
>> > >>     > https://github.com/hibernate/hibernate-orm/pull/2288
>> > >>     <https://github.com/hibernate/hibernate-orm/pull/2288>
>> > >>     >
>> > >>     > Let me know what you think.
>> > >>     >
>> > >>     > Vlad
>> > >>     >
>> > >>     > On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole
>> > >>     <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>> > >>     >
>> > >>     >> Its not so much hindering 6.0 that I am concerned with.  The
>> > >>     problem is
>> > >>     >> updatability for the user.  The more things they use that
>> > >>     change = the more
>> > >>     >> work to upgrade.
>> > >>     >>
>> > >>     >> On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea
>> > >>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
>> > >>     >> wrote:
>> > >>     >>
>> > >>     >>> I suppose this will be refactored considerably in 6.x.
>> > >>     >>>
>> > >>     >>> However, it's just a small change and I don't think it will
>> > >>     hinder any
>> > >>     >>> 6.x changes.
>> > >>     >>>
>> > >>     >>> I'm thinking of defining an SqlFunctionContributor interface
>> > >>     >>> (@FunctionalInterface)
>> > >>     >>> which can be provided via the properties Map that's supplied
>> > >>     when using
>> > >>     >>> the Persistence#createEntityManagerFactory method.
>> > >>     >>>
>> > >>     >>> In EntityManagerFactoryBuilder, I can just inspect that and
>> > >>     pass it
>> > >>     >>> further to MetamodelBuilder.
>> > >>     >>>
>> > >>     >>> So, it does not take any effort to implement it and users can
>> > >>     benefit
>> > >>     >>> from it. I recently answered a question on the forum on this
>> > >>     topic:
>> > >>     >>>
>> > >>     >>> https://discourse.hibernate.org/t/i-cant-use-group-concat-
>> > >>     <https://discourse.hibernate.org/t/i-cant-use-group-concat->
>> > >>     >>> in-queries/752/14
>> > >>     >>>
>> > >>     >>> And, realized that I was wrong about suggesting doing it via
>> the
>> > >>     >>> Integrator mechanism (since the Metamodel is already frozen
>> by
>> > >>     the time we
>> > >>     >>> execute the Integrator).
>> > >>     >>>
>> > >>     >>> Vlad
>> > >>     >>>
>> > >>     >>> On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole
>> > >>     <steve at hibernate.org <mailto:steve at hibernate.org>>
>> > >>     >>> wrote:
>> > >>     >>>
>> > >>     >>>> This should maybe wait for 6.0.  We are ditching SQLFunction
>> > >>     in favor of
>> > >>     >>>> a more AST-friendly contract.
>> > >>     >>>>
>> > >>     >>>> Beyond that, go for it.
>> > >>     >>>>
>> > >>     >>>>
>> > >>     >>>> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea
>> > >>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
>> > >>     >>>> wrote:
>> > >>     >>>>
>> > >>     >>>>> Hi,
>> > >>     >>>>>
>> > >>     >>>>> I realized that only the native Hibernate bootstrapping
>> > >>     mechanism allows
>> > >>     >>>>> for passing custom SQL functions.
>> > >>     >>>>>
>> > >>     >>>>> For JPA, we can extend the Dialect to register, but that's
>> > >>     not always
>> > >>     >>>>> desirable as it requires a code change
>> > >>     >>>>> every time the user switches to a new Dialect version.
>> > >>     >>>>>
>> > >>     >>>>> For this reason, I created this Jira issue:
>> > >>     >>>>>
>> > >>     >>>>> https://hibernate.atlassian.net/browse/HHH-12589
>> > >>     <https://hibernate.atlassian.net/browse/HHH-12589>
>> > >>     >>>>>
>> > >>     >>>>> Let me know if anyone has anything against implementing
>> this
>> > >>     feature.
>> > >>     >>>>>
>> > >>     >>>>> Vlad
>> > >>     >>>>> _______________________________________________
>> > >>     >>>>> hibernate-dev mailing list
>> > >>     >>>>> hibernate-dev at lists.jboss.org
>> > >>     <mailto:hibernate-dev at lists.jboss.org>
>> > >>     >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> > >>     >>>>>
>> > >>     > _______________________________________________
>> > >>     > hibernate-dev mailing list
>> > >>     > hibernate-dev at lists.jboss.org <mailto:
>> > hibernate-dev at lists.jboss.org>
>> > >>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> > >>
>> > >>     _______________________________________________
>> > >>     hibernate-dev mailing list
>> > >>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.
>> jboss.org
>> > >
>> > >>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> > >>
>> > >>
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From guillaume.smet at gmail.com  Thu May 17 15:17:56 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 17 May 2018 21:17:56 +0200
Subject: [hibernate-dev] Stride
In-Reply-To: <CAFm4XO0x9ePoHrzUWsrj8-DK12SJNy2dDLssJ3A1oRZ73wEUSw@mail.gmail.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
	<CALt0+o-LpBy1vv60jenTsqpYJW_56vcuVi4orTLF_WdWLDByKg@mail.gmail.com>
	<CAFm4XO0x9ePoHrzUWsrj8-DK12SJNy2dDLssJ3A1oRZ73wEUSw@mail.gmail.com>
Message-ID: <CALt0+o9A=6EphY1xPAhXTMnTEMoyK00PqKhXd7vgAbz76rRG2w@mail.gmail.com>

Well, can we at least wait for the Jenkins integration then?

If as you say "it won't take long", we won't have long to wait.

Frankly, I don't see why we would want to rush into this migration...
especially since Stride is not ready yet. We will be part of the first
users to migrate and I'm not sure it's a good idea.

We also need someone with the time to configure correctly all the
integrations.

If we don't have all the features we use now (not talking about the ones we
don't use), I'm pretty sure it won't be better.

A chat system that works is essential to our work.

On Thu, May 17, 2018 at 8:20 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 17 May 2018 at 19:11, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> > Hi Steve,
> >
> > Hum. I see at least 1/ and 3/ as being annoying. I personally like to
> have
> > the JIRA/GitHub/Jenkins notifications on HipChat.
>
> JIRA and GitHub integrations are available already.
>
> I'm confident Jenkins won't take long:
>  - https://jira.atlassian.com/browse/STRIDE-1973
>
> > What would be the advantages of migrating so soon?
>
> We'll know sooner if we like it :)
>

From guillaume.smet at gmail.com  Thu May 17 15:32:38 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 17 May 2018 21:32:38 +0200
Subject: [hibernate-dev] Stride
In-Reply-To: <CAFm4XO2UzDPv+BnkG_=QT+pLWxVyCK5u1-B8FZPpQfOG7GemLg@mail.gmail.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
	<CAFm4XO2UzDPv+BnkG_=QT+pLWxVyCK5u1-B8FZPpQfOG7GemLg@mail.gmail.com>
Message-ID: <4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com>

By the way, you say it?s clear we don?t want to stay on HipChat. 

When did we decide that? I don?t remember a discussion about it. 

For sure, we probably won?t have a choice because there?s a good chance Atlassian will close the service but what are the problems that make a migration so urgent?

> Le 17 mai 2018 ? 20:16, Sanne Grinovero <sanne at hibernate.org> a ?crit :
> 
> lol, I was writing about the same to the team list.
> 
> +1 to have people register, it's better for them anyway. I checked
> it's easier to self-register.
> 
> +1 to migrate quickly. It's clear we don't want to stay on HipChat, if
> this doesn't work out we'll see.
> 
> Refer to my parallel email for Fedora instructions.
> 
> Thanks,
> Sanne
> 
> 
>> On 17 May 2018 at 19:03, Steve Ebersole <steve at hibernate.org> wrote:
>> I got an email from Atlassian this morning about the migration from HipChat
>> to Stride.  Basically they have not gotten Stride feature-complete in terms
>> of HipChat which is the trigger for the mass migration.  However, they are
>> reaching out to all waiting teams to see if any want to migrate anyway.
>> The list of missing features they sent me are:
>> 
>> 
>>   1. Guest access
>>   2. Some admin controls and compliance settings
>>   3. Integrations with Atlassian server products (the Jira Server app is
>>   currently in beta and coming soon) and some other popular integrations. See
>>   all available Stride integrations
>>   <http://click.mailer.atlassian.com/?qs=6712850cb7a4f2d4a207f46e5f190a454855738b8db6340974f28f3c2e1e6aa7c674a6314ad5df11014e5e2ee39bd3d4326606d2826b241a>
>>   .
>>   4. User management via API
>>   5. Dark mode
>> 
>> I am not really sure exactly what is missing WRT (2).  (3) is nice-to-have,
>> but not blocker IMO assuming it gets added at some point.
>> 
>> I think (1) is the only one that is concerning.  Though TBH for myself
>> personally, I do not think registering is a big deal.
>> 
>> Unless I hear otherwise, I plan on asking them to proceed with our
>> migration to Stride.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Thu May 17 18:16:30 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 17 May 2018 23:16:30 +0100
Subject: [hibernate-dev] Stride
In-Reply-To: <4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
	<CAFm4XO2UzDPv+BnkG_=QT+pLWxVyCK5u1-B8FZPpQfOG7GemLg@mail.gmail.com>
	<4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com>
Message-ID: <CAFm4XO1YC1e_yLEawfX-+Mro-WEuM=pGB_DC3NPbYpvn0HNmnA@mail.gmail.com>

On 17 May 2018 at 20:32, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> By the way, you say it?s clear we don?t want to stay on HipChat.
>
> When did we decide that? I don?t remember a discussion about it.

I didn't say it was decided, but I think we're working on that since
Steve asked about it today. To which I agree *because* it seems clear
to me that we don't want to stay on it - a notion I inferred from
multiple previous discussions.

Steve pointed out multiple flaws e.g. the native client packaging
broken on Fedora, to which Atlassian pretty much replied by letting us
know they won't invest in HipChat as the future is Stride. We can
choose when to switch but staying doesn't look sensible to me as it
certainly won't improve; it's also likely that they'll want everyone
migrated eventually so to shut the existing service down.

I for one gave up as well installing the native client and have been
using the web client since setting up my new workstation, as I was
expecting Stride to arrive soon.

The other day some people tried to join and gave up because of login
complexity - that's IMO a very bad sign: not welcoming community
people means it's failing its primary requirements.

And let's not forget all authentication nonsense; especially days that
I'm working more on the WildFly side of things and need to login to
multiple instances I really look forward to a better system (hopefully
it is!?).

Question, since you want a decision: are you only suggesting to delay
or suggesting that you should rather stay on HipChat?

Personally, I'm fine delaying a bit even though I can live happily
without Jenkins notifications, but let's hear the others as well.

Thanks,
Sanne


>
> For sure, we probably won?t have a choice because there?s a good chance Atlassian will close the service but what are the problems that make a migration so urgent?
>
>> Le 17 mai 2018 ? 20:16, Sanne Grinovero <sanne at hibernate.org> a ?crit :
>>
>> lol, I was writing about the same to the team list.
>>
>> +1 to have people register, it's better for them anyway. I checked
>> it's easier to self-register.
>>
>> +1 to migrate quickly. It's clear we don't want to stay on HipChat, if
>> this doesn't work out we'll see.
>>
>> Refer to my parallel email for Fedora instructions.
>>
>> Thanks,
>> Sanne
>>
>>
>>> On 17 May 2018 at 19:03, Steve Ebersole <steve at hibernate.org> wrote:
>>> I got an email from Atlassian this morning about the migration from HipChat
>>> to Stride.  Basically they have not gotten Stride feature-complete in terms
>>> of HipChat which is the trigger for the mass migration.  However, they are
>>> reaching out to all waiting teams to see if any want to migrate anyway.
>>> The list of missing features they sent me are:
>>>
>>>
>>>   1. Guest access
>>>   2. Some admin controls and compliance settings
>>>   3. Integrations with Atlassian server products (the Jira Server app is
>>>   currently in beta and coming soon) and some other popular integrations. See
>>>   all available Stride integrations
>>>   <http://click.mailer.atlassian.com/?qs=6712850cb7a4f2d4a207f46e5f190a454855738b8db6340974f28f3c2e1e6aa7c674a6314ad5df11014e5e2ee39bd3d4326606d2826b241a>
>>>   .
>>>   4. User management via API
>>>   5. Dark mode
>>>
>>> I am not really sure exactly what is missing WRT (2).  (3) is nice-to-have,
>>> but not blocker IMO assuming it gets added at some point.
>>>
>>> I think (1) is the only one that is concerning.  Though TBH for myself
>>> personally, I do not think registering is a big deal.
>>>
>>> Unless I hear otherwise, I plan on asking them to proceed with our
>>> migration to Stride.
>>> _______________________________________________
>>> 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 gbadner at redhat.com  Thu May 17 20:24:10 2018
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 17 May 2018 17:24:10 -0700
Subject: [hibernate-dev] Cache region names are not prefixed in 5.3
In-Reply-To: <CAFm4XO2AuHb5xH10C16qQN6Ws+s1e3bi8wmieZ9POVEqyOMDtw@mail.gmail.com>
References: <CAFDzhiS4YA4X6HSSwsni96Sn-=JOqZhOJXc1dxf6EZFJYWaq5Q@mail.gmail.com>
	<CAFm4XO29YAVEpzEr7M4B_CQHFbDPMSuPTiD=o4_trgBUiANFzA@mail.gmail.com>
	<CAFm4XO3BMjQ--e5xc2azge7YcLZ__1rbN-bDj6GyLLiohj8OdA@mail.gmail.com>
	<6a55397b-14d6-5484-219f-1e93e5c5d45b@redhat.com>
	<CAFm4XO2AuHb5xH10C16qQN6Ws+s1e3bi8wmieZ9POVEqyOMDtw@mail.gmail.com>
Message-ID: <CAFDzhiRND94RDfF=qA72KnRF5WK6ubfyBJ=wYnFfHgER+zuS0Q@mail.gmail.com>

I see that HHH-11356 removed prefixes from region names used by Hibernate.

I also noticed that entity regions are unprefixed and the package name is
removed.

I've created 2 issues:
HHH-12599 to add Javadoc to make it clear that region names are unprefixed;
HHH-12598 to add the package onto entity region names.

Should I create an ISPN issue for hibernate-infinispan (or whatever it's
referred to now) to add the prefixes?

On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 17 May 2018 at 12:09, Radim Vansa <rvansa at redhat.com> wrote:
> > I basically agree with Sanne here that having the prefix isolated opens
> > space for performance improvements, though if certain call is prefixed,
> > RegionFactory can always drop that prefix. The important thing is to
> mention
> > if the region name is prefixed or not in javadocs. I would also prefer if
> > *all* region names that RegionFactory is supposed to access followed the
> > same strategy (prefixed/not-prefixed).
> >
> > 5.1 included method
> >
> >     QueryResultsRegion buildQueryResultsRegion(String regionName,
> Properties
> > properties)
> >
> > where StandardQueryCache did the prefix for us, the change in 5.3 to
> >
> >     QueryResultsRegion buildQueryResultsRegion(String regionName,
> > SessionFactoryImplementor sessionFactory)
> >
> > does not indicate that the prefix won't be there and the javadoc is
> missing
> > completely.
> >
> > Also, DomainDataRegionConfig.getRegionName() has no javadoc and
> > RegionFactory does not add the prefix.
> >
> > @Steve could you please amend the javadoc and confirm if RF should prefix
> > region names?
> >
> > @Sanne while cache manager per deployment is an obvious way to
> distinguish
> > regions at deployments, CM holds some heavy resources (e.g. threads) - so I
> > while we are supposed to scale number of caches up to thousands (and
> we've
> > fixed some problems that arise when you have for example ~3k caches), ATM
> > you're not supposed to scale CMs. And I don't think that we'll focus in
> this
> > direction since the bright future lies in microservices :)
>
> Right, good points. It's a possible optimization I'd like to see
> eventually but it's not trivial to get there yet.
>
> Yet assuming a microservices scenario, this does become trivial to
> benefit from: the container knows there's a single deployment, a
> single CM. So no need to isolate them at all, just need to possibly
> isolate multiple PUs defined in the same service.
>
> So it will be easy to run hundreds of isolated microservices on the
> same physical CPU and kill each other via process contention :P
>
> >
> > Radim
> >
> >
> > On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
> >>
> >> On 17 May 2018 at 11:11, Sanne Grinovero <sanne at hibernate.org> wrote:
> >>>
> >>> I think this is the RegionFactory's responsibility, as Hibernate ORM
> >>> alone can't know if this is necessary.
> >>>
> >>> Prefixing is one of many options to isolate caches; a Cache technology
> >>> might wish to use a different approach by implementing a custom
> >>> `org.hibernate.cache.spi.CacheKeysFactory`.
> >>
> >> Hum, I regret how I wrote the above paragraph.
> >>
> >> I actually meant that a Cache technology could implement isolation in
> >> many different ways.
> >> Using a custom `CacheKeysFactory` is just an example, there are many
> >> other options as well. In fact, I believe a good choice for
> >> application servers would be to have an independent CacheManager for
> >> each deployment. Then it can safely inspect the deployment, see if
> >> there are multiple Persistence Units using the same caching
> >> technology, and implement further isolation only if necessary.
> >>
> >> These thoughts are a consequence of a chat I had with Paul Ferraro
> >> from the WildFly team, as he mentioned the size of the keys becoming
> >> problematic with all the additional prefixing they need to apply. I
> >> hope this will make it possible to e.g. create an "as small as
> >> possible" unique identifier for the deployments to replace the
> >> deployment name during serialization (to identify the CacheManager)
> >> followed by a numeric id indexing the PUs within the deployment - or
> >> nothing altogether in case of single PUs.
> >>
> >> Of course, I don't expect that to be needed right away; the
> >> RegionFactory could just do good old prefixing for now but I hope
> >> we'll explore such improvements in the near future.
> >>
> >> Thanks,
> >> Sanne
> >>
> >>> Not least the server / deployer might be able to hint the Cache
> >>> provider to tell if isolation is at all necessary.
> >>>
> >>> In conclusion, by having Hibernate ORM not messing with prefixes
> >>> allows other technologies to implement more efficient solutions. Our
> >>> own code also ends up being more efficient by not needing to add a
> >>> prefix during each and every access to the cache.
> >>>
> >>> Thanks,
> >>> Sanne
> >>>
> >>> On 17 May 2018 at 06:34, Gail Badner <gbadner at redhat.com> wrote:
> >>>>
> >>>> I see that cache region names are not being prefixed in 5.3.
> >>>>
> >>>> EnabledCaching sets the TimestampsRegion region name
> >>>> to TimestampsRegion.class.getName(), and sets the QueryResultsRegion
> >>>> region
> >>>> name to QueryResultsRegion.class.getName(). [1]
> >>>>
> >>>> Without a prefix, WildFly is failing intermittently when there are 2
> >>>> persistence units with the query cache enabled due to:
> >>>>
> >>>> org.infinispan.commons.CacheConfigurationException: ISPN000453:
> Attempt
> >>>> to
> >>>> define configuration for cache org.hibernate.cache.spi.
> TimestampsRegion
> >>>> which already exists
> >>>>
> >>>> Entity region names are not being prefixed either.
> >>>>
> >>>> Should they be prefixed by Hibernate or by the RegionFactory?
> >>>>
> >>>> Regards,
> >>>> Gail
> >>>>
> >>>> [1]
> >>>>
> >>>> https://github.com/hibernate/hibernate-orm/blob/master/
> hibernate-core/src/main/java/org/hibernate/cache/internal/
> EnabledCaching.java#L80-L92
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> >
> > --
> > Radim Vansa <rvansa at redhat.com>
> > JBoss Performance Team
> >
>

From gbadner at redhat.com  Thu May 17 20:54:18 2018
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 17 May 2018 17:54:18 -0700
Subject: [hibernate-dev] Cache region names are not prefixed in 5.3
In-Reply-To: <CAFDzhiRND94RDfF=qA72KnRF5WK6ubfyBJ=wYnFfHgER+zuS0Q@mail.gmail.com>
References: <CAFDzhiS4YA4X6HSSwsni96Sn-=JOqZhOJXc1dxf6EZFJYWaq5Q@mail.gmail.com>
	<CAFm4XO29YAVEpzEr7M4B_CQHFbDPMSuPTiD=o4_trgBUiANFzA@mail.gmail.com>
	<CAFm4XO3BMjQ--e5xc2azge7YcLZ__1rbN-bDj6GyLLiohj8OdA@mail.gmail.com>
	<6a55397b-14d6-5484-219f-1e93e5c5d45b@redhat.com>
	<CAFm4XO2AuHb5xH10C16qQN6Ws+s1e3bi8wmieZ9POVEqyOMDtw@mail.gmail.com>
	<CAFDzhiRND94RDfF=qA72KnRF5WK6ubfyBJ=wYnFfHgER+zuS0Q@mail.gmail.com>
Message-ID: <CAFDzhiQtr9FOZtcqULR7KBGT4scopuQoEheh+OJYTVa0jkev6Q@mail.gmail.com>

On Thu, May 17, 2018 at 5:24 PM, Gail Badner <gbadner at redhat.com> wrote:

> I see that HHH-11356 removed prefixes from region names used by Hibernate.
>
> I also noticed that entity regions are unprefixed and the package name is
> removed.
>

Actually, the package names are being included in the region names. The
test I was looking at did not have a package.


>
> I've created 2 issues:
> HHH-12599 to add Javadoc to make it clear that region names are unprefixed;
> HHH-12598 to add the package onto entity region names.
>

I've rejected HHH-12598.


>
> Should I create an ISPN issue for hibernate-infinispan (or whatever it's
> referred to now) to add the prefixes?
>
> On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 17 May 2018 at 12:09, Radim Vansa <rvansa at redhat.com> wrote:
>> > I basically agree with Sanne here that having the prefix isolated opens
>> > space for performance improvements, though if certain call is prefixed,
>> > RegionFactory can always drop that prefix. The important thing is to
>> mention
>> > if the region name is prefixed or not in javadocs. I would also prefer
>> if
>> > *all* region names that RegionFactory is supposed to access followed the
>> > same strategy (prefixed/not-prefixed).
>> >
>> > 5.1 included method
>> >
>> >     QueryResultsRegion buildQueryResultsRegion(String regionName,
>> Properties
>> > properties)
>> >
>> > where StandardQueryCache did the prefix for us, the change in 5.3 to
>> >
>> >     QueryResultsRegion buildQueryResultsRegion(String regionName,
>> > SessionFactoryImplementor sessionFactory)
>> >
>> > does not indicate that the prefix won't be there and the javadoc is
>> missing
>> > completely.
>> >
>> > Also, DomainDataRegionConfig.getRegionName() has no javadoc and
>> > RegionFactory does not add the prefix.
>> >
>> > @Steve could you please amend the javadoc and confirm if RF should
>> prefix
>> > region names?
>> >
>> > @Sanne while cache manager per deployment is an obvious way to
>> distinguish
>> > regions at deployments, CM holds some heavy resources (e.g. threads) - so
>> I
>> > while we are supposed to scale number of caches up to thousands (and
>> we've
>> > fixed some problems that arise when you have for example ~3k caches),
>> ATM
>> > you're not supposed to scale CMs. And I don't think that we'll focus in
>> this
>> > direction since the bright future lies in microservices :)
>>
>> Right, good points. It's a possible optimization I'd like to see
>> eventually but it's not trivial to get there yet.
>>
>> Yet assuming a microservices scenario, this does become trivial to
>> benefit from: the container knows there's a single deployment, a
>> single CM. So no need to isolate them at all, just need to possibly
>> isolate multiple PUs defined in the same service.
>>
>> So it will be easy to run hundreds of isolated microservices on the
>> same physical CPU and kill each other via process contention :P
>>
>> >
>> > Radim
>> >
>> >
>> > On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
>> >>
>> >> On 17 May 2018 at 11:11, Sanne Grinovero <sanne at hibernate.org> wrote:
>> >>>
>> >>> I think this is the RegionFactory's responsibility, as Hibernate ORM
>> >>> alone can't know if this is necessary.
>> >>>
>> >>> Prefixing is one of many options to isolate caches; a Cache technology
>> >>> might wish to use a different approach by implementing a custom
>> >>> `org.hibernate.cache.spi.CacheKeysFactory`.
>> >>
>> >> Hum, I regret how I wrote the above paragraph.
>> >>
>> >> I actually meant that a Cache technology could implement isolation in
>> >> many different ways.
>> >> Using a custom `CacheKeysFactory` is just an example, there are many
>> >> other options as well. In fact, I believe a good choice for
>> >> application servers would be to have an independent CacheManager for
>> >> each deployment. Then it can safely inspect the deployment, see if
>> >> there are multiple Persistence Units using the same caching
>> >> technology, and implement further isolation only if necessary.
>> >>
>> >> These thoughts are a consequence of a chat I had with Paul Ferraro
>> >> from the WildFly team, as he mentioned the size of the keys becoming
>> >> problematic with all the additional prefixing they need to apply. I
>> >> hope this will make it possible to e.g. create an "as small as
>> >> possible" unique identifier for the deployments to replace the
>> >> deployment name during serialization (to identify the CacheManager)
>> >> followed by a numeric id indexing the PUs within the deployment - or
>> >> nothing altogether in case of single PUs.
>> >>
>> >> Of course, I don't expect that to be needed right away; the
>> >> RegionFactory could just do good old prefixing for now but I hope
>> >> we'll explore such improvements in the near future.
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >>> Not least the server / deployer might be able to hint the Cache
>> >>> provider to tell if isolation is at all necessary.
>> >>>
>> >>> In conclusion, by having Hibernate ORM not messing with prefixes
>> >>> allows other technologies to implement more efficient solutions. Our
>> >>> own code also ends up being more efficient by not needing to add a
>> >>> prefix during each and every access to the cache.
>> >>>
>> >>> Thanks,
>> >>> Sanne
>> >>>
>> >>> On 17 May 2018 at 06:34, Gail Badner <gbadner at redhat.com> wrote:
>> >>>>
>> >>>> I see that cache region names are not being prefixed in 5.3.
>> >>>>
>> >>>> EnabledCaching sets the TimestampsRegion region name
>> >>>> to TimestampsRegion.class.getName(), and sets the QueryResultsRegion
>> >>>> region
>> >>>> name to QueryResultsRegion.class.getName(). [1]
>> >>>>
>> >>>> Without a prefix, WildFly is failing intermittently when there are 2
>> >>>> persistence units with the query cache enabled due to:
>> >>>>
>> >>>> org.infinispan.commons.CacheConfigurationException: ISPN000453:
>> Attempt
>> >>>> to
>> >>>> define configuration for cache org.hibernate.cache.spi.Timest
>> ampsRegion
>> >>>> which already exists
>> >>>>
>> >>>> Entity region names are not being prefixed either.
>> >>>>
>> >>>> Should they be prefixed by Hibernate or by the RegionFactory?
>> >>>>
>> >>>> Regards,
>> >>>> Gail
>> >>>>
>> >>>> [1]
>> >>>>
>> >>>> https://github.com/hibernate/hibernate-orm/blob/master/hiber
>> nate-core/src/main/java/org/hibernate/cache/internal/Enabl
>> edCaching.java#L80-L92
>> >>>> _______________________________________________
>> >>>> hibernate-dev mailing list
>> >>>> hibernate-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>> >
>> > --
>> > Radim Vansa <rvansa at redhat.com>
>> > JBoss Performance Team
>> >
>>
>
>

From rvansa at redhat.com  Fri May 18 02:57:59 2018
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 18 May 2018 08:57:59 +0200
Subject: [hibernate-dev] Stride
In-Reply-To: <CAFm4XO1YC1e_yLEawfX-+Mro-WEuM=pGB_DC3NPbYpvn0HNmnA@mail.gmail.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
	<CAFm4XO2UzDPv+BnkG_=QT+pLWxVyCK5u1-B8FZPpQfOG7GemLg@mail.gmail.com>
	<4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com>
	<CAFm4XO1YC1e_yLEawfX-+Mro-WEuM=pGB_DC3NPbYpvn0HNmnA@mail.gmail.com>
Message-ID: <dda4b285-f0ae-e961-26c1-05e3b29d56ee@redhat.com>

Just out of curiosity, when choosing a replacement for HipChat, have you 
considered Zulip?

Infinispan uses that for about a month now and besides being too 
colourful (similar to HipChat) there's been positive feedback, 
especially due to the threading feature.

Radim [trying to lure everyone to the same client]

On 05/18/2018 12:16 AM, Sanne Grinovero wrote:
> On 17 May 2018 at 20:32, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>> By the way, you say it?s clear we don?t want to stay on HipChat.
>>
>> When did we decide that? I don?t remember a discussion about it.
> I didn't say it was decided, but I think we're working on that since
> Steve asked about it today. To which I agree *because* it seems clear
> to me that we don't want to stay on it - a notion I inferred from
> multiple previous discussions.
>
> Steve pointed out multiple flaws e.g. the native client packaging
> broken on Fedora, to which Atlassian pretty much replied by letting us
> know they won't invest in HipChat as the future is Stride. We can
> choose when to switch but staying doesn't look sensible to me as it
> certainly won't improve; it's also likely that they'll want everyone
> migrated eventually so to shut the existing service down.
>
> I for one gave up as well installing the native client and have been
> using the web client since setting up my new workstation, as I was
> expecting Stride to arrive soon.
>
> The other day some people tried to join and gave up because of login
> complexity - that's IMO a very bad sign: not welcoming community
> people means it's failing its primary requirements.
>
> And let's not forget all authentication nonsense; especially days that
> I'm working more on the WildFly side of things and need to login to
> multiple instances I really look forward to a better system (hopefully
> it is!?).
>
> Question, since you want a decision: are you only suggesting to delay
> or suggesting that you should rather stay on HipChat?
>
> Personally, I'm fine delaying a bit even though I can live happily
> without Jenkins notifications, but let's hear the others as well.
>
> Thanks,
> Sanne
>
>
>> For sure, we probably won?t have a choice because there?s a good chance Atlassian will close the service but what are the problems that make a migration so urgent?
>>
>>> Le 17 mai 2018 ? 20:16, Sanne Grinovero <sanne at hibernate.org> a ?crit :
>>>
>>> lol, I was writing about the same to the team list.
>>>
>>> +1 to have people register, it's better for them anyway. I checked
>>> it's easier to self-register.
>>>
>>> +1 to migrate quickly. It's clear we don't want to stay on HipChat, if
>>> this doesn't work out we'll see.
>>>
>>> Refer to my parallel email for Fedora instructions.
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>>> On 17 May 2018 at 19:03, Steve Ebersole <steve at hibernate.org> wrote:
>>>> I got an email from Atlassian this morning about the migration from HipChat
>>>> to Stride.  Basically they have not gotten Stride feature-complete in terms
>>>> of HipChat which is the trigger for the mass migration.  However, they are
>>>> reaching out to all waiting teams to see if any want to migrate anyway.
>>>> The list of missing features they sent me are:
>>>>
>>>>
>>>>    1. Guest access
>>>>    2. Some admin controls and compliance settings
>>>>    3. Integrations with Atlassian server products (the Jira Server app is
>>>>    currently in beta and coming soon) and some other popular integrations. See
>>>>    all available Stride integrations
>>>>    <http://click.mailer.atlassian.com/?qs=6712850cb7a4f2d4a207f46e5f190a454855738b8db6340974f28f3c2e1e6aa7c674a6314ad5df11014e5e2ee39bd3d4326606d2826b241a>
>>>>    .
>>>>    4. User management via API
>>>>    5. Dark mode
>>>>
>>>> I am not really sure exactly what is missing WRT (2).  (3) is nice-to-have,
>>>> but not blocker IMO assuming it gets added at some point.
>>>>
>>>> I think (1) is the only one that is concerning.  Though TBH for myself
>>>> personally, I do not think registering is a big deal.
>>>>
>>>> Unless I hear otherwise, I plan on asking them to proceed with our
>>>> migration to Stride.
>>>> _______________________________________________
>>>> 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


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


From rvansa at redhat.com  Fri May 18 03:02:15 2018
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 18 May 2018 09:02:15 +0200
Subject: [hibernate-dev] Cache region names are not prefixed in 5.3
In-Reply-To: <CAFDzhiQtr9FOZtcqULR7KBGT4scopuQoEheh+OJYTVa0jkev6Q@mail.gmail.com>
References: <CAFDzhiS4YA4X6HSSwsni96Sn-=JOqZhOJXc1dxf6EZFJYWaq5Q@mail.gmail.com>
	<CAFm4XO29YAVEpzEr7M4B_CQHFbDPMSuPTiD=o4_trgBUiANFzA@mail.gmail.com>
	<CAFm4XO3BMjQ--e5xc2azge7YcLZ__1rbN-bDj6GyLLiohj8OdA@mail.gmail.com>
	<6a55397b-14d6-5484-219f-1e93e5c5d45b@redhat.com>
	<CAFm4XO2AuHb5xH10C16qQN6Ws+s1e3bi8wmieZ9POVEqyOMDtw@mail.gmail.com>
	<CAFDzhiRND94RDfF=qA72KnRF5WK6ubfyBJ=wYnFfHgER+zuS0Q@mail.gmail.com>
	<CAFDzhiQtr9FOZtcqULR7KBGT4scopuQoEheh+OJYTVa0jkev6Q@mail.gmail.com>
Message-ID: <753a5115-03e7-3bfc-2444-a42fc21758c5@redhat.com>

On 05/18/2018 02:54 AM, Gail Badner wrote:
>
>
> On Thu, May 17, 2018 at 5:24 PM, Gail Badner <gbadner at redhat.com 
> <mailto:gbadner at redhat.com>> wrote:
>
>     I see that?HHH-11356 removed prefixes from region names used by
>     Hibernate.
>
>     I also noticed that entity regions are unprefixed and the package
>     name is removed.
>
>
> Actually, the package names are being included in the region names. 
> The test I was looking at did not have a package.
>
>
>     I've created 2 issues:
>     HHH-12599 to add Javadoc to make it clear that region names are
>     unprefixed;
>     HHH-12598 to add the package onto entity region names.
>
>
> I've rejected HHH-12598.
>
>
>     Should I create an ISPN issue for hibernate-infinispan (or
>     whatever it's referred to now) to add the prefixes?
>

I take it as confirmed that RegionFactory is supposed to do this. 
Created https://issues.jboss.org/browse/ISPN-9174

R.

>
>     On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero
>     <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
>
>         On 17 May 2018 at 12:09, Radim Vansa <rvansa at redhat.com
>         <mailto:rvansa at redhat.com>> wrote:
>         > I basically agree with Sanne here that having the prefix
>         isolated opens
>         > space for performance improvements, though if certain call
>         is prefixed,
>         > RegionFactory can always drop that prefix. The important
>         thing is to mention
>         > if the region name is prefixed or not in javadocs. I would
>         also prefer if
>         > *all* region names that RegionFactory is supposed to access
>         followed the
>         > same strategy (prefixed/not-prefixed).
>         >
>         > 5.1 included method
>         >
>         >? ? ?QueryResultsRegion buildQueryResultsRegion(String
>         regionName, Properties
>         > properties)
>         >
>         > where StandardQueryCache did the prefix for us, the change
>         in 5.3 to
>         >
>         >? ? ?QueryResultsRegion buildQueryResultsRegion(String
>         regionName,
>         > SessionFactoryImplementor sessionFactory)
>         >
>         > does not indicate that the prefix won't be there and the
>         javadoc is missing
>         > completely.
>         >
>         > Also, DomainDataRegionConfig.getRegionName() has no javadoc and
>         > RegionFactory does not add the prefix.
>         >
>         > @Steve could you please amend the javadoc and confirm if RF
>         should prefix
>         > region names?
>         >
>         > @Sanne while cache manager per deployment is an obvious way
>         to distinguish
>         > regions at deployments, CM holds some heavy resources (e.g.
>         threads) - so I
>         > while we are supposed to scale number of caches up to
>         thousands (and we've
>         > fixed some problems that arise when you have for example ~3k
>         caches), ATM
>         > you're not supposed to scale CMs. And I don't think that
>         we'll focus in this
>         > direction since the bright future lies in microservices :)
>
>         Right, good points. It's a possible optimization I'd like to see
>         eventually but it's not trivial to get there yet.
>
>         Yet assuming a microservices scenario, this does become trivial to
>         benefit from: the container knows there's a single deployment, a
>         single CM. So no need to isolate them at all, just need to
>         possibly
>         isolate multiple PUs defined in the same service.
>
>         So it will be easy to run hundreds of isolated microservices
>         on the
>         same physical CPU and kill each other via process contention :P
>
>         >
>         > Radim
>         >
>         >
>         > On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
>         >>
>         >> On 17 May 2018 at 11:11, Sanne Grinovero
>         <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
>         >>>
>         >>> I think this is the RegionFactory's responsibility, as
>         Hibernate ORM
>         >>> alone can't know if this is necessary.
>         >>>
>         >>> Prefixing is one of many options to isolate caches; a
>         Cache technology
>         >>> might wish to use a different approach by implementing a
>         custom
>         >>> `org.hibernate.cache.spi.CacheKeysFactory`.
>         >>
>         >> Hum, I regret how I wrote the above paragraph.
>         >>
>         >> I actually meant that a Cache technology could implement
>         isolation in
>         >> many different ways.
>         >> Using a custom `CacheKeysFactory` is just an example, there
>         are many
>         >> other options as well. In fact, I believe a good choice for
>         >> application servers would be to have an independent
>         CacheManager for
>         >> each deployment. Then it can safely inspect the deployment,
>         see if
>         >> there are multiple Persistence Units using the same caching
>         >> technology, and implement further isolation only if necessary.
>         >>
>         >> These thoughts are a consequence of a chat I had with Paul
>         Ferraro
>         >> from the WildFly team, as he mentioned the size of the keys
>         becoming
>         >> problematic with all the additional prefixing they need to
>         apply. I
>         >> hope this will make it possible to e.g. create an "as small as
>         >> possible" unique identifier for the deployments to replace the
>         >> deployment name during serialization (to identify the
>         CacheManager)
>         >> followed by a numeric id indexing the PUs within the
>         deployment - or
>         >> nothing altogether in case of single PUs.
>         >>
>         >> Of course, I don't expect that to be needed right away; the
>         >> RegionFactory could just do good old prefixing for now but
>         I hope
>         >> we'll explore such improvements in the near future.
>         >>
>         >> Thanks,
>         >> Sanne
>         >>
>         >>> Not least the server / deployer might be able to hint the
>         Cache
>         >>> provider to tell if isolation is at all necessary.
>         >>>
>         >>> In conclusion, by having Hibernate ORM not messing with
>         prefixes
>         >>> allows other technologies to implement more efficient
>         solutions. Our
>         >>> own code also ends up being more efficient by not needing
>         to add a
>         >>> prefix during each and every access to the cache.
>         >>>
>         >>> Thanks,
>         >>> Sanne
>         >>>
>         >>> On 17 May 2018 at 06:34, Gail Badner <gbadner at redhat.com
>         <mailto:gbadner at redhat.com>> wrote:
>         >>>>
>         >>>> I see that cache region names are not being prefixed in 5.3.
>         >>>>
>         >>>> EnabledCaching sets the TimestampsRegion region name
>         >>>> to TimestampsRegion.class.getName(), and sets the
>         QueryResultsRegion
>         >>>> region
>         >>>> name to QueryResultsRegion.class.getName(). [1]
>         >>>>
>         >>>> Without a prefix, WildFly is failing intermittently when
>         there are 2
>         >>>> persistence units with the query cache enabled due to:
>         >>>>
>         >>>> org.infinispan.commons.CacheConfigurationException:
>         ISPN000453: Attempt
>         >>>> to
>         >>>> define configuration for cache
>         org.hibernate.cache.spi.TimestampsRegion
>         >>>> which already exists
>         >>>>
>         >>>> Entity region names are not being prefixed either.
>         >>>>
>         >>>> Should they be prefixed by Hibernate or by the RegionFactory?
>         >>>>
>         >>>> Regards,
>         >>>> Gail
>         >>>>
>         >>>> [1]
>         >>>>
>         >>>>
>         https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92
>         <https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92>
>         >>>> _______________________________________________
>         >>>> hibernate-dev mailing list
>         >>>> hibernate-dev at lists.jboss.org
>         <mailto:hibernate-dev at lists.jboss.org>
>         >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>         <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>         >
>         >
>         >
>         > --
>         > Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>         > JBoss Performance Team
>         >
>
>
>

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


From rvansa at redhat.com  Fri May 18 03:37:44 2018
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 18 May 2018 09:37:44 +0200
Subject: [hibernate-dev] Cache region names are not prefixed in 5.3
In-Reply-To: <753a5115-03e7-3bfc-2444-a42fc21758c5@redhat.com>
References: <CAFDzhiS4YA4X6HSSwsni96Sn-=JOqZhOJXc1dxf6EZFJYWaq5Q@mail.gmail.com>
	<CAFm4XO29YAVEpzEr7M4B_CQHFbDPMSuPTiD=o4_trgBUiANFzA@mail.gmail.com>
	<CAFm4XO3BMjQ--e5xc2azge7YcLZ__1rbN-bDj6GyLLiohj8OdA@mail.gmail.com>
	<6a55397b-14d6-5484-219f-1e93e5c5d45b@redhat.com>
	<CAFm4XO2AuHb5xH10C16qQN6Ws+s1e3bi8wmieZ9POVEqyOMDtw@mail.gmail.com>
	<CAFDzhiRND94RDfF=qA72KnRF5WK6ubfyBJ=wYnFfHgER+zuS0Q@mail.gmail.com>
	<CAFDzhiQtr9FOZtcqULR7KBGT4scopuQoEheh+OJYTVa0jkev6Q@mail.gmail.com>
	<753a5115-03e7-3bfc-2444-a42fc21758c5@redhat.com>
Message-ID: <06eb39bd-3f48-c348-622d-97e162f4229f@redhat.com>

One thing I've stumbled upon: it seems that RegionFactory should call 
its method qualify(String regionName) to produce the prefixed region 
name. Following Hibernate's implementation I use RegionNameQualifier for 
this, which uses prefix + '.' + regionName.

In previous versions the dot was missing from the qualifier - is this 
something that could break backwards compatibility? E.g. in WF to let 
2LC use specific cache configuration you need to set 
`hibernate.cache.infinispan.deployment#entity.name.cfg` - I wonder if 
the qualified region name becomes deployment#.entity.name now...

Radim

On 05/18/2018 09:02 AM, Radim Vansa wrote:
> On 05/18/2018 02:54 AM, Gail Badner wrote:
>>
>>
>> On Thu, May 17, 2018 at 5:24 PM, Gail Badner <gbadner at redhat.com 
>> <mailto:gbadner at redhat.com>> wrote:
>>
>> ??? I see that?HHH-11356 removed prefixes from region names used by
>> ??? Hibernate.
>>
>> ??? I also noticed that entity regions are unprefixed and the package
>> ??? name is removed.
>>
>>
>> Actually, the package names are being included in the region names. 
>> The test I was looking at did not have a package.
>>
>>
>> ??? I've created 2 issues:
>> ??? HHH-12599 to add Javadoc to make it clear that region names are
>> ??? unprefixed;
>> ??? HHH-12598 to add the package onto entity region names.
>>
>>
>> I've rejected HHH-12598.
>>
>>
>> ??? Should I create an ISPN issue for hibernate-infinispan (or
>> ??? whatever it's referred to now) to add the prefixes?
>>
>
> I take it as confirmed that RegionFactory is supposed to do this. 
> Created https://issues.jboss.org/browse/ISPN-9174
>
> R.
>
>>
>> ??? On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero
>> ??? <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
>>
>> ??????? On 17 May 2018 at 12:09, Radim Vansa <rvansa at redhat.com
>> ??????? <mailto:rvansa at redhat.com>> wrote:
>> ??????? > I basically agree with Sanne here that having the prefix
>> ??????? isolated opens
>> ??????? > space for performance improvements, though if certain call
>> ??????? is prefixed,
>> ??????? > RegionFactory can always drop that prefix. The important
>> ??????? thing is to mention
>> ??????? > if the region name is prefixed or not in javadocs. I would
>> ??????? also prefer if
>> ??????? > *all* region names that RegionFactory is supposed to access
>> ??????? followed the
>> ??????? > same strategy (prefixed/not-prefixed).
>> ??????? >
>> ??????? > 5.1 included method
>> ??????? >
>> ??????? >? ? ?QueryResultsRegion buildQueryResultsRegion(String
>> ??????? regionName, Properties
>> ??????? > properties)
>> ??????? >
>> ??????? > where StandardQueryCache did the prefix for us, the change
>> ??????? in 5.3 to
>> ??????? >
>> ??????? >? ? ?QueryResultsRegion buildQueryResultsRegion(String
>> ??????? regionName,
>> ??????? > SessionFactoryImplementor sessionFactory)
>> ??????? >
>> ??????? > does not indicate that the prefix won't be there and the
>> ??????? javadoc is missing
>> ??????? > completely.
>> ??????? >
>> ??????? > Also, DomainDataRegionConfig.getRegionName() has no javadoc 
>> and
>> ??????? > RegionFactory does not add the prefix.
>> ??????? >
>> ??????? > @Steve could you please amend the javadoc and confirm if RF
>> ??????? should prefix
>> ??????? > region names?
>> ??????? >
>> ??????? > @Sanne while cache manager per deployment is an obvious way
>> ??????? to distinguish
>> ??????? > regions at deployments, CM holds some heavy resources (e.g.
>> ??????? threads) - so I
>> ??????? > while we are supposed to scale number of caches up to
>> ??????? thousands (and we've
>> ??????? > fixed some problems that arise when you have for example ~3k
>> ??????? caches), ATM
>> ??????? > you're not supposed to scale CMs. And I don't think that
>> ??????? we'll focus in this
>> ??????? > direction since the bright future lies in microservices :)
>>
>> ??????? Right, good points. It's a possible optimization I'd like to see
>> ??????? eventually but it's not trivial to get there yet.
>>
>> ??????? Yet assuming a microservices scenario, this does become 
>> trivial to
>> ??????? benefit from: the container knows there's a single deployment, a
>> ??????? single CM. So no need to isolate them at all, just need to
>> ??????? possibly
>> ??????? isolate multiple PUs defined in the same service.
>>
>> ??????? So it will be easy to run hundreds of isolated microservices
>> ??????? on the
>> ??????? same physical CPU and kill each other via process contention :P
>>
>> ??????? >
>> ??????? > Radim
>> ??????? >
>> ??????? >
>> ??????? > On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
>> ??????? >>
>> ??????? >> On 17 May 2018 at 11:11, Sanne Grinovero
>> ??????? <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
>> ??????? >>>
>> ??????? >>> I think this is the RegionFactory's responsibility, as
>> ??????? Hibernate ORM
>> ??????? >>> alone can't know if this is necessary.
>> ??????? >>>
>> ??????? >>> Prefixing is one of many options to isolate caches; a
>> ??????? Cache technology
>> ??????? >>> might wish to use a different approach by implementing a
>> ??????? custom
>> ??????? >>> `org.hibernate.cache.spi.CacheKeysFactory`.
>> ??????? >>
>> ??????? >> Hum, I regret how I wrote the above paragraph.
>> ??????? >>
>> ??????? >> I actually meant that a Cache technology could implement
>> ??????? isolation in
>> ??????? >> many different ways.
>> ??????? >> Using a custom `CacheKeysFactory` is just an example, there
>> ??????? are many
>> ??????? >> other options as well. In fact, I believe a good choice for
>> ??????? >> application servers would be to have an independent
>> ??????? CacheManager for
>> ??????? >> each deployment. Then it can safely inspect the deployment,
>> ??????? see if
>> ??????? >> there are multiple Persistence Units using the same caching
>> ??????? >> technology, and implement further isolation only if 
>> necessary.
>> ??????? >>
>> ??????? >> These thoughts are a consequence of a chat I had with Paul
>> ??????? Ferraro
>> ??????? >> from the WildFly team, as he mentioned the size of the keys
>> ??????? becoming
>> ??????? >> problematic with all the additional prefixing they need to
>> ??????? apply. I
>> ??????? >> hope this will make it possible to e.g. create an "as 
>> small as
>> ??????? >> possible" unique identifier for the deployments to replace 
>> the
>> ??????? >> deployment name during serialization (to identify the
>> ??????? CacheManager)
>> ??????? >> followed by a numeric id indexing the PUs within the
>> ??????? deployment - or
>> ??????? >> nothing altogether in case of single PUs.
>> ??????? >>
>> ??????? >> Of course, I don't expect that to be needed right away; the
>> ??????? >> RegionFactory could just do good old prefixing for now but
>> ??????? I hope
>> ??????? >> we'll explore such improvements in the near future.
>> ??????? >>
>> ??????? >> Thanks,
>> ??????? >> Sanne
>> ??????? >>
>> ??????? >>> Not least the server / deployer might be able to hint the
>> ??????? Cache
>> ??????? >>> provider to tell if isolation is at all necessary.
>> ??????? >>>
>> ??????? >>> In conclusion, by having Hibernate ORM not messing with
>> ??????? prefixes
>> ??????? >>> allows other technologies to implement more efficient
>> ??????? solutions. Our
>> ??????? >>> own code also ends up being more efficient by not needing
>> ??????? to add a
>> ??????? >>> prefix during each and every access to the cache.
>> ??????? >>>
>> ??????? >>> Thanks,
>> ??????? >>> Sanne
>> ??????? >>>
>> ??????? >>> On 17 May 2018 at 06:34, Gail Badner <gbadner at redhat.com
>> ??????? <mailto:gbadner at redhat.com>> wrote:
>> ??????? >>>>
>> ??????? >>>> I see that cache region names are not being prefixed in 
>> 5.3.
>> ??????? >>>>
>> ??????? >>>> EnabledCaching sets the TimestampsRegion region name
>> ??????? >>>> to TimestampsRegion.class.getName(), and sets the
>> ??????? QueryResultsRegion
>> ??????? >>>> region
>> ??????? >>>> name to QueryResultsRegion.class.getName(). [1]
>> ??????? >>>>
>> ??????? >>>> Without a prefix, WildFly is failing intermittently when
>> ??????? there are 2
>> ??????? >>>> persistence units with the query cache enabled due to:
>> ??????? >>>>
>> ??????? >>>> org.infinispan.commons.CacheConfigurationException:
>> ??????? ISPN000453: Attempt
>> ??????? >>>> to
>> ??????? >>>> define configuration for cache
>> ??????? org.hibernate.cache.spi.TimestampsRegion
>> ??????? >>>> which already exists
>> ??????? >>>>
>> ??????? >>>> Entity region names are not being prefixed either.
>> ??????? >>>>
>> ??????? >>>> Should they be prefixed by Hibernate or by the 
>> RegionFactory?
>> ??????? >>>>
>> ??????? >>>> Regards,
>> ??????? >>>> Gail
>> ??????? >>>>
>> ??????? >>>> [1]
>> ??????? >>>>
>> ??????? >>>>
>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92
>> <https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92>
>> ??????? >>>> _______________________________________________
>> ??????? >>>> hibernate-dev mailing list
>> ??????? >>>> hibernate-dev at lists.jboss.org
>> ??????? <mailto:hibernate-dev at lists.jboss.org>
>> ??????? >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> ??????? >
>> ??????? >
>> ??????? >
>> ??????? > --
>> ??????? > Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>> ??????? > JBoss Performance Team
>> ??????? >
>>
>>
>>
>

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


From rvansa at redhat.com  Fri May 18 04:01:29 2018
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 18 May 2018 10:01:29 +0200
Subject: [hibernate-dev] Cache region names are not prefixed in 5.3
In-Reply-To: <06eb39bd-3f48-c348-622d-97e162f4229f@redhat.com>
References: <CAFDzhiS4YA4X6HSSwsni96Sn-=JOqZhOJXc1dxf6EZFJYWaq5Q@mail.gmail.com>
	<CAFm4XO29YAVEpzEr7M4B_CQHFbDPMSuPTiD=o4_trgBUiANFzA@mail.gmail.com>
	<CAFm4XO3BMjQ--e5xc2azge7YcLZ__1rbN-bDj6GyLLiohj8OdA@mail.gmail.com>
	<6a55397b-14d6-5484-219f-1e93e5c5d45b@redhat.com>
	<CAFm4XO2AuHb5xH10C16qQN6Ws+s1e3bi8wmieZ9POVEqyOMDtw@mail.gmail.com>
	<CAFDzhiRND94RDfF=qA72KnRF5WK6ubfyBJ=wYnFfHgER+zuS0Q@mail.gmail.com>
	<CAFDzhiQtr9FOZtcqULR7KBGT4scopuQoEheh+OJYTVa0jkev6Q@mail.gmail.com>
	<753a5115-03e7-3bfc-2444-a42fc21758c5@redhat.com>
	<06eb39bd-3f48-c348-622d-97e162f4229f@redhat.com>
Message-ID: <78881d03-0fad-7b41-12b4-200f85151f09@redhat.com>

Ignore me, panicked too quickly... the dot is added there in 5.1 as well.

On 05/18/2018 09:37 AM, Radim Vansa wrote:
> One thing I've stumbled upon: it seems that RegionFactory should call 
> its method qualify(String regionName) to produce the prefixed region 
> name. Following Hibernate's implementation I use RegionNameQualifier 
> for this, which uses prefix + '.' + regionName.
>
> In previous versions the dot was missing from the qualifier - is this 
> something that could break backwards compatibility? E.g. in WF to let 
> 2LC use specific cache configuration you need to set 
> `hibernate.cache.infinispan.deployment#entity.name.cfg` - I wonder if 
> the qualified region name becomes deployment#.entity.name now...
>
> Radim
>
> On 05/18/2018 09:02 AM, Radim Vansa wrote:
>> On 05/18/2018 02:54 AM, Gail Badner wrote:
>>>
>>>
>>> On Thu, May 17, 2018 at 5:24 PM, Gail Badner <gbadner at redhat.com 
>>> <mailto:gbadner at redhat.com>> wrote:
>>>
>>> ??? I see that?HHH-11356 removed prefixes from region names used by
>>> ??? Hibernate.
>>>
>>> ??? I also noticed that entity regions are unprefixed and the package
>>> ??? name is removed.
>>>
>>>
>>> Actually, the package names are being included in the region names. 
>>> The test I was looking at did not have a package.
>>>
>>>
>>> ??? I've created 2 issues:
>>> ??? HHH-12599 to add Javadoc to make it clear that region names are
>>> ??? unprefixed;
>>> ??? HHH-12598 to add the package onto entity region names.
>>>
>>>
>>> I've rejected HHH-12598.
>>>
>>>
>>> ??? Should I create an ISPN issue for hibernate-infinispan (or
>>> ??? whatever it's referred to now) to add the prefixes?
>>>
>>
>> I take it as confirmed that RegionFactory is supposed to do this. 
>> Created https://issues.jboss.org/browse/ISPN-9174
>>
>> R.
>>
>>>
>>> ??? On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero
>>> ??? <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
>>>
>>> ??????? On 17 May 2018 at 12:09, Radim Vansa <rvansa at redhat.com
>>> ??????? <mailto:rvansa at redhat.com>> wrote:
>>> ??????? > I basically agree with Sanne here that having the prefix
>>> ??????? isolated opens
>>> ??????? > space for performance improvements, though if certain call
>>> ??????? is prefixed,
>>> ??????? > RegionFactory can always drop that prefix. The important
>>> ??????? thing is to mention
>>> ??????? > if the region name is prefixed or not in javadocs. I would
>>> ??????? also prefer if
>>> ??????? > *all* region names that RegionFactory is supposed to access
>>> ??????? followed the
>>> ??????? > same strategy (prefixed/not-prefixed).
>>> ??????? >
>>> ??????? > 5.1 included method
>>> ??????? >
>>> ??????? >? ? ?QueryResultsRegion buildQueryResultsRegion(String
>>> ??????? regionName, Properties
>>> ??????? > properties)
>>> ??????? >
>>> ??????? > where StandardQueryCache did the prefix for us, the change
>>> ??????? in 5.3 to
>>> ??????? >
>>> ??????? >? ? ?QueryResultsRegion buildQueryResultsRegion(String
>>> ??????? regionName,
>>> ??????? > SessionFactoryImplementor sessionFactory)
>>> ??????? >
>>> ??????? > does not indicate that the prefix won't be there and the
>>> ??????? javadoc is missing
>>> ??????? > completely.
>>> ??????? >
>>> ??????? > Also, DomainDataRegionConfig.getRegionName() has no 
>>> javadoc and
>>> ??????? > RegionFactory does not add the prefix.
>>> ??????? >
>>> ??????? > @Steve could you please amend the javadoc and confirm if RF
>>> ??????? should prefix
>>> ??????? > region names?
>>> ??????? >
>>> ??????? > @Sanne while cache manager per deployment is an obvious way
>>> ??????? to distinguish
>>> ??????? > regions at deployments, CM holds some heavy resources (e.g.
>>> ??????? threads) - so I
>>> ??????? > while we are supposed to scale number of caches up to
>>> ??????? thousands (and we've
>>> ??????? > fixed some problems that arise when you have for example ~3k
>>> ??????? caches), ATM
>>> ??????? > you're not supposed to scale CMs. And I don't think that
>>> ??????? we'll focus in this
>>> ??????? > direction since the bright future lies in microservices :)
>>>
>>> ??????? Right, good points. It's a possible optimization I'd like to 
>>> see
>>> ??????? eventually but it's not trivial to get there yet.
>>>
>>> ??????? Yet assuming a microservices scenario, this does become 
>>> trivial to
>>> ??????? benefit from: the container knows there's a single 
>>> deployment, a
>>> ??????? single CM. So no need to isolate them at all, just need to
>>> ??????? possibly
>>> ??????? isolate multiple PUs defined in the same service.
>>>
>>> ??????? So it will be easy to run hundreds of isolated microservices
>>> ??????? on the
>>> ??????? same physical CPU and kill each other via process contention :P
>>>
>>> ??????? >
>>> ??????? > Radim
>>> ??????? >
>>> ??????? >
>>> ??????? > On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
>>> ??????? >>
>>> ??????? >> On 17 May 2018 at 11:11, Sanne Grinovero
>>> ??????? <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
>>> ??????? >>>
>>> ??????? >>> I think this is the RegionFactory's responsibility, as
>>> ??????? Hibernate ORM
>>> ??????? >>> alone can't know if this is necessary.
>>> ??????? >>>
>>> ??????? >>> Prefixing is one of many options to isolate caches; a
>>> ??????? Cache technology
>>> ??????? >>> might wish to use a different approach by implementing a
>>> ??????? custom
>>> ??????? >>> `org.hibernate.cache.spi.CacheKeysFactory`.
>>> ??????? >>
>>> ??????? >> Hum, I regret how I wrote the above paragraph.
>>> ??????? >>
>>> ??????? >> I actually meant that a Cache technology could implement
>>> ??????? isolation in
>>> ??????? >> many different ways.
>>> ??????? >> Using a custom `CacheKeysFactory` is just an example, there
>>> ??????? are many
>>> ??????? >> other options as well. In fact, I believe a good choice for
>>> ??????? >> application servers would be to have an independent
>>> ??????? CacheManager for
>>> ??????? >> each deployment. Then it can safely inspect the deployment,
>>> ??????? see if
>>> ??????? >> there are multiple Persistence Units using the same caching
>>> ??????? >> technology, and implement further isolation only if 
>>> necessary.
>>> ??????? >>
>>> ??????? >> These thoughts are a consequence of a chat I had with Paul
>>> ??????? Ferraro
>>> ??????? >> from the WildFly team, as he mentioned the size of the keys
>>> ??????? becoming
>>> ??????? >> problematic with all the additional prefixing they need to
>>> ??????? apply. I
>>> ??????? >> hope this will make it possible to e.g. create an "as 
>>> small as
>>> ??????? >> possible" unique identifier for the deployments to 
>>> replace the
>>> ??????? >> deployment name during serialization (to identify the
>>> ??????? CacheManager)
>>> ??????? >> followed by a numeric id indexing the PUs within the
>>> ??????? deployment - or
>>> ??????? >> nothing altogether in case of single PUs.
>>> ??????? >>
>>> ??????? >> Of course, I don't expect that to be needed right away; the
>>> ??????? >> RegionFactory could just do good old prefixing for now but
>>> ??????? I hope
>>> ??????? >> we'll explore such improvements in the near future.
>>> ??????? >>
>>> ??????? >> Thanks,
>>> ??????? >> Sanne
>>> ??????? >>
>>> ??????? >>> Not least the server / deployer might be able to hint the
>>> ??????? Cache
>>> ??????? >>> provider to tell if isolation is at all necessary.
>>> ??????? >>>
>>> ??????? >>> In conclusion, by having Hibernate ORM not messing with
>>> ??????? prefixes
>>> ??????? >>> allows other technologies to implement more efficient
>>> ??????? solutions. Our
>>> ??????? >>> own code also ends up being more efficient by not needing
>>> ??????? to add a
>>> ??????? >>> prefix during each and every access to the cache.
>>> ??????? >>>
>>> ??????? >>> Thanks,
>>> ??????? >>> Sanne
>>> ??????? >>>
>>> ??????? >>> On 17 May 2018 at 06:34, Gail Badner <gbadner at redhat.com
>>> ??????? <mailto:gbadner at redhat.com>> wrote:
>>> ??????? >>>>
>>> ??????? >>>> I see that cache region names are not being prefixed in 
>>> 5.3.
>>> ??????? >>>>
>>> ??????? >>>> EnabledCaching sets the TimestampsRegion region name
>>> ??????? >>>> to TimestampsRegion.class.getName(), and sets the
>>> ??????? QueryResultsRegion
>>> ??????? >>>> region
>>> ??????? >>>> name to QueryResultsRegion.class.getName(). [1]
>>> ??????? >>>>
>>> ??????? >>>> Without a prefix, WildFly is failing intermittently when
>>> ??????? there are 2
>>> ??????? >>>> persistence units with the query cache enabled due to:
>>> ??????? >>>>
>>> ??????? >>>> org.infinispan.commons.CacheConfigurationException:
>>> ??????? ISPN000453: Attempt
>>> ??????? >>>> to
>>> ??????? >>>> define configuration for cache
>>> ??????? org.hibernate.cache.spi.TimestampsRegion
>>> ??????? >>>> which already exists
>>> ??????? >>>>
>>> ??????? >>>> Entity region names are not being prefixed either.
>>> ??????? >>>>
>>> ??????? >>>> Should they be prefixed by Hibernate or by the 
>>> RegionFactory?
>>> ??????? >>>>
>>> ??????? >>>> Regards,
>>> ??????? >>>> Gail
>>> ??????? >>>>
>>> ??????? >>>> [1]
>>> ??????? >>>>
>>> ??????? >>>>
>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92 
>>>
>>> <https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92> 
>>>
>>> ??????? >>>> _______________________________________________
>>> ??????? >>>> hibernate-dev mailing list
>>> ??????? >>>> hibernate-dev at lists.jboss.org
>>> ??????? <mailto:hibernate-dev at lists.jboss.org>
>>> ??????? >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>> ??????? >
>>> ??????? >
>>> ??????? >
>>> ??????? > --
>>> ??????? > Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>>> ??????? > JBoss Performance Team
>>> ??????? >
>>>
>>>
>>>
>>
>

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


From guillaume.smet at gmail.com  Fri May 18 05:22:38 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 18 May 2018 11:22:38 +0200
Subject: [hibernate-dev] Stride
In-Reply-To: <CAFm4XO1YC1e_yLEawfX-+Mro-WEuM=pGB_DC3NPbYpvn0HNmnA@mail.gmail.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
	<CAFm4XO2UzDPv+BnkG_=QT+pLWxVyCK5u1-B8FZPpQfOG7GemLg@mail.gmail.com>
	<4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com>
	<CAFm4XO1YC1e_yLEawfX-+Mro-WEuM=pGB_DC3NPbYpvn0HNmnA@mail.gmail.com>
Message-ID: <CALt0+o9eQ-ZTDzLbiu_63tLaQ-=uOwoeWgR3He4PBXJQi85aHQ@mail.gmail.com>

Hi,

On Fri, May 18, 2018 at 12:16 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Steve pointed out multiple flaws e.g. the native client packaging
> broken on Fedora, to which Atlassian pretty much replied by letting us
> know they won't invest in HipChat as the future is Stride. We can
> choose when to switch but staying doesn't look sensible to me as it
> certainly won't improve; it's also likely that they'll want everyone
> migrated eventually so to shut the existing service down.
>

Well, "multiple flaws" is AFAIK:
1/ the packaging of the native client (well, native is a big word, it's
just a packaged webapp);
2/ the guest access/registration.

For 1/, did someone install the Stride client to be sure it's better?

2/ We don't have any guest access on Stride for now, WDYM by self
registration is better? IMHO, it would be nice to have GitHub/Google
authentication integration. I expect most people won't want to create an
account just to ask a quick question.

And let's not forget all authentication nonsense; especially days that
> I'm working more on the WildFly side of things and need to login to
> multiple instances I really look forward to a better system (hopefully
> it is!?).
>

Will it be better? Shouldn't we coordinate with WildFly to see where they
want to go?

If they don't go with Stride, it won't solve your issue.

The only way to fix this issue is to coordinate with all the projects you
have an interest in and choose the same tool (and check that the tool
allows authentication on several instances at once or has a centralized
instance).

AFAICS from Radim's email, Infinispan has already chosen another tool...


> Question, since you want a decision: are you only suggesting to delay
> or suggesting that you should rather stay on HipChat?
>

I say that we know HipChat sort of works for us as a daily coordination
tool (not talking about discussions with external people). We have no idea
Stride will.

And this recent comment
https://jira.atlassian.com/browse/STRIDE-1973?focusedCommentId=1796169&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1796169
makes me think it's still half baked. It's only one comment but I don't
think there are lots of people already migrated there.

Frankly, the fact that moving to Stride is a one way street and we will
lose our coordination tool if it doesn't work well makes me feel
uncomfortable.


> Personally, I'm fine delaying a bit even though I can live happily
> without Jenkins notifications, but let's hear the others as well.
>

I just want to be able to do my job. That's basically my only requirement.

>From my point of view, it seems like a rushed decision that won't solve the
issues we have, and will potentially create others as we will be migrating
to beta software.

-- 
Guillaume

From steve at hibernate.org  Fri May 18 07:37:30 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 18 May 2018 06:37:30 -0500
Subject: [hibernate-dev] Stride
In-Reply-To: <CALt0+o9eQ-ZTDzLbiu_63tLaQ-=uOwoeWgR3He4PBXJQi85aHQ@mail.gmail.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
	<CAFm4XO2UzDPv+BnkG_=QT+pLWxVyCK5u1-B8FZPpQfOG7GemLg@mail.gmail.com>
	<4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com>
	<CAFm4XO1YC1e_yLEawfX-+Mro-WEuM=pGB_DC3NPbYpvn0HNmnA@mail.gmail.com>
	<CALt0+o9eQ-ZTDzLbiu_63tLaQ-=uOwoeWgR3He4PBXJQi85aHQ@mail.gmail.com>
Message-ID: <CAFdSV9sAJp32Z7oqn6QtPb3ZTSkW3uVFPqom8KCnM4xeoSY8wQ@mail.gmail.com>

You can't "do your job" without yet another way to get notified of CI job
status?  I'm confused - did Jenkins remove all of its other forms of
notification?  ;)  Seriously though,  I've never understood this desire to
have yet another communications "inbox" spammed by automated notifications
- and its even worse in Hip Cat because I can never hide them.  So it is
hard for me to incorporate this into the argument against moving.

Y'all really wanted to move to Hip Chat in the first place even though to
me it always felt (and feels) half-baked itself.  When you have a
communications client that does not even have a working install for the OS
well over half the team using it uses... well, to me that is far bigger
problem than not having a 13th way to see Jenkins notifications ;)  And if
the web client is as good as the native client, I assume you use the web
client instead?

So to me it really comes down to what are the blockers to not making this
move now.  So far I hear:

   1. No Jenkins notifications - see above
   2. Guest access - meh - If having to have an account to join the
   discussion is bad then we should immediately make our forums
   guest-accessible again as well ;)
   3. There may be better options out there - at some point can we just
   pick one and use it?  Is one "inbox" really that much better than another
   "inbox"?  And clearly I am not even tied to Hip Chat - I was one of the
   people wanting to not move there.  Radim, what makes Zulip so amazing?
   4. "Coordination tool"?  Not really sure what this one is about.  Is
   this back to Jenkins notifications?  If you mean a communications tool, of
   course it works.  They are largely the same.  Andrea, Sanne and I have
   played with it, so we in fact do have some idea if it will (spoiler: it
   does)
   5. We should go where WildFly goes (?).

The bottom line is that this is the way Atlassian is going.  Hip Chat is
beyond deprecated - to the point where they won't even fix the smallest of
bugs like the RPM package even though Red Hat employees spent hours doing
all the work for them in terms of investigation and solution.  They
literally just need to add the suggested RPM metadata changes.  But they
wont.  That tells you all you need to know.



On Fri, May 18, 2018 at 4:23 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> On Fri, May 18, 2018 at 12:16 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> Steve pointed out multiple flaws e.g. the native client packaging
>> broken on Fedora, to which Atlassian pretty much replied by letting us
>> know they won't invest in HipChat as the future is Stride. We can
>> choose when to switch but staying doesn't look sensible to me as it
>> certainly won't improve; it's also likely that they'll want everyone
>> migrated eventually so to shut the existing service down.
>>
>
> Well, "multiple flaws" is AFAIK:
> 1/ the packaging of the native client (well, native is a big word, it's
> just a packaged webapp);
> 2/ the guest access/registration.
>
> For 1/, did someone install the Stride client to be sure it's better?
>
> 2/ We don't have any guest access on Stride for now, WDYM by self
> registration is better? IMHO, it would be nice to have GitHub/Google
> authentication integration. I expect most people won't want to create an
> account just to ask a quick question.
>
> And let's not forget all authentication nonsense; especially days that
>> I'm working more on the WildFly side of things and need to login to
>> multiple instances I really look forward to a better system (hopefully
>> it is!?).
>>
>
> Will it be better? Shouldn't we coordinate with WildFly to see where they
> want to go?
>
> If they don't go with Stride, it won't solve your issue.
>
> The only way to fix this issue is to coordinate with all the projects you
> have an interest in and choose the same tool (and check that the tool
> allows authentication on several instances at once or has a centralized
> instance).
>
> AFAICS from Radim's email, Infinispan has already chosen another tool...
>
>
>> Question, since you want a decision: are you only suggesting to delay
>> or suggesting that you should rather stay on HipChat?
>>
>
> I say that we know HipChat sort of works for us as a daily coordination
> tool (not talking about discussions with external people). We have no idea
> Stride will.
>
> And this recent comment
> https://jira.atlassian.com/browse/STRIDE-1973?focusedCommentId=1796169&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1796169
> makes me think it's still half baked. It's only one comment but I don't
> think there are lots of people already migrated there.
>
> Frankly, the fact that moving to Stride is a one way street and we will
> lose our coordination tool if it doesn't work well makes me feel
> uncomfortable.
>
>
>> Personally, I'm fine delaying a bit even though I can live happily
>> without Jenkins notifications, but let's hear the others as well.
>>
>
> I just want to be able to do my job. That's basically my only requirement.
>
> From my point of view, it seems like a rushed decision that won't solve
> the issues we have, and will potentially create others as we will be
> migrating to beta software.
>
> --
> Guillaume
>

From steve at hibernate.org  Fri May 18 08:05:36 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 18 May 2018 07:05:36 -0500
Subject: [hibernate-dev] Simplify SQL function registration when
 bootstrapping via JPA
In-Reply-To: <CA+gWKMAxzCsSdW2_6e980zUe=-C3bd4bFd9JhAjt0tC90Oojeg@mail.gmail.com>
References: <CA+gWKMDfCar8+vjYdxP7C6Fy_vxMvO8h9PRJEDs2XAe2jAobcw@mail.gmail.com>
	<CAFdSV9uQZ6f7HMw1kPBcuNpySV1GF1E2mLu9uZh9Y+mBWtWJog@mail.gmail.com>
	<CA+gWKMDb9F5B-UMM8YH_UZw5PtOryFdN5-D6SLy3dCYJ2MtcCQ@mail.gmail.com>
	<CAFdSV9uO6oeELSh52Bad9ik3VSrCydinPjw6DiefmPK4Krd_5w@mail.gmail.com>
	<CA+gWKMCEAxyDBNKhG0LUnLpsJZ3ZBob3K=z-Sd51m7iTueg8Gg@mail.gmail.com>
	<69110219-7c69-a82b-675d-1a5dd2f3902e@gmail.com>
	<CA+gWKMD4viCDXCgeF2HkqknN21KaKQAdD-7_=8EFXyV0XxW0dw@mail.gmail.com>
	<eb79893f-82da-2cd8-3da5-b2b6ef45bc64@gmail.com>
	<d0261511-ed4c-a6e0-94a6-2cddd4ba0a7d@gmail.com>
	<CA+gWKMBn-Q9nRS17VMSZBuqfpTLrAaFroc8BahPSEHcD-P_sog@mail.gmail.com>
	<CAFdSV9u0BuifLsViw5ss-6e-ssJoQ2QBmc==Hs2UhiRTur5pFg@mail.gmail.com>
	<CA+gWKMAxzCsSdW2_6e980zUe=-C3bd4bFd9JhAjt0tC90Oojeg@mail.gmail.com>
Message-ID: <CAFdSV9tdnYuX-Vjd9Nvwn596pMo8QBycNL29O9wE6zuG0P1eeg@mail.gmail.com>

There could conceivably be multiple MetadataBuilderContributor instances
needing to be integrated.  CDI (and therefore ManagedBeanRegistry) do not
work well in this situation.  MetadataBuilderContributor should be done via
ServiceLoader (via ClassLoaderService)

When I mentioned ManagedBeanRegistry, I was talking specifically about just
contributing functions - but MetadataBuilderContributor is more
generalized, which is fine.. it just won't fit into the CDI paradigm




On Thu, May 17, 2018 at 1:35 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I named it MetadataBuilderContributor because you can do more than just
> registering SqlFunctions. While implementing it, I realized that, this way,
> it's going to be very flexible to customize the Hibernate-native Metadata
> while doing the JPA bootstrap.
>
> Related to ManagedBeanRegitry, I'm trying to convert to using it, but
> stumbled on this issue.
>
> If I try to get a Bean like this:
>
> managedBeanRegistry.getBean( MetadataBuilderContributor.class );
>
> And there is no BeanContainer set via
> "hibernate.resource.beans.container", then the FallbackContainedBean is
> used, which tries to instantiate the provided interface:
>
> beanType.newInstance();
>
> But since I provide an interface, the call will fail.
>
> The only workaround I found is this:
>
> ManagedBeanRegistry managedBeanRegistry = standardServiceRegistry
> .getService( ManagedBeanRegistry.class );
>
> BeanContainer beanContainer = managedBeanRegistry.getBeanContainer();
>
> ManagedBean<MetadataBuilderContributor>
> metadataBuilderContributorManagedBean = null;
> if ( beanContainer != null ) {
> metadataBuilderContributorManagedBean = managedBeanRegistry
> .getBean( MetadataBuilderContributor.class );
> }
>
> MetadataBuilderContributor metadataBuilderContributor =
> metadataBuilderContributorManagedBean
> .getBeanInstance();
>
> Am I using it the wrong way, or do we need to check the BeanContainer
> first to make sure it's not null before getting a Bean from the
> ManagedBeanRegistry?
>
> Vlad
>
>
> On Thu, May 17, 2018 at 9:07 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Personally I think both a contributor and CDI integration
>> (ManagedBeanRegitry) make sense here.  Btw, the name for the contributor
>> should not be SqlFunctionContributor - it should reflect the ultimate goal
>> here which is SqmFunctionTemplate; I can see SqmFunctionContributor or just
>> FunctionContributor.  This is an example of what I meant about waiting for
>> 6...
>>
>> On Thu, May 17, 2018 at 12:50 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Sure thing. I'll try to adapt it to using the Bean registry.
>>>
>>> Vlad
>>>
>>> On Thu, 17 May 2018, 20:07 Chris Cranford, <crancran at gmail.com> wrote:
>>>
>>> > I personally agree with Christian, I don't see the use of the
>>> > ManagedBeanRegistry being a problem.  The new interface certainly opens
>>> > the door for a variety of builder settings to be contributed easily and
>>> > using the registry allows for a versatile way to provide that bean,
>>> > whether it be through some CDI/Spring environment or the fallback
>>> > solution where we instantiate it ourselves.  I believe the code as you
>>> > have it can easily be adapted to use the registry by replacing the
>>> > "newInstance()" call with a call into getting the bean from the
>>> > registry.  The registry itself internally should handle getting the
>>> bean
>>> > from the container or returning you a new instance we instantiate
>>> > ourselves.
>>> >
>>> > On 05/17/2018 12:25 PM, Christian Beikov wrote:
>>> > > The functions could be contributed via a CDI/Spring bean which might
>>> not
>>> > > be such a bad idea I think. In a test environment there could be a
>>> > > different contributor active than in production. Of course, this
>>> could
>>> > > also be handled by passing in different configuration property
>>> values,
>>> > > but that's why I was saying I'm not sure about it. Maybe someone else
>>> > > has an idea if using ManagedBeanRegistry might make sense?
>>> > >
>>> > >
>>> > > Mit freundlichen Gr??en,
>>> > >
>>> ------------------------------------------------------------------------
>>> > > *Christian Beikov*
>>> > > Am 17.05.2018 um 16:49 schrieb Vlad Mihalcea:
>>> > >> Hi,
>>> > >>
>>> > >> Looking at the SessionFactoryImpl class, the only way to provide an
>>> > >> SqlFunction is either via the Dialect or via the
>>> SessionFactoryOptions:
>>> > >> this.sqlFunctionRegistry  =new SQLFunctionRegistry(
>>> > jdbcServices.getJdbcEnvironment().getDialect(),
>>> > options.getCustomSqlFunctionMap() );
>>> > >> I'm not sure if the ManagedBeanRegistry would have helped in this
>>> case
>>> > >> without requiring more code changes.
>>> > >>
>>> > >> Vlad
>>> > >>
>>> > >> On Thu, May 17, 2018 at 5:22 PM, Christian Beikov
>>> > >> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>> wrote:
>>> > >>
>>> > >>     It looks ok to me although I'm not sure if it wouldn't be more
>>> > >>     appropriate to instantiate the contributor via
>>> ManagedBeanRegistry.
>>> > >>
>>> > >>
>>> > >>     Mit freundlichen Gr??en,
>>> > >>
>>> >
>>> ------------------------------------------------------------------------
>>> > >>     *Christian Beikov*
>>> > >>     Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea:
>>> > >>     > In the end, I thought of a more generic approach to for JPA
>>> > >>     bootstrapping
>>> > >>     > which, not only allows us to register SqlFunctions, but we can
>>> > >>     apply other
>>> > >>     > changes on the MetadataBuilder object used during bootstrap.
>>> > >>     >
>>> > >>     > This is the Pull Request:
>>> > >>     >
>>> > >>     > https://github.com/hibernate/hibernate-orm/pull/2288
>>> > >>     <https://github.com/hibernate/hibernate-orm/pull/2288>
>>> > >>     >
>>> > >>     > Let me know what you think.
>>> > >>     >
>>> > >>     > Vlad
>>> > >>     >
>>> > >>     > On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole
>>> > >>     <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>>> > >>     >
>>> > >>     >> Its not so much hindering 6.0 that I am concerned with.  The
>>> > >>     problem is
>>> > >>     >> updatability for the user.  The more things they use that
>>> > >>     change = the more
>>> > >>     >> work to upgrade.
>>> > >>     >>
>>> > >>     >> On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea
>>> > >>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
>>> > >>     >> wrote:
>>> > >>     >>
>>> > >>     >>> I suppose this will be refactored considerably in 6.x.
>>> > >>     >>>
>>> > >>     >>> However, it's just a small change and I don't think it will
>>> > >>     hinder any
>>> > >>     >>> 6.x changes.
>>> > >>     >>>
>>> > >>     >>> I'm thinking of defining an SqlFunctionContributor interface
>>> > >>     >>> (@FunctionalInterface)
>>> > >>     >>> which can be provided via the properties Map that's supplied
>>> > >>     when using
>>> > >>     >>> the Persistence#createEntityManagerFactory method.
>>> > >>     >>>
>>> > >>     >>> In EntityManagerFactoryBuilder, I can just inspect that and
>>> > >>     pass it
>>> > >>     >>> further to MetamodelBuilder.
>>> > >>     >>>
>>> > >>     >>> So, it does not take any effort to implement it and users
>>> can
>>> > >>     benefit
>>> > >>     >>> from it. I recently answered a question on the forum on this
>>> > >>     topic:
>>> > >>     >>>
>>> > >>     >>> https://discourse.hibernate.org/t/i-cant-use-group-concat-
>>> > >>     <https://discourse.hibernate.org/t/i-cant-use-group-concat->
>>> > >>     >>> in-queries/752/14
>>> > >>     >>>
>>> > >>     >>> And, realized that I was wrong about suggesting doing it
>>> via the
>>> > >>     >>> Integrator mechanism (since the Metamodel is already frozen
>>> by
>>> > >>     the time we
>>> > >>     >>> execute the Integrator).
>>> > >>     >>>
>>> > >>     >>> Vlad
>>> > >>     >>>
>>> > >>     >>> On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole
>>> > >>     <steve at hibernate.org <mailto:steve at hibernate.org>>
>>> > >>     >>> wrote:
>>> > >>     >>>
>>> > >>     >>>> This should maybe wait for 6.0.  We are ditching
>>> SQLFunction
>>> > >>     in favor of
>>> > >>     >>>> a more AST-friendly contract.
>>> > >>     >>>>
>>> > >>     >>>> Beyond that, go for it.
>>> > >>     >>>>
>>> > >>     >>>>
>>> > >>     >>>> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea
>>> > >>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
>>> > >>     >>>> wrote:
>>> > >>     >>>>
>>> > >>     >>>>> Hi,
>>> > >>     >>>>>
>>> > >>     >>>>> I realized that only the native Hibernate bootstrapping
>>> > >>     mechanism allows
>>> > >>     >>>>> for passing custom SQL functions.
>>> > >>     >>>>>
>>> > >>     >>>>> For JPA, we can extend the Dialect to register, but that's
>>> > >>     not always
>>> > >>     >>>>> desirable as it requires a code change
>>> > >>     >>>>> every time the user switches to a new Dialect version.
>>> > >>     >>>>>
>>> > >>     >>>>> For this reason, I created this Jira issue:
>>> > >>     >>>>>
>>> > >>     >>>>> https://hibernate.atlassian.net/browse/HHH-12589
>>> > >>     <https://hibernate.atlassian.net/browse/HHH-12589>
>>> > >>     >>>>>
>>> > >>     >>>>> Let me know if anyone has anything against implementing
>>> this
>>> > >>     feature.
>>> > >>     >>>>>
>>> > >>     >>>>> Vlad
>>> > >>     >>>>> _______________________________________________
>>> > >>     >>>>> hibernate-dev mailing list
>>> > >>     >>>>> hibernate-dev at lists.jboss.org
>>> > >>     <mailto:hibernate-dev at lists.jboss.org>
>>> > >>     >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>> > >>     >>>>>
>>> > >>     > _______________________________________________
>>> > >>     > hibernate-dev mailing list
>>> > >>     > hibernate-dev at lists.jboss.org <mailto:
>>> > hibernate-dev at lists.jboss.org>
>>> > >>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>> > >>
>>> > >>     _______________________________________________
>>> > >>     hibernate-dev mailing list
>>> > >>     hibernate-dev at lists.jboss.org <mailto:
>>> hibernate-dev at lists.jboss.org
>>> > >
>>> > >>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>> > >>
>>> > >>
>>> > > _______________________________________________
>>> > > hibernate-dev mailing list
>>> > > hibernate-dev at lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> > _______________________________________________
>>> > 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  Fri May 18 09:56:21 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 18 May 2018 09:56:21 -0400
Subject: [hibernate-dev] Stride
In-Reply-To: <dda4b285-f0ae-e961-26c1-05e3b29d56ee@redhat.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
	<CAFm4XO2UzDPv+BnkG_=QT+pLWxVyCK5u1-B8FZPpQfOG7GemLg@mail.gmail.com>
	<4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com>
	<CAFm4XO1YC1e_yLEawfX-+Mro-WEuM=pGB_DC3NPbYpvn0HNmnA@mail.gmail.com>
	<dda4b285-f0ae-e961-26c1-05e3b29d56ee@redhat.com>
Message-ID: <55c700b0-5621-4703-0469-ca10658f885b@redhat.com>

Does Zulip have a Fedora (native) client that can be installed by Fedora 
dnf tool?

I've been using Zulip in a browser [1] (as I do with hipchat) and it 
seems at least as good as hipchat.

Has anyone looked at the Zulip multiple organization (team) support [2]?

Scott

[1] https://infinispan.zulipchat.com/
[2] https://zulip.readthedocs.io/en/1.7.1/prod-multiple-organizations.html

On 05/18/2018 02:57 AM, Radim Vansa wrote:
> Just out of curiosity, when choosing a replacement for HipChat, have you
> considered Zulip?
> 
> Infinispan uses that for about a month now and besides being too
> colourful (similar to HipChat) there's been positive feedback,
> especially due to the threading feature.
> 
> Radim [trying to lure everyone to the same client]
> 
> On 05/18/2018 12:16 AM, Sanne Grinovero wrote:
>> On 17 May 2018 at 20:32, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>>> By the way, you say it?s clear we don?t want to stay on HipChat.
>>>
>>> When did we decide that? I don?t remember a discussion about it.
>> I didn't say it was decided, but I think we're working on that since
>> Steve asked about it today. To which I agree *because* it seems clear
>> to me that we don't want to stay on it - a notion I inferred from
>> multiple previous discussions.
>>
>> Steve pointed out multiple flaws e.g. the native client packaging
>> broken on Fedora, to which Atlassian pretty much replied by letting us
>> know they won't invest in HipChat as the future is Stride. We can
>> choose when to switch but staying doesn't look sensible to me as it
>> certainly won't improve; it's also likely that they'll want everyone
>> migrated eventually so to shut the existing service down.
>>
>> I for one gave up as well installing the native client and have been
>> using the web client since setting up my new workstation, as I was
>> expecting Stride to arrive soon.
>>
>> The other day some people tried to join and gave up because of login
>> complexity - that's IMO a very bad sign: not welcoming community
>> people means it's failing its primary requirements.
>>
>> And let's not forget all authentication nonsense; especially days that
>> I'm working more on the WildFly side of things and need to login to
>> multiple instances I really look forward to a better system (hopefully
>> it is!?).
>>
>> Question, since you want a decision: are you only suggesting to delay
>> or suggesting that you should rather stay on HipChat?
>>
>> Personally, I'm fine delaying a bit even though I can live happily
>> without Jenkins notifications, but let's hear the others as well.
>>
>> Thanks,
>> Sanne
>>
>>
>>> For sure, we probably won?t have a choice because there?s a good chance Atlassian will close the service but what are the problems that make a migration so urgent?
>>>
>>>> Le 17 mai 2018 ? 20:16, Sanne Grinovero <sanne at hibernate.org> a ?crit :
>>>>
>>>> lol, I was writing about the same to the team list.
>>>>
>>>> +1 to have people register, it's better for them anyway. I checked
>>>> it's easier to self-register.
>>>>
>>>> +1 to migrate quickly. It's clear we don't want to stay on HipChat, if
>>>> this doesn't work out we'll see.
>>>>
>>>> Refer to my parallel email for Fedora instructions.
>>>>
>>>> Thanks,
>>>> Sanne
>>>>
>>>>
>>>>> On 17 May 2018 at 19:03, Steve Ebersole <steve at hibernate.org> wrote:
>>>>> I got an email from Atlassian this morning about the migration from HipChat
>>>>> to Stride.  Basically they have not gotten Stride feature-complete in terms
>>>>> of HipChat which is the trigger for the mass migration.  However, they are
>>>>> reaching out to all waiting teams to see if any want to migrate anyway.
>>>>> The list of missing features they sent me are:
>>>>>
>>>>>
>>>>>     1. Guest access
>>>>>     2. Some admin controls and compliance settings
>>>>>     3. Integrations with Atlassian server products (the Jira Server app is
>>>>>     currently in beta and coming soon) and some other popular integrations. See
>>>>>     all available Stride integrations
>>>>>     <http://click.mailer.atlassian.com/?qs=6712850cb7a4f2d4a207f46e5f190a454855738b8db6340974f28f3c2e1e6aa7c674a6314ad5df11014e5e2ee39bd3d4326606d2826b241a>
>>>>>     .
>>>>>     4. User management via API
>>>>>     5. Dark mode
>>>>>
>>>>> I am not really sure exactly what is missing WRT (2).  (3) is nice-to-have,
>>>>> but not blocker IMO assuming it gets added at some point.
>>>>>
>>>>> I think (1) is the only one that is concerning.  Though TBH for myself
>>>>> personally, I do not think registering is a big deal.
>>>>>
>>>>> Unless I hear otherwise, I plan on asking them to proceed with our
>>>>> migration to Stride.
>>>>> _______________________________________________
>>>>> 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 rvansa at redhat.com  Fri May 18 12:45:13 2018
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 18 May 2018 18:45:13 +0200
Subject: [hibernate-dev] Stride
In-Reply-To: <55c700b0-5621-4703-0469-ca10658f885b@redhat.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
	<CAFm4XO2UzDPv+BnkG_=QT+pLWxVyCK5u1-B8FZPpQfOG7GemLg@mail.gmail.com>
	<4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com>
	<CAFm4XO1YC1e_yLEawfX-+Mro-WEuM=pGB_DC3NPbYpvn0HNmnA@mail.gmail.com>
	<dda4b285-f0ae-e961-26c1-05e3b29d56ee@redhat.com>
	<55c700b0-5621-4703-0469-ca10658f885b@redhat.com>
Message-ID: <8867fdd8-b0a5-5b17-7c6b-9fadfdf6d833@redhat.com>

On 05/18/2018 03:56 PM, Scott Marlow wrote:
> Does Zulip have a Fedora (native) client that can be installed by 
> Fedora dnf tool?

No, they don't have RPM, I use the provided AppImage. Yes, nuisance 
(updates are not automatic). Issue [1] from 2015 looks stale.

htop tells me that it's consuming 114 MB of RES memory and 12% CPU (!) 
when idle, though - I was hoping for better.

[1] https://github.com/zulip/zulip/issues/41

> I've been using Zulip in a browser [1] (as I do with hipchat) and it 
> seems at least as good as hipchat.
>
> Has anyone looked at the Zulip multiple organization (team) support [2]?

Client supporting multiple organizations was among the key requirements; 
noone likes the situation around isolated WF & Hibernate HipChats.

R.

>
> Scott
>
> [1] https://infinispan.zulipchat.com/
> [2] 
> https://zulip.readthedocs.io/en/1.7.1/prod-multiple-organizations.html
>
> On 05/18/2018 02:57 AM, Radim Vansa wrote:
>> Just out of curiosity, when choosing a replacement for HipChat, have you
>> considered Zulip?
>>
>> Infinispan uses that for about a month now and besides being too
>> colourful (similar to HipChat) there's been positive feedback,
>> especially due to the threading feature.
>>
>> Radim [trying to lure everyone to the same client]
>>
>> On 05/18/2018 12:16 AM, Sanne Grinovero wrote:
>>> On 17 May 2018 at 20:32, Guillaume Smet <guillaume.smet at gmail.com> 
>>> wrote:
>>>> By the way, you say it?s clear we don?t want to stay on HipChat.
>>>>
>>>> When did we decide that? I don?t remember a discussion about it.
>>> I didn't say it was decided, but I think we're working on that since
>>> Steve asked about it today. To which I agree *because* it seems clear
>>> to me that we don't want to stay on it - a notion I inferred from
>>> multiple previous discussions.
>>>
>>> Steve pointed out multiple flaws e.g. the native client packaging
>>> broken on Fedora, to which Atlassian pretty much replied by letting us
>>> know they won't invest in HipChat as the future is Stride. We can
>>> choose when to switch but staying doesn't look sensible to me as it
>>> certainly won't improve; it's also likely that they'll want everyone
>>> migrated eventually so to shut the existing service down.
>>>
>>> I for one gave up as well installing the native client and have been
>>> using the web client since setting up my new workstation, as I was
>>> expecting Stride to arrive soon.
>>>
>>> The other day some people tried to join and gave up because of login
>>> complexity - that's IMO a very bad sign: not welcoming community
>>> people means it's failing its primary requirements.
>>>
>>> And let's not forget all authentication nonsense; especially days that
>>> I'm working more on the WildFly side of things and need to login to
>>> multiple instances I really look forward to a better system (hopefully
>>> it is!?).
>>>
>>> Question, since you want a decision: are you only suggesting to delay
>>> or suggesting that you should rather stay on HipChat?
>>>
>>> Personally, I'm fine delaying a bit even though I can live happily
>>> without Jenkins notifications, but let's hear the others as well.
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>>> For sure, we probably won?t have a choice because there?s a good 
>>>> chance Atlassian will close the service but what are the problems 
>>>> that make a migration so urgent?
>>>>
>>>>> Le 17 mai 2018 ? 20:16, Sanne Grinovero <sanne at hibernate.org> a 
>>>>> ?crit :
>>>>>
>>>>> lol, I was writing about the same to the team list.
>>>>>
>>>>> +1 to have people register, it's better for them anyway. I checked
>>>>> it's easier to self-register.
>>>>>
>>>>> +1 to migrate quickly. It's clear we don't want to stay on 
>>>>> HipChat, if
>>>>> this doesn't work out we'll see.
>>>>>
>>>>> Refer to my parallel email for Fedora instructions.
>>>>>
>>>>> Thanks,
>>>>> Sanne
>>>>>
>>>>>
>>>>>> On 17 May 2018 at 19:03, Steve Ebersole <steve at hibernate.org> wrote:
>>>>>> I got an email from Atlassian this morning about the migration 
>>>>>> from HipChat
>>>>>> to Stride.? Basically they have not gotten Stride 
>>>>>> feature-complete in terms
>>>>>> of HipChat which is the trigger for the mass migration. However, 
>>>>>> they are
>>>>>> reaching out to all waiting teams to see if any want to migrate 
>>>>>> anyway.
>>>>>> The list of missing features they sent me are:
>>>>>>
>>>>>>
>>>>>> ??? 1. Guest access
>>>>>> ??? 2. Some admin controls and compliance settings
>>>>>> ??? 3. Integrations with Atlassian server products (the Jira 
>>>>>> Server app is
>>>>>> ??? currently in beta and coming soon) and some other popular 
>>>>>> integrations. See
>>>>>> ??? all available Stride integrations
>>>>>> <http://click.mailer.atlassian.com/?qs=6712850cb7a4f2d4a207f46e5f190a454855738b8db6340974f28f3c2e1e6aa7c674a6314ad5df11014e5e2ee39bd3d4326606d2826b241a>
>>>>>> ??? .
>>>>>> ??? 4. User management via API
>>>>>> ??? 5. Dark mode
>>>>>>
>>>>>> I am not really sure exactly what is missing WRT (2). (3) is 
>>>>>> nice-to-have,
>>>>>> but not blocker IMO assuming it gets added at some point.
>>>>>>
>>>>>> I think (1) is the only one that is concerning.? Though TBH for 
>>>>>> myself
>>>>>> personally, I do not think registering is a big deal.
>>>>>>
>>>>>> Unless I hear otherwise, I plan on asking them to proceed with our
>>>>>> migration to Stride.
>>>>>> _______________________________________________
>>>>>> 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
>>
>>

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


From gbadner at redhat.com  Fri May 18 15:38:03 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 18 May 2018 12:38:03 -0700
Subject: [hibernate-dev] Is bytecode enhancement enabled by default in 5.3?
Message-ID: <CAFDzhiRmiKcbWn=HVuMG+CQSMJ_kR8GRH76Tzueqq3c2TTj_vg@mail.gmail.com>

I don't think it is, just need to confirm.

Thanks,
Gail

From lbarreiro at redhat.com  Fri May 18 20:28:11 2018
From: lbarreiro at redhat.com (Luis Barreiro)
Date: Sat, 19 May 2018 01:28:11 +0100
Subject: [hibernate-dev] Is bytecode enhancement enabled by default in
 5.3?
In-Reply-To: <CAFDzhiRmiKcbWn=HVuMG+CQSMJ_kR8GRH76Tzueqq3c2TTj_vg@mail.gmail.com>
References: <CAFDzhiRmiKcbWn=HVuMG+CQSMJ_kR8GRH76Tzueqq3c2TTj_vg@mail.gmail.com>
Message-ID: <850f8263-c48e-0a4c-c634-d6cd8da59f29@redhat.com>

I don't get your question.

Hibernate does not enhance the entities by itself, you have to 
explicitly use one of the build tool plugins (maven, gradle, ant) to 
perform that step.

Even then, the plugins have all the features disabled by default.

The support for enhanced entities in hibernate is not something you can 
enable or disable.

The only thing configurable is the bytecode provider, and that is 
something that has indeed changed for 5.3. AFAICT the generated bytecode 
should be identical.

Luis Barreiro

Middleware Performance Team

<https://red.ht/sig>

On 05/18/2018 08:38 PM, Gail Badner wrote:
> I don't think it is, just need to confirm.
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Sat May 19 06:28:24 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 19 May 2018 11:28:24 +0100
Subject: [hibernate-dev] Is bytecode enhancement enabled by default in
	5.3?
In-Reply-To: <850f8263-c48e-0a4c-c634-d6cd8da59f29@redhat.com>
References: <CAFDzhiRmiKcbWn=HVuMG+CQSMJ_kR8GRH76Tzueqq3c2TTj_vg@mail.gmail.com>
	<850f8263-c48e-0a4c-c634-d6cd8da59f29@redhat.com>
Message-ID: <CAFm4XO2iYqR_32UeJW=3_hoa4wgHF2zRCXs0fG2w+Uhcadjdng@mail.gmail.com>

Hi Gail,

perhaps your question is related to WildFly? As far as I know, WildFly
does enhance entities automatically during deployment.

But as Luis suggested, Hibernate doesn't control this process so I'm
not sure if that's still the case in any development branch of
WildFly; probably a question for Scott.

If not WildFly, other platforms might do the same but it's up to them
to decide on the defaults.

Thanks,
Sanne


On 19 May 2018 at 01:28, Luis Barreiro <lbarreiro at redhat.com> wrote:
> I don't get your question.
>
> Hibernate does not enhance the entities by itself, you have to
> explicitly use one of the build tool plugins (maven, gradle, ant) to
> perform that step.
>
> Even then, the plugins have all the features disabled by default.
>
> The support for enhanced entities in hibernate is not something you can
> enable or disable.
>
> The only thing configurable is the bytecode provider, and that is
> something that has indeed changed for 5.3. AFAICT the generated bytecode
> should be identical.
>
> Luis Barreiro
>
> Middleware Performance Team
>
> <https://red.ht/sig>
>
> On 05/18/2018 08:38 PM, Gail Badner wrote:
>> I don't think it is, just need to confirm.
>>
>> Thanks,
>> Gail
>> _______________________________________________
>> 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  Sun May 20 07:06:52 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Sun, 20 May 2018 07:06:52 -0400
Subject: [hibernate-dev] Is bytecode enhancement enabled by default in
	5.3?
In-Reply-To: <CAFm4XO2iYqR_32UeJW=3_hoa4wgHF2zRCXs0fG2w+Uhcadjdng@mail.gmail.com>
References: <CAFDzhiRmiKcbWn=HVuMG+CQSMJ_kR8GRH76Tzueqq3c2TTj_vg@mail.gmail.com>
	<850f8263-c48e-0a4c-c634-d6cd8da59f29@redhat.com>
	<CAFm4XO2iYqR_32UeJW=3_hoa4wgHF2zRCXs0fG2w+Uhcadjdng@mail.gmail.com>
Message-ID: <CAJtdNN4YqSc47v4MjTV8tfRKEyqs6QtOJC9Vo9aeN7G-b8sPwA@mail.gmail.com>

There is a tradeoff in WF deployment, between Hibernate bytecode (runtime)
enhancing class transformers, being registered before CDI deployment, reads
the entity classes.

There is also the tradeoff between Hibernate bytecode (runtime) enhancing
class transformers being registered too late because the persistent unit
uses a datasourcedefinition.

I asked Gail's question for 5.1.x and the answer was no.

Now, for 5.3, I don't understand the answers yet.

Anyway, wanted to mention the above, to share more info with all, as to why
we are asking.

Regards,
Scott

On Sat, May 19, 2018, 6:30 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Gail,
>
> perhaps your question is related to WildFly? As far as I know, WildFly
> does enhance entities automatically during deployment.
>
> But as Luis suggested, Hibernate doesn't control this process so I'm
> not sure if that's still the case in any development branch of
> WildFly; probably a question for Scott.
>
> If not WildFly, other platforms might do the same but it's up to them
> to decide on the defaults.
>
> Thanks,
> Sanne
>
>
> On 19 May 2018 at 01:28, Luis Barreiro <lbarreiro at redhat.com> wrote:
> > I don't get your question.
> >
> > Hibernate does not enhance the entities by itself, you have to
> > explicitly use one of the build tool plugins (maven, gradle, ant) to
> > perform that step.
> >
> > Even then, the plugins have all the features disabled by default.
> >
> > The support for enhanced entities in hibernate is not something you can
> > enable or disable.
> >
> > The only thing configurable is the bytecode provider, and that is
> > something that has indeed changed for 5.3. AFAICT the generated bytecode
> > should be identical.
> >
> > Luis Barreiro
> >
> > Middleware Performance Team
> >
> > <https://red.ht/sig>
> >
> > On 05/18/2018 08:38 PM, Gail Badner wrote:
> >> I don't think it is, just need to confirm.
> >>
> >> Thanks,
> >> Gail
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Sun May 20 08:48:19 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 20 May 2018 13:48:19 +0100
Subject: [hibernate-dev] Is bytecode enhancement enabled by default in
	5.3?
In-Reply-To: <CAJtdNN4YqSc47v4MjTV8tfRKEyqs6QtOJC9Vo9aeN7G-b8sPwA@mail.gmail.com>
References: <CAFDzhiRmiKcbWn=HVuMG+CQSMJ_kR8GRH76Tzueqq3c2TTj_vg@mail.gmail.com>
	<850f8263-c48e-0a4c-c634-d6cd8da59f29@redhat.com>
	<CAFm4XO2iYqR_32UeJW=3_hoa4wgHF2zRCXs0fG2w+Uhcadjdng@mail.gmail.com>
	<CAJtdNN4YqSc47v4MjTV8tfRKEyqs6QtOJC9Vo9aeN7G-b8sPwA@mail.gmail.com>
Message-ID: <CAFm4XO1uLygeGPjKqC+LVVLoLO+JquL3rKhH0RSy=eohFrxcNg@mail.gmail.com>

Hi Scott,

could you explain what you mean by "tradeoff" in this context?

Thanks!


On 20 May 2018 at 12:06, Scott Marlow <smarlow at redhat.com> wrote:
> There is a tradeoff in WF deployment, between Hibernate bytecode (runtime)
> enhancing class transformers, being registered before CDI deployment, reads
> the entity classes.
>
> There is also the tradeoff between Hibernate bytecode (runtime) enhancing
> class transformers being registered too late because the persistent unit
> uses a datasourcedefinition.
>
> I asked Gail's question for 5.1.x and the answer was no.
>
> Now, for 5.3, I don't understand the answers yet.
>
> Anyway, wanted to mention the above, to share more info with all, as to why
> we are asking.
>
> Regards,
> Scott
>
> On Sat, May 19, 2018, 6:30 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi Gail,
>>
>> perhaps your question is related to WildFly? As far as I know, WildFly
>> does enhance entities automatically during deployment.
>>
>> But as Luis suggested, Hibernate doesn't control this process so I'm
>> not sure if that's still the case in any development branch of
>> WildFly; probably a question for Scott.
>>
>> If not WildFly, other platforms might do the same but it's up to them
>> to decide on the defaults.
>>
>> Thanks,
>> Sanne
>>
>>
>> On 19 May 2018 at 01:28, Luis Barreiro <lbarreiro at redhat.com> wrote:
>> > I don't get your question.
>> >
>> > Hibernate does not enhance the entities by itself, you have to
>> > explicitly use one of the build tool plugins (maven, gradle, ant) to
>> > perform that step.
>> >
>> > Even then, the plugins have all the features disabled by default.
>> >
>> > The support for enhanced entities in hibernate is not something you can
>> > enable or disable.
>> >
>> > The only thing configurable is the bytecode provider, and that is
>> > something that has indeed changed for 5.3. AFAICT the generated bytecode
>> > should be identical.
>> >
>> > Luis Barreiro
>> >
>> > Middleware Performance Team
>> >
>> > <https://red.ht/sig>
>> >
>> > On 05/18/2018 08:38 PM, Gail Badner wrote:
>> >> I don't think it is, just need to confirm.
>> >>
>> >> Thanks,
>> >> Gail
>> >> _______________________________________________
>> >> 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 guillaume.smet at gmail.com  Mon May 21 08:01:14 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 21 May 2018 14:01:14 +0200
Subject: [hibernate-dev] Stride
In-Reply-To: <CAFdSV9sAJp32Z7oqn6QtPb3ZTSkW3uVFPqom8KCnM4xeoSY8wQ@mail.gmail.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
	<CAFm4XO2UzDPv+BnkG_=QT+pLWxVyCK5u1-B8FZPpQfOG7GemLg@mail.gmail.com>
	<4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com>
	<CAFm4XO1YC1e_yLEawfX-+Mro-WEuM=pGB_DC3NPbYpvn0HNmnA@mail.gmail.com>
	<CALt0+o9eQ-ZTDzLbiu_63tLaQ-=uOwoeWgR3He4PBXJQi85aHQ@mail.gmail.com>
	<CAFdSV9sAJp32Z7oqn6QtPb3ZTSkW3uVFPqom8KCnM4xeoSY8wQ@mail.gmail.com>
Message-ID: <CALt0+o_yq8=K1aOFzkX22H41A+oh4rjJ3OAiVu+E9D=gCZhBvA@mail.gmail.com>

Hi,

On Fri, May 18, 2018 at 1:37 PM, Steve Ebersole <steve at hibernate.org> wrote:

> You can't "do your job" without yet another way to get notified of CI job
> status?  I'm confused - did Jenkins remove all of its other forms of
> notification?  ;)  Seriously though,  I've never understood this desire to
> have yet another communications "inbox" spammed by automated notifications
> - and its even worse in Hip Cat because I can never hide them.  So it is
> hard for me to incorporate this into the argument against moving.
>

Typically, for the websites builds, I like to have the notifications on
HipChat. Not vital but it's something I appreciate.


> Y'all really wanted to move to Hip Chat in the first place even though to
> me it always felt (and feels) half-baked itself.
>

I wasn't part of the team at that point.


> And if the web client is as good as the native client, I assume you use
> the web client instead?
>

Yes. I have a pinned tab for it. Desktop notifications from the browser are
well integrated now.


> So to me it really comes down to what are the blockers to not making this
> move now.  So far I hear:
>
>    1. No Jenkins notifications - see above
>    2. Guest access - meh - If having to have an account to join the
>    discussion is bad then we should immediately make our forums
>    guest-accessible again as well ;)
>
> As mentioned in my email, I don't mind not having guest access if we have
some sort of external auth integration (Github/Twitter/Google). This way,
it avoids creating yet another account. That's what we have on our new
forums.

Maybe Stride has it, I don't know, but I would like our next chat system to
have that.

I took a look at several accounts we have on our forums and most of them
are from GitHub or Google (I took seven randomly and 1 had an account
specific to our forums - no better statistics sorry).

>
>    1. There may be better options out there - at some point can we just
>    pick one and use it?  Is one "inbox" really that much better than another
>    "inbox"?  And clearly I am not even tied to Hip Chat - I was one of the
>    people wanting to not move there.  Radim, what makes Zulip so amazing?
>    2. "Coordination tool"?  Not really sure what this one is about.  Is
>    this back to Jenkins notifications?  If you mean a communications tool, of
>    course it works.  They are largely the same.  Andrea, Sanne and I have
>    played with it, so we in fact do have some idea if it will (spoiler: it
>    does)
>    3. We should go where WildFly goes (?).
>
> My main point is that we have no idea if Stride is stable at the moment.
They definitely don't want to massively migrate the HipChat users and I
found at least one comment of a person who has migrated there and is not
happy at all (not saying it makes all the migrated users unhappy, just
saying that it might be a bad move if we do it now).

So again, what problem are we trying to solve by migrating to Stride while
it's still a work in progress? Because you reversed the question but it is
the correct question.

- If it is the client issue, is the Stride client better integrated? And is
it enough to trigger the migration?
- If it's the access difficulty, does Stride allow external
authentications? Because that's what external users want.
- If it's the "it's a pain to be logged in to multiple instances", are we
all moving to Stride and will it solve the issue - meaning is it easier to
be connected to multiple instances?
- Other issues I'm not aware of?

When you want to migrate to something new, you ponder the risks with the
benefits. For now, noone has stated any clear benefit, apart from "it's
new" and "HipChat has issues but we don't know if they will be solved by
Stride".

Note that my position is not "we should stay on HipChat forever" because we
can't as they will close the service at some point. My position is:
- I'm not sure the risk of moving to a half-baked system is worth it if
there are no clear benefits (I would wait a bit)
- is Stride gonna solve our issues or do we need to move to another system?
(because if it's the case, let's avoid the Stride square).

-- 
Guillaume

From yoann at hibernate.org  Tue May 22 04:26:25 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 22 May 2018 10:26:25 +0200
Subject: [hibernate-dev] Stride
In-Reply-To: <CALt0+o_yq8=K1aOFzkX22H41A+oh4rjJ3OAiVu+E9D=gCZhBvA@mail.gmail.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
	<CAFm4XO2UzDPv+BnkG_=QT+pLWxVyCK5u1-B8FZPpQfOG7GemLg@mail.gmail.com>
	<4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com>
	<CAFm4XO1YC1e_yLEawfX-+Mro-WEuM=pGB_DC3NPbYpvn0HNmnA@mail.gmail.com>
	<CALt0+o9eQ-ZTDzLbiu_63tLaQ-=uOwoeWgR3He4PBXJQi85aHQ@mail.gmail.com>
	<CAFdSV9sAJp32Z7oqn6QtPb3ZTSkW3uVFPqom8KCnM4xeoSY8wQ@mail.gmail.com>
	<CALt0+o_yq8=K1aOFzkX22H41A+oh4rjJ3OAiVu+E9D=gCZhBvA@mail.gmail.com>
Message-ID: <CAEqagpr6fveA-8Q7WHig3xJuB7FEp4P_AvP1vMjdSvdA9j7Zsg@mail.gmail.com>

I think the problem here is about how we're choosing to migrate to another
tool. We are basically moving to Stride because Atlassian is being
uncooperative with updating HipChat, even though Stride is still not fully
functional.
Atlassian made HipChat, and we're not happy with HipChat. Atlassian made
Stride too, so let's not trust them blindly? Sure, we can always move to
another platform after moving to Stride, but it'll be a waste of time for
everyone. Let's see what our options really are, first!

I don't think we have many needs, and frankly I don't care which tool we'll
be using. I'd rather it be open source, but I'll just use whatever we pick
in the end, as long as I can write messages and receive messages. But I
want people to be on this platform: both the team, and ideally community
members. So let's just make sure everyone is at least comfortable with our
choice.
Sure some features are not useful to everybody, but in the end it's a
matter of taste and personal workflow, and we can't argue about that
without enforcing a standardized workflow. I think it would be more useful
to just list what we want, then see which platforms fit best, then pick
one, compromising as needed.

I started a document to compare various solutions, feel free to add
anything you think is relevant:
https://docs.google.com/spreadsheets/d/1oiI_SO4O5OwTx7Fd8_lvhOvVcIIYLbnSY1MAqemz-JI/edit?usp=sharing

... But I think the one criteria that will make us pick Stride is free
hosting. Most other platforms either do not have a free plan, or do not
provide all of their features to free plan users. Zulip apparently removes
OAuth authentication in its free plan, for instance. The Infinispan team
has OAuth authentication enabled though... Do they pay for their Zulip
instance?

Of course if we could host it ourselves it would be another story, but I
doubt anyone wants to add that to the list of tools we currently maintain.


On Mon, 21 May 2018 at 14:02 Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> On Fri, May 18, 2018 at 1:37 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > You can't "do your job" without yet another way to get notified of CI job
> > status?  I'm confused - did Jenkins remove all of its other forms of
> > notification?  ;)  Seriously though,  I've never understood this desire
> to
> > have yet another communications "inbox" spammed by automated
> notifications
> > - and its even worse in Hip Cat because I can never hide them.  So it is
> > hard for me to incorporate this into the argument against moving.
> >
>
> Typically, for the websites builds, I like to have the notifications on
> HipChat. Not vital but it's something I appreciate.
>
>
> > Y'all really wanted to move to Hip Chat in the first place even though to
> > me it always felt (and feels) half-baked itself.
> >
>
> I wasn't part of the team at that point.
>
>
> > And if the web client is as good as the native client, I assume you use
> > the web client instead?
> >
>
> Yes. I have a pinned tab for it. Desktop notifications from the browser are
> well integrated now.
>
>
> > So to me it really comes down to what are the blockers to not making this
> > move now.  So far I hear:
> >
> >    1. No Jenkins notifications - see above
> >    2. Guest access - meh - If having to have an account to join the
> >    discussion is bad then we should immediately make our forums
> >    guest-accessible again as well ;)
> >
> > As mentioned in my email, I don't mind not having guest access if we have
> some sort of external auth integration (Github/Twitter/Google). This way,
> it avoids creating yet another account. That's what we have on our new
> forums.
>
> Maybe Stride has it, I don't know, but I would like our next chat system to
> have that.
>
> I took a look at several accounts we have on our forums and most of them
> are from GitHub or Google (I took seven randomly and 1 had an account
> specific to our forums - no better statistics sorry).
>
> >
> >    1. There may be better options out there - at some point can we just
> >    pick one and use it?  Is one "inbox" really that much better than
> another
> >    "inbox"?  And clearly I am not even tied to Hip Chat - I was one of
> the
> >    people wanting to not move there.  Radim, what makes Zulip so amazing?
> >    2. "Coordination tool"?  Not really sure what this one is about.  Is
> >    this back to Jenkins notifications?  If you mean a communications
> tool, of
> >    course it works.  They are largely the same.  Andrea, Sanne and I have
> >    played with it, so we in fact do have some idea if it will (spoiler:
> it
> >    does)
> >    3. We should go where WildFly goes (?).
> >
> > My main point is that we have no idea if Stride is stable at the moment.
> They definitely don't want to massively migrate the HipChat users and I
> found at least one comment of a person who has migrated there and is not
> happy at all (not saying it makes all the migrated users unhappy, just
> saying that it might be a bad move if we do it now).
>
> So again, what problem are we trying to solve by migrating to Stride while
> it's still a work in progress? Because you reversed the question but it is
> the correct question.
>
> - If it is the client issue, is the Stride client better integrated? And is
> it enough to trigger the migration?
> - If it's the access difficulty, does Stride allow external
> authentications? Because that's what external users want.
> - If it's the "it's a pain to be logged in to multiple instances", are we
> all moving to Stride and will it solve the issue - meaning is it easier to
> be connected to multiple instances?
> - Other issues I'm not aware of?
>
> When you want to migrate to something new, you ponder the risks with the
> benefits. For now, noone has stated any clear benefit, apart from "it's
> new" and "HipChat has issues but we don't know if they will be solved by
> Stride".
>
> Note that my position is not "we should stay on HipChat forever" because we
> can't as they will close the service at some point. My position is:
> - I'm not sure the risk of moving to a half-baked system is worth it if
> there are no clear benefits (I would wait a bit)
> - is Stride gonna solve our issues or do we need to move to another system?
> (because if it's the case, let's avoid the Stride square).
>
> --
> 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  Tue May 22 04:38:35 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 22 May 2018 09:38:35 +0100
Subject: [hibernate-dev] Stride
In-Reply-To: <CAEqagpr6fveA-8Q7WHig3xJuB7FEp4P_AvP1vMjdSvdA9j7Zsg@mail.gmail.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
	<CAFm4XO2UzDPv+BnkG_=QT+pLWxVyCK5u1-B8FZPpQfOG7GemLg@mail.gmail.com>
	<4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com>
	<CAFm4XO1YC1e_yLEawfX-+Mro-WEuM=pGB_DC3NPbYpvn0HNmnA@mail.gmail.com>
	<CALt0+o9eQ-ZTDzLbiu_63tLaQ-=uOwoeWgR3He4PBXJQi85aHQ@mail.gmail.com>
	<CAFdSV9sAJp32Z7oqn6QtPb3ZTSkW3uVFPqom8KCnM4xeoSY8wQ@mail.gmail.com>
	<CALt0+o_yq8=K1aOFzkX22H41A+oh4rjJ3OAiVu+E9D=gCZhBvA@mail.gmail.com>
	<CAEqagpr6fveA-8Q7WHig3xJuB7FEp4P_AvP1vMjdSvdA9j7Zsg@mail.gmail.com>
Message-ID: <CAFm4XO0khaSGmmrKdJ8bpSGWY1Fd87ypFb7hNVQ4avgbHiybSQ@mail.gmail.com>

I see it much simpler.

We're moving to Stride because that's how HipChat evolved.


On Tue, 22 May 2018, 09:34 Yoann Rodiere, <yoann at hibernate.org> wrote:

> I think the problem here is about how we're choosing to migrate to another
> tool. We are basically moving to Stride because Atlassian is being
> uncooperative with updating HipChat, even though Stride is still not fully
> functional.
> Atlassian made HipChat, and we're not happy with HipChat. Atlassian made
> Stride too, so let's not trust them blindly? Sure, we can always move to
> another platform after moving to Stride, but it'll be a waste of time for
> everyone. Let's see what our options really are, first!
>
> I don't think we have many needs, and frankly I don't care which tool we'll
> be using. I'd rather it be open source, but I'll just use whatever we pick
> in the end, as long as I can write messages and receive messages. But I
> want people to be on this platform: both the team, and ideally community
> members. So let's just make sure everyone is at least comfortable with our
> choice.
> Sure some features are not useful to everybody, but in the end it's a
> matter of taste and personal workflow, and we can't argue about that
> without enforcing a standardized workflow. I think it would be more useful
> to just list what we want, then see which platforms fit best, then pick
> one, compromising as needed.
>
> I started a document to compare various solutions, feel free to add
> anything you think is relevant:
>
> https://docs.google.com/spreadsheets/d/1oiI_SO4O5OwTx7Fd8_lvhOvVcIIYLbnSY1MAqemz-JI/edit?usp=sharing
>
> ... But I think the one criteria that will make us pick Stride is free
> hosting. Most other platforms either do not have a free plan, or do not
> provide all of their features to free plan users. Zulip apparently removes
> OAuth authentication in its free plan, for instance. The Infinispan team
> has OAuth authentication enabled though... Do they pay for their Zulip
> instance?
>
> Of course if we could host it ourselves it would be another story, but I
> doubt anyone wants to add that to the list of tools we currently maintain.
>
>
> On Mon, 21 May 2018 at 14:02 Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
> > Hi,
> >
> > On Fri, May 18, 2018 at 1:37 PM, Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> > > You can't "do your job" without yet another way to get notified of CI
> job
> > > status?  I'm confused - did Jenkins remove all of its other forms of
> > > notification?  ;)  Seriously though,  I've never understood this desire
> > to
> > > have yet another communications "inbox" spammed by automated
> > notifications
> > > - and its even worse in Hip Cat because I can never hide them.  So it
> is
> > > hard for me to incorporate this into the argument against moving.
> > >
> >
> > Typically, for the websites builds, I like to have the notifications on
> > HipChat. Not vital but it's something I appreciate.
> >
> >
> > > Y'all really wanted to move to Hip Chat in the first place even though
> to
> > > me it always felt (and feels) half-baked itself.
> > >
> >
> > I wasn't part of the team at that point.
> >
> >
> > > And if the web client is as good as the native client, I assume you use
> > > the web client instead?
> > >
> >
> > Yes. I have a pinned tab for it. Desktop notifications from the browser
> are
> > well integrated now.
> >
> >
> > > So to me it really comes down to what are the blockers to not making
> this
> > > move now.  So far I hear:
> > >
> > >    1. No Jenkins notifications - see above
> > >    2. Guest access - meh - If having to have an account to join the
> > >    discussion is bad then we should immediately make our forums
> > >    guest-accessible again as well ;)
> > >
> > > As mentioned in my email, I don't mind not having guest access if we
> have
> > some sort of external auth integration (Github/Twitter/Google). This way,
> > it avoids creating yet another account. That's what we have on our new
> > forums.
> >
> > Maybe Stride has it, I don't know, but I would like our next chat system
> to
> > have that.
> >
> > I took a look at several accounts we have on our forums and most of them
> > are from GitHub or Google (I took seven randomly and 1 had an account
> > specific to our forums - no better statistics sorry).
> >
> > >
> > >    1. There may be better options out there - at some point can we just
> > >    pick one and use it?  Is one "inbox" really that much better than
> > another
> > >    "inbox"?  And clearly I am not even tied to Hip Chat - I was one of
> > the
> > >    people wanting to not move there.  Radim, what makes Zulip so
> amazing?
> > >    2. "Coordination tool"?  Not really sure what this one is about.  Is
> > >    this back to Jenkins notifications?  If you mean a communications
> > tool, of
> > >    course it works.  They are largely the same.  Andrea, Sanne and I
> have
> > >    played with it, so we in fact do have some idea if it will (spoiler:
> > it
> > >    does)
> > >    3. We should go where WildFly goes (?).
> > >
> > > My main point is that we have no idea if Stride is stable at the
> moment.
> > They definitely don't want to massively migrate the HipChat users and I
> > found at least one comment of a person who has migrated there and is not
> > happy at all (not saying it makes all the migrated users unhappy, just
> > saying that it might be a bad move if we do it now).
> >
> > So again, what problem are we trying to solve by migrating to Stride
> while
> > it's still a work in progress? Because you reversed the question but it
> is
> > the correct question.
> >
> > - If it is the client issue, is the Stride client better integrated? And
> is
> > it enough to trigger the migration?
> > - If it's the access difficulty, does Stride allow external
> > authentications? Because that's what external users want.
> > - If it's the "it's a pain to be logged in to multiple instances", are we
> > all moving to Stride and will it solve the issue - meaning is it easier
> to
> > be connected to multiple instances?
> > - Other issues I'm not aware of?
> >
> > When you want to migrate to something new, you ponder the risks with the
> > benefits. For now, noone has stated any clear benefit, apart from "it's
> > new" and "HipChat has issues but we don't know if they will be solved by
> > Stride".
> >
> > Note that my position is not "we should stay on HipChat forever" because
> we
> > can't as they will close the service at some point. My position is:
> > - I'm not sure the risk of moving to a half-baked system is worth it if
> > there are no clear benefits (I would wait a bit)
> > - is Stride gonna solve our issues or do we need to move to another
> system?
> > (because if it's the case, let's avoid the Stride square).
> >
> > --
> > 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From yoann at hibernate.org  Tue May 22 04:43:06 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 22 May 2018 10:43:06 +0200
Subject: [hibernate-dev] Disallow uncategorized topics
Message-ID: <CAEqagpr2YS18Vo4OP1Tf4QadW_r7snsZCAOQQXFwc=PoWXMN1A@mail.gmail.com>

Hi,

We've seen a few posts on discourse lately without any category. More often
than not, these are about ORM (which makes sense since most posts are about
ORM).

This is a bit annoying since it makes it hard to configure Discourse to
only receive notifications about topics we want to actively monitor.

Would anyone object to disallowing uncategorized topics? I can create a
"Miscellaneous" category if you want, but I'd really like people to pick a
category when they create a topic.
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From guillaume.smet at gmail.com  Tue May 22 04:49:52 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 22 May 2018 10:49:52 +0200
Subject: [hibernate-dev] Stride
In-Reply-To: <CAEqagpr6fveA-8Q7WHig3xJuB7FEp4P_AvP1vMjdSvdA9j7Zsg@mail.gmail.com>
References: <CAFdSV9tKabFc4E6Q7aX7hpkJYoD2S7i=+k-SXk+HaCmPn4X6Og@mail.gmail.com>
	<CAFm4XO2UzDPv+BnkG_=QT+pLWxVyCK5u1-B8FZPpQfOG7GemLg@mail.gmail.com>
	<4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com>
	<CAFm4XO1YC1e_yLEawfX-+Mro-WEuM=pGB_DC3NPbYpvn0HNmnA@mail.gmail.com>
	<CALt0+o9eQ-ZTDzLbiu_63tLaQ-=uOwoeWgR3He4PBXJQi85aHQ@mail.gmail.com>
	<CAFdSV9sAJp32Z7oqn6QtPb3ZTSkW3uVFPqom8KCnM4xeoSY8wQ@mail.gmail.com>
	<CALt0+o_yq8=K1aOFzkX22H41A+oh4rjJ3OAiVu+E9D=gCZhBvA@mail.gmail.com>
	<CAEqagpr6fveA-8Q7WHig3xJuB7FEp4P_AvP1vMjdSvdA9j7Zsg@mail.gmail.com>
Message-ID: <CALt0+o-49sT8fTpxYSRTBD_1zOHnK18WXFwxVrxcoocrbMT6Ew@mail.gmail.com>

On Tue, May 22, 2018 at 10:26 AM, Yoann Rodiere <yoann at hibernate.org> wrote:

> ... But I think the one criteria that will make us pick Stride is free
> hosting. Most other platforms either do not have a free plan, or do not
> provide all of their features to free plan users. Zulip apparently removes
> OAuth authentication in its free plan, for instance. The Infinispan team
> has OAuth authentication enabled though... Do they pay for their Zulip
> instance?
>

Quote: "Zulip Cloud Premium is free for open source projects and a wide
variety of non-commercial entities"

What bugged me first was the capped archives of the free offer.

HipChat is doing a very similar thing.

-- 
Guillaume

From sanne at hibernate.org  Tue May 22 05:05:47 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 22 May 2018 10:05:47 +0100
Subject: [hibernate-dev] Disallow uncategorized topics
In-Reply-To: <CAEqagpr2YS18Vo4OP1Tf4QadW_r7snsZCAOQQXFwc=PoWXMN1A@mail.gmail.com>
References: <CAEqagpr2YS18Vo4OP1Tf4QadW_r7snsZCAOQQXFwc=PoWXMN1A@mail.gmail.com>
Message-ID: <CAFm4XO2_OvQ479z+PuJ_jegMNqqMssON-qGNzFGDmYJfw9qwTg@mail.gmail.com>

+1 to encourage people to set a category

but I wouldn't require strict rules, it's not like we're flooded with
notifications?

In particular, I see no value in a "Miscellaneous" category; it's not
like people are going to think "cool, Miscellaneous is exactly what I
was looking for".

On 22 May 2018 at 09:43, Yoann Rodiere <yoann at hibernate.org> wrote:
> Hi,
>
> We've seen a few posts on discourse lately without any category. More often
> than not, these are about ORM (which makes sense since most posts are about
> ORM).
>
> This is a bit annoying since it makes it hard to configure Discourse to
> only receive notifications about topics we want to actively monitor.
>
> Would anyone object to disallowing uncategorized topics? I can create a
> "Miscellaneous" category if you want, but I'd really like people to pick a
> category when they create a topic.
> --
> 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 guillaume.smet at gmail.com  Tue May 22 05:13:42 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 22 May 2018 11:13:42 +0200
Subject: [hibernate-dev] Disallow uncategorized topics
In-Reply-To: <CAEqagpr2YS18Vo4OP1Tf4QadW_r7snsZCAOQQXFwc=PoWXMN1A@mail.gmail.com>
References: <CAEqagpr2YS18Vo4OP1Tf4QadW_r7snsZCAOQQXFwc=PoWXMN1A@mail.gmail.com>
Message-ID: <CALt0+o_s9ZbakPSYBP9Sv2Ldxr3M74xnymGOqHDcK3kMwnm=rA@mail.gmail.com>

Hi,

On Tue, May 22, 2018 at 10:43 AM, Yoann Rodiere <yoann at hibernate.org> wrote:

> Would anyone object to disallowing uncategorized topics? I can create a
> "Miscellaneous" category if you want, but I'd really like people to pick a
> category when they create a topic.


Sure, let's do it if we can.

I don't think we need a Misc. category. I just categorized all the
uncategorized posts and they all fit somewhere.

-- 
Guillaume

From yoann at hibernate.org  Tue May 22 05:15:28 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 22 May 2018 11:15:28 +0200
Subject: [hibernate-dev] Disallow uncategorized topics
In-Reply-To: <CAFm4XO2_OvQ479z+PuJ_jegMNqqMssON-qGNzFGDmYJfw9qwTg@mail.gmail.com>
References: <CAEqagpr2YS18Vo4OP1Tf4QadW_r7snsZCAOQQXFwc=PoWXMN1A@mail.gmail.com>
	<CAFm4XO2_OvQ479z+PuJ_jegMNqqMssON-qGNzFGDmYJfw9qwTg@mail.gmail.com>
Message-ID: <CAEqagpreRLXUH92zHFQu2Xin1db+M9KCPV7CUxgP=7EEj3ESTg@mail.gmail.com>

I counted at least 3 mis-categorized topics just this weekend, and beyond
the notification we also have to categorize them ourselves.

Unfortunately I can't "encourage" without enforcing a strict rule.
Discourse only has an option to force people to chose a category, not an
option to make it more obvious that people should chose a category.
That's why I suggested the "Miscellaneous" category: they will be forced to
pick a category, but if nothing fits they can always pick "Miscellaneous".
Obviously I don't imagine that people will think "Miscellaneous" will fit
their needs exactly, that's a last resort.

On Tue, 22 May 2018 at 11:06 Sanne Grinovero <sanne at hibernate.org> wrote:

> +1 to encourage people to set a category
>
> but I wouldn't require strict rules, it's not like we're flooded with
> notifications?
>
> In particular, I see no value in a "Miscellaneous" category; it's not
> like people are going to think "cool, Miscellaneous is exactly what I
> was looking for".
>
> On 22 May 2018 at 09:43, Yoann Rodiere <yoann at hibernate.org> wrote:
> > Hi,
> >
> > We've seen a few posts on discourse lately without any category. More
> often
> > than not, these are about ORM (which makes sense since most posts are
> about
> > ORM).
> >
> > This is a bit annoying since it makes it hard to configure Discourse to
> > only receive notifications about topics we want to actively monitor.
> >
> > Would anyone object to disallowing uncategorized topics? I can create a
> > "Miscellaneous" category if you want, but I'd really like people to pick
> a
> > category when they create a topic.
> > --
> > 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
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From sanne at hibernate.org  Tue May 22 05:22:08 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 22 May 2018 10:22:08 +0100
Subject: [hibernate-dev] Disallow uncategorized topics
In-Reply-To: <CAEqagpreRLXUH92zHFQu2Xin1db+M9KCPV7CUxgP=7EEj3ESTg@mail.gmail.com>
References: <CAEqagpr2YS18Vo4OP1Tf4QadW_r7snsZCAOQQXFwc=PoWXMN1A@mail.gmail.com>
	<CAFm4XO2_OvQ479z+PuJ_jegMNqqMssON-qGNzFGDmYJfw9qwTg@mail.gmail.com>
	<CAEqagpreRLXUH92zHFQu2Xin1db+M9KCPV7CUxgP=7EEj3ESTg@mail.gmail.com>
Message-ID: <CAFm4XO3+wjqB0ZJV3SvjBELr26xbuuNWP0Yazvvtyd7CH8KW+g@mail.gmail.com>

On 22 May 2018 at 10:15, Yoann Rodiere <yoann at hibernate.org> wrote:
> I counted at least 3 mis-categorized topics just this weekend, and beyond
> the notification we also have to categorize them ourselves.
>
> Unfortunately I can't "encourage" without enforcing a strict rule. Discourse
> only has an option to force people to chose a category, not an option to
> make it more obvious that people should chose a category.
> That's why I suggested the "Miscellaneous" category: they will be forced to
> pick a category, but if nothing fits they can always pick "Miscellaneous".
> Obviously I don't imagine that people will think "Miscellaneous" will fit
> their needs exactly, that's a last resort.

Ah. What about a "" category ? Maybe that will encourage people to
stop a second and think about it, yet have the option to go ahead?

>
> On Tue, 22 May 2018 at 11:06 Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> +1 to encourage people to set a category
>>
>> but I wouldn't require strict rules, it's not like we're flooded with
>> notifications?
>>
>> In particular, I see no value in a "Miscellaneous" category; it's not
>> like people are going to think "cool, Miscellaneous is exactly what I
>> was looking for".
>>
>> On 22 May 2018 at 09:43, Yoann Rodiere <yoann at hibernate.org> wrote:
>> > Hi,
>> >
>> > We've seen a few posts on discourse lately without any category. More
>> > often
>> > than not, these are about ORM (which makes sense since most posts are
>> > about
>> > ORM).
>> >
>> > This is a bit annoying since it makes it hard to configure Discourse to
>> > only receive notifications about topics we want to actively monitor.
>> >
>> > Would anyone object to disallowing uncategorized topics? I can create a
>> > "Miscellaneous" category if you want, but I'd really like people to pick
>> > a
>> > category when they create a topic.
>> > --
>> > 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
>
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team

From yoann at hibernate.org  Tue May 22 05:30:15 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 22 May 2018 11:30:15 +0200
Subject: [hibernate-dev] Disallow uncategorized topics
In-Reply-To: <CAFm4XO3+wjqB0ZJV3SvjBELr26xbuuNWP0Yazvvtyd7CH8KW+g@mail.gmail.com>
References: <CAEqagpr2YS18Vo4OP1Tf4QadW_r7snsZCAOQQXFwc=PoWXMN1A@mail.gmail.com>
	<CAFm4XO2_OvQ479z+PuJ_jegMNqqMssON-qGNzFGDmYJfw9qwTg@mail.gmail.com>
	<CAEqagpreRLXUH92zHFQu2Xin1db+M9KCPV7CUxgP=7EEj3ESTg@mail.gmail.com>
	<CAFm4XO3+wjqB0ZJV3SvjBELr26xbuuNWP0Yazvvtyd7CH8KW+g@mail.gmail.com>
Message-ID: <CAEqagppTogvz5VdqXcpkZ-in4xMHdth_oz5LP3zuw6XsPLqcGA@mail.gmail.com>

I can create a category named " " and force users to pick something
explicitly, but it will render poorly, especially on the home page.

What's wrong with "Miscellaneous"? I can use another name if you want.
"Cannot categorize" or something like that. I can even try naming it
"Uncategorized", but there's already a "system" category with this name
(only enabled if we don't enforce categories), so I'm not sure if Discourse
will allow that.

On Tue, 22 May 2018 at 11:22 Sanne Grinovero <sanne at hibernate.org> wrote:

> On 22 May 2018 at 10:15, Yoann Rodiere <yoann at hibernate.org> wrote:
> > I counted at least 3 mis-categorized topics just this weekend, and beyond
> > the notification we also have to categorize them ourselves.
> >
> > Unfortunately I can't "encourage" without enforcing a strict rule.
> Discourse
> > only has an option to force people to chose a category, not an option to
> > make it more obvious that people should chose a category.
> > That's why I suggested the "Miscellaneous" category: they will be forced
> to
> > pick a category, but if nothing fits they can always pick
> "Miscellaneous".
> > Obviously I don't imagine that people will think "Miscellaneous" will fit
> > their needs exactly, that's a last resort.
>
> Ah. What about a "" category ? Maybe that will encourage people to
> stop a second and think about it, yet have the option to go ahead?
>
> >
> > On Tue, 22 May 2018 at 11:06 Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> +1 to encourage people to set a category
> >>
> >> but I wouldn't require strict rules, it's not like we're flooded with
> >> notifications?
> >>
> >> In particular, I see no value in a "Miscellaneous" category; it's not
> >> like people are going to think "cool, Miscellaneous is exactly what I
> >> was looking for".
> >>
> >> On 22 May 2018 at 09:43, Yoann Rodiere <yoann at hibernate.org> wrote:
> >> > Hi,
> >> >
> >> > We've seen a few posts on discourse lately without any category. More
> >> > often
> >> > than not, these are about ORM (which makes sense since most posts are
> >> > about
> >> > ORM).
> >> >
> >> > This is a bit annoying since it makes it hard to configure Discourse
> to
> >> > only receive notifications about topics we want to actively monitor.
> >> >
> >> > Would anyone object to disallowing uncategorized topics? I can create
> a
> >> > "Miscellaneous" category if you want, but I'd really like people to
> pick
> >> > a
> >> > category when they create a topic.
> >> > --
> >> > 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
> >
> > --
> > 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  Tue May 22 05:48:06 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 22 May 2018 10:48:06 +0100
Subject: [hibernate-dev] Disallow uncategorized topics
In-Reply-To: <CAEqagppTogvz5VdqXcpkZ-in4xMHdth_oz5LP3zuw6XsPLqcGA@mail.gmail.com>
References: <CAEqagpr2YS18Vo4OP1Tf4QadW_r7snsZCAOQQXFwc=PoWXMN1A@mail.gmail.com>
	<CAFm4XO2_OvQ479z+PuJ_jegMNqqMssON-qGNzFGDmYJfw9qwTg@mail.gmail.com>
	<CAEqagpreRLXUH92zHFQu2Xin1db+M9KCPV7CUxgP=7EEj3ESTg@mail.gmail.com>
	<CAFm4XO3+wjqB0ZJV3SvjBELr26xbuuNWP0Yazvvtyd7CH8KW+g@mail.gmail.com>
	<CAEqagppTogvz5VdqXcpkZ-in4xMHdth_oz5LP3zuw6XsPLqcGA@mail.gmail.com>
Message-ID: <CAFm4XO2ZDz5xYFvM5afzf3yKtQfixtaL8kT6TdaEDWahterGDw@mail.gmail.com>

On 22 May 2018 at 10:30, Yoann Rodiere <yoann at hibernate.org> wrote:
> I can create a category named " " and force users to pick something
> explicitly, but it will render poorly, especially on the home page.

Just a joke. More seriously I was wondering if there was some way.

> What's wrong with "Miscellaneous"? I can use another name if you want.
> "Cannot categorize" or something like that. I can even try naming it
> "Uncategorized", but there's already a "system" category with this name
> (only enabled if we don't enforce categories), so I'm not sure if Discourse
> will allow that.

Nothing decidedly wrong with it. Just my last preference; IMO I'd
prefer keeping things as they are, but no strong feeling.

Thanks

>
> On Tue, 22 May 2018 at 11:22 Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> On 22 May 2018 at 10:15, Yoann Rodiere <yoann at hibernate.org> wrote:
>> > I counted at least 3 mis-categorized topics just this weekend, and
>> > beyond
>> > the notification we also have to categorize them ourselves.
>> >
>> > Unfortunately I can't "encourage" without enforcing a strict rule.
>> > Discourse
>> > only has an option to force people to chose a category, not an option to
>> > make it more obvious that people should chose a category.
>> > That's why I suggested the "Miscellaneous" category: they will be forced
>> > to
>> > pick a category, but if nothing fits they can always pick
>> > "Miscellaneous".
>> > Obviously I don't imagine that people will think "Miscellaneous" will
>> > fit
>> > their needs exactly, that's a last resort.
>>
>> Ah. What about a "" category ? Maybe that will encourage people to
>> stop a second and think about it, yet have the option to go ahead?
>>
>> >
>> > On Tue, 22 May 2018 at 11:06 Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> +1 to encourage people to set a category
>> >>
>> >> but I wouldn't require strict rules, it's not like we're flooded with
>> >> notifications?
>> >>
>> >> In particular, I see no value in a "Miscellaneous" category; it's not
>> >> like people are going to think "cool, Miscellaneous is exactly what I
>> >> was looking for".
>> >>
>> >> On 22 May 2018 at 09:43, Yoann Rodiere <yoann at hibernate.org> wrote:
>> >> > Hi,
>> >> >
>> >> > We've seen a few posts on discourse lately without any category. More
>> >> > often
>> >> > than not, these are about ORM (which makes sense since most posts are
>> >> > about
>> >> > ORM).
>> >> >
>> >> > This is a bit annoying since it makes it hard to configure Discourse
>> >> > to
>> >> > only receive notifications about topics we want to actively monitor.
>> >> >
>> >> > Would anyone object to disallowing uncategorized topics? I can create
>> >> > a
>> >> > "Miscellaneous" category if you want, but I'd really like people to
>> >> > pick
>> >> > a
>> >> > category when they create a topic.
>> >> > --
>> >> > 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
>> >
>> > --
>> > 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 yoann at hibernate.org  Tue May 22 06:01:08 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 22 May 2018 12:01:08 +0200
Subject: [hibernate-dev] Disallow uncategorized topics
In-Reply-To: <CAFm4XO2ZDz5xYFvM5afzf3yKtQfixtaL8kT6TdaEDWahterGDw@mail.gmail.com>
References: <CAEqagpr2YS18Vo4OP1Tf4QadW_r7snsZCAOQQXFwc=PoWXMN1A@mail.gmail.com>
	<CAFm4XO2_OvQ479z+PuJ_jegMNqqMssON-qGNzFGDmYJfw9qwTg@mail.gmail.com>
	<CAEqagpreRLXUH92zHFQu2Xin1db+M9KCPV7CUxgP=7EEj3ESTg@mail.gmail.com>
	<CAFm4XO3+wjqB0ZJV3SvjBELr26xbuuNWP0Yazvvtyd7CH8KW+g@mail.gmail.com>
	<CAEqagppTogvz5VdqXcpkZ-in4xMHdth_oz5LP3zuw6XsPLqcGA@mail.gmail.com>
	<CAFm4XO2ZDz5xYFvM5afzf3yKtQfixtaL8kT6TdaEDWahterGDw@mail.gmail.com>
Message-ID: <CAEqagppSkqAOtVHgsso2GOfhrM8qUTUhhzqXXRuOYcrm_51D5Q@mail.gmail.com>

Done: users must now choose a category, and may use "Miscellaneous" if
their topic really doesn't fit any category.

On Tue, 22 May 2018 at 11:48 Sanne Grinovero <sanne at hibernate.org> wrote:

> On 22 May 2018 at 10:30, Yoann Rodiere <yoann at hibernate.org> wrote:
> > I can create a category named " " and force users to pick something
> > explicitly, but it will render poorly, especially on the home page.
>
> Just a joke. More seriously I was wondering if there was some way.
>
> > What's wrong with "Miscellaneous"? I can use another name if you want.
> > "Cannot categorize" or something like that. I can even try naming it
> > "Uncategorized", but there's already a "system" category with this name
> > (only enabled if we don't enforce categories), so I'm not sure if
> Discourse
> > will allow that.
>
> Nothing decidedly wrong with it. Just my last preference; IMO I'd
> prefer keeping things as they are, but no strong feeling.
>
> Thanks
>
> >
> > On Tue, 22 May 2018 at 11:22 Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> On 22 May 2018 at 10:15, Yoann Rodiere <yoann at hibernate.org> wrote:
> >> > I counted at least 3 mis-categorized topics just this weekend, and
> >> > beyond
> >> > the notification we also have to categorize them ourselves.
> >> >
> >> > Unfortunately I can't "encourage" without enforcing a strict rule.
> >> > Discourse
> >> > only has an option to force people to chose a category, not an option
> to
> >> > make it more obvious that people should chose a category.
> >> > That's why I suggested the "Miscellaneous" category: they will be
> forced
> >> > to
> >> > pick a category, but if nothing fits they can always pick
> >> > "Miscellaneous".
> >> > Obviously I don't imagine that people will think "Miscellaneous" will
> >> > fit
> >> > their needs exactly, that's a last resort.
> >>
> >> Ah. What about a "" category ? Maybe that will encourage people to
> >> stop a second and think about it, yet have the option to go ahead?
> >>
> >> >
> >> > On Tue, 22 May 2018 at 11:06 Sanne Grinovero <sanne at hibernate.org>
> >> > wrote:
> >> >>
> >> >> +1 to encourage people to set a category
> >> >>
> >> >> but I wouldn't require strict rules, it's not like we're flooded with
> >> >> notifications?
> >> >>
> >> >> In particular, I see no value in a "Miscellaneous" category; it's not
> >> >> like people are going to think "cool, Miscellaneous is exactly what I
> >> >> was looking for".
> >> >>
> >> >> On 22 May 2018 at 09:43, Yoann Rodiere <yoann at hibernate.org> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > We've seen a few posts on discourse lately without any category.
> More
> >> >> > often
> >> >> > than not, these are about ORM (which makes sense since most posts
> are
> >> >> > about
> >> >> > ORM).
> >> >> >
> >> >> > This is a bit annoying since it makes it hard to configure
> Discourse
> >> >> > to
> >> >> > only receive notifications about topics we want to actively
> monitor.
> >> >> >
> >> >> > Would anyone object to disallowing uncategorized topics? I can
> create
> >> >> > a
> >> >> > "Miscellaneous" category if you want, but I'd really like people to
> >> >> > pick
> >> >> > a
> >> >> > category when they create a topic.
> >> >> > --
> >> >> > 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
> >> >
> >> > --
> >> > 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
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From sanne at hibernate.org  Tue May 22 07:42:42 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 22 May 2018 12:42:42 +0100
Subject: [hibernate-dev] WildFly 14 requirements for Hibernate libraries
Message-ID: <CAFm4XO1s+Zsn-R44Qrb+H=Gg08aFNG6Le_2+xBYO_8T+1BeRPg@mail.gmail.com>

Hi all,

good news first: WildFly 13 will include our latest Hibernate
libraries, in addition to the existing ones.

When booting WildFly 13 with the "-Dee8.preview.mode=true" property
set, it will use:
 - Hibernate ORM 5.3
 - Hibernate Search 5.10
 - Hibernate Validator 6.0

(Validator 6 was available also in WildFly 12)

By default, for users not setting this preview mode, it will use the
older versions which were included in previous WildFly releases -
providing JPA 2.1 and EE7 compatibility only.

We're getting some requirements for WildFly 14 though, which needs to
be ready within 3 months.

In particular:

 A] EE8 will be the only mode

So while today users have the ability to opt-in or ORM 5.3 and
companions, this will be enforced as the older libraries are removed.

Not much we need to do, other than further ensuring that people will
not have trouble. It's also an opportunity to get rid of unnecessary
dependencies.

 B] we need to finish some backward compatibility work.

We did quite some work to ensure ORM 5.3 would be great at backward
compatibility but we left some pending work, e.g. the Compatibility
Transformer that David proposed is not available yet and it needs some
more details from us, such as a definitive list of the transformations
it will need to perform.

Also, the QE team didn't have a chance to review the work in detail
yet; I'm confident we did most of the work already but they might
raise the bar further or just have some questions, we will need to
work with them. I also hope we'll get more familiar with them and
their processes as clearly this isn't a one-off, we can all benefit
from working more closely with them for all future releases.

 C] WildFly 14 is expected to work on both JDK8 and JDK11

Most work to support new JDKs has been done but we need to finish the
last details.
 - CI jobs still not entirely working on JDK11
 - Javassist might stay as an option but we need to make sure no
feature relies on it, as I don't think Javassist will be supportable
on JDK11
 - consequentially, the Byte Buddy based alternative needs to be great
(some issues have been raised)
 - some code to work on JDK11 will need to invoke APIs which were not
available in JDK8: are we going to release "multi-release jars"?
 - resume the work on modernizing the XML parsers?

In particular, Byte Buddy on JDK11 will need access to the classloader
via VarHandles to enhance entities; I didn't investigate this
thoroughly yet but I believe I won't be able to give these references
to BB while relying exclusively on JDK8 APIs.

If we manage to improve anything by the 28th we can still include
micro-fixes in WildFly 13; in particular, if you are aware of any
blocker let's fix them now so that people can give us more detailed
feedback by actually using the EE8 preview mode.

(This includes possibly planning for some micro releases within a week)

Thanks,
Sanne

From smarlow at redhat.com  Tue May 22 08:56:45 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 22 May 2018 08:56:45 -0400
Subject: [hibernate-dev] Is bytecode enhancement enabled by default in
 5.3?
In-Reply-To: <CAFm4XO1uLygeGPjKqC+LVVLoLO+JquL3rKhH0RSy=eohFrxcNg@mail.gmail.com>
References: <CAFDzhiRmiKcbWn=HVuMG+CQSMJ_kR8GRH76Tzueqq3c2TTj_vg@mail.gmail.com>
	<850f8263-c48e-0a4c-c634-d6cd8da59f29@redhat.com>
	<CAFm4XO2iYqR_32UeJW=3_hoa4wgHF2zRCXs0fG2w+Uhcadjdng@mail.gmail.com>
	<CAJtdNN4YqSc47v4MjTV8tfRKEyqs6QtOJC9Vo9aeN7G-b8sPwA@mail.gmail.com>
	<CAFm4XO1uLygeGPjKqC+LVVLoLO+JquL3rKhH0RSy=eohFrxcNg@mail.gmail.com>
Message-ID: <ce338acb-90bf-e2cf-4fd0-b2c90b17cbd7@redhat.com>



On 05/20/2018 08:48 AM, Sanne Grinovero wrote:
> Hi Scott,
> 
> could you explain what you mean by "tradeoff" in this context?  

Hi Sanne,

Sure, see below for more details.

> 
> Thanks!
> 
> 
> On 20 May 2018 at 12:06, Scott Marlow <smarlow at redhat.com> wrote:
>> There is a tradeoff in WF deployment, between Hibernate bytecode (runtime)
>> enhancing class transformers, being registered before CDI deployment, reads
>> the entity classes.

To explain what I mean by the "tradeoff", I will first explain some 
ordering rules based on the current WildFly/Hibernate deployment scheme.

1. The first "must happen before" rule is that the Hibernate ORM 
bytecode enhancer must register via 
PersistenceUnitInfo.addTransformer(ClassTransformer) [1], before any 
application classes are loaded/defined by the application classloader.

2. Another "must happen before" rule is that the DataSource [2] must be 
available before the first Hibernate ORM (persistence unit) bootstrap 
phase (in the case of applications using the two-phase bootstrap). For 
applications using the single phase PU bootstrap, the DataSource must be 
available before the call to Persistence.createEntityManagerFactory().

3. Another "must happen before" rule, is that CDI handling (WF) deployer 
unit processing code must read the application classes and transform 
application classes as part of CDI deployment, in order to meet the CDI 
requirements.  The first Hibernate ORM pu bootstrap phrase, must 
currently register its class transformer [1] before CDI reads/transforms 
application classes, or the Hibernate entity class transformer, will be 
ignored (note, there is no deployment failure for this, nor can there be 
currently).

4.  Another "must happen before" rule, is that WildFly 
@DataSourceDefinitions, do not become available until very late 
deployment phases, when application classes, will already have been 
read.  Hibernate can also start its first Hibernate ORM pu bootstrap 
phrase, very late as well but again, the Hibernate entity class will be 
ignored (since application classes are already defined before Hibernate 
starts deployment).

If applications want entity classes to be enhanced, the first Hibernate 
ORM pu bootstrap phrase, must run early enough but that cannot happen if 
the pu depends on a @DataSourceDefinition.

There are some WildFly pu hints that influence the ordering but 
currently, apps have to decide what they really want to work:

jboss.as.jpa.classtransformer - defaults to true but if false, WildFly 
does not try to register the entity class transformers early.

wildfly.jpa.twophasebootstrap - defaults to true but if false, WildFly 
does not try to use two phase persistence unit bootstrap (currently only 
supported for Hibernate).

Steve Ebersole and I have talked about adding additional phases to the 
PU bootstrap, but that was so long ago, I forget if it was about 
registering the ORM class transformer [1] earlier.  If ORM 5.3 or 6.0, 
is depending on [1] to work correctly in order to implement the ORM 
features, we need to take some action.

In the past, I recall someone mentioning that lazy loading or dirty flag 
handling, would depend on bytecode enhancing.  If that happened or will 
happen, we should discuss what the fallback solution is for when 
bytecode enhancing is not working.

Another subject, is how should a user find out that bytecode enhancing 
is actually updating application entity classes.  Should that operation 
have trace logging and should that be at the WF or ORM level?

Scott

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

[2] https://docs.oracle.com/javase/7/docs/api/javax/sql/DataSource.html

>>
>> There is also the tradeoff between Hibernate bytecode (runtime) enhancing
>> class transformers being registered too late because the persistent unit
>> uses a datasourcedefinition.
>>
>> I asked Gail's question for 5.1.x and the answer was no.
>>
>> Now, for 5.3, I don't understand the answers yet.
>>
>> Anyway, wanted to mention the above, to share more info with all, as to why
>> we are asking.
>>

From guillaume.smet at gmail.com  Tue May 22 09:39:29 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 22 May 2018 15:39:29 +0200
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o91=szL+-HW9ffv4CnsHNH+ZK+d8RWXM3gQSivdtkMMjw@mail.gmail.com>

Hi,

Here are the minutes of our NoORM IRC meeting:

15:38 < jbott> Meeting ended Tue May 22 13:37:54 2018 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:38 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-22-13.00.html
15:38 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-22-13.00.txt
15:38 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-05-22-13.00.log.html

Have a nice day.

-- 
Guillaume

From smarlow at redhat.com  Wed May 23 08:51:54 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 23 May 2018 08:51:54 -0400
Subject: [hibernate-dev] Suggestions for alternative due to deprecation of
 Configuration access in ServiceContributor...
Message-ID: <c2ac5331-02e4-e7de-a970-c7f207752c1c@redhat.com>

For the WildFly use of ServiceContributor [1], which registers for each 
SF/EMF, the 2lc RegionFactoryInitiator + JtaPlatform, I am worried that 
we don't yet have a "per app deployment" way to disable the WF 
ServiceContributorImpl.

I'm thinking that some applications (e.g. Spring) may not want to use 
the WF 2lc RegionFactoryInitiator + JtaPlatform classes.  To accomadate 
that need, I'm thinking of introducing WF configuration properties for 
controlling this:

* wildfly.jpa.jtaplatform will default to true but if set to false, [1] 
will not call serviceRegistryBuilder.addInitiator(new 
WildFlyCustomJtaPlatformInitiator()).

* wildfly.jpa.regionfactory will default to true but if set to false, 
[1] will not call serviceRegistryBuilder.addInitiator(new 
WildFlyCustomRegionFactoryInitiator()).

My request is that we keep the 
StandardServiceRegistryBuilder.getSettings() call and document that in 
the future, instead of removing it, we will change it to return a read 
only copy of the configuration settings.  Then, I can update [1] to 
check for these new properties and know that I can depend on using 
StandardServiceRegistryBuilder.getSettings().

An alternative could be to add a new method 
StandardServiceRegistryBuilder.getReadOnlySettings().

I'd like to make the WF code change now for WF13, so a quick response is 
appreciated! :)

Scott

[1] 
https://github.com/scottmarlow/wildfly/blob/WFLY-10427/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L30

From steve at hibernate.org  Wed May 23 09:17:22 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 23 May 2018 08:17:22 -0500
Subject: [hibernate-dev] Is bytecode enhancement enabled by default in
	5.3?
In-Reply-To: <ce338acb-90bf-e2cf-4fd0-b2c90b17cbd7@redhat.com>
References: <CAFDzhiRmiKcbWn=HVuMG+CQSMJ_kR8GRH76Tzueqq3c2TTj_vg@mail.gmail.com>
	<850f8263-c48e-0a4c-c634-d6cd8da59f29@redhat.com>
	<CAFm4XO2iYqR_32UeJW=3_hoa4wgHF2zRCXs0fG2w+Uhcadjdng@mail.gmail.com>
	<CAJtdNN4YqSc47v4MjTV8tfRKEyqs6QtOJC9Vo9aeN7G-b8sPwA@mail.gmail.com>
	<CAFm4XO1uLygeGPjKqC+LVVLoLO+JquL3rKhH0RSy=eohFrxcNg@mail.gmail.com>
	<ce338acb-90bf-e2cf-4fd0-b2c90b17cbd7@redhat.com>
Message-ID: <CAFdSV9viwYX9uDKzq0U2VKpfV4VOt5M7fDp9jYdhcURLKbGzpQ@mail.gmail.com>

I never understood this `DataSourceDefinitions` part.  Why can't they just
be discovered via jipijapa prior to doing anything with Hibernate/JPA?

See inline...

Steve Ebersole and I have talked about adding additional phases to the
> PU bootstrap, but that was so long ago, I forget if it was about
> registering the ORM class transformer [1] earlier.  If ORM 5.3 or 6.0,
> is depending on [1] to work correctly in order to implement the ORM
> features, we need to take some action.
>

So the rub right now (up through and including) 5.3 is that we sometimes
load domain model Class references during this "first bootstrap phase".
What really needs to happen is for Hibernate to unequivocally delay loading
domain model Class references until after this phase is over - at least
delay loading them into the "real" ClassLoader, we can use the JPA temp
ClassLoader if it is available.

6.0 will delay loading these Class references even more so than today.
However, even with 6.0 we cannot fully guarantee that we will never load
them during this 1st phase.  That is a design goal for 7.0 and the move to
Jandex.



> In the past, I recall someone mentioning that lazy loading or dirty flag
> handling, would depend on bytecode enhancing.  If that happened or will
> happen, we should discuss what the fallback solution is for when
> bytecode enhancing is not working.
>

Bytecode enhancement is not needed for either of these - Hibernate can (and
has forever) supported these without enhancement.  That will continue to be
the case.  Bytecode enhancement is simply an alternative means for adding
these features.

However, certain features such as automatic bi-dir association management
does require enhancement to work.



> Another subject, is how should a user find out that bytecode enhancing
> is actually updating application entity classes.  Should that operation
> have trace logging and should that be at the WF or ORM level?
>

Well based on what you described it sounds to me like there ought to be at
least 2 different log events here:

   1. The transformer is registered (this could be either WF or Hibernate
   or both)
   2. The transformer calls the Enhancer
   3. (?) Enhancer enhances a class.  Enhancer is an interface though and
   this would rely on the impls (Javassist and Byte Buddy) to do this.

From steve at hibernate.org  Wed May 23 09:20:54 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 23 May 2018 08:20:54 -0500
Subject: [hibernate-dev] Suggestions for alternative due to deprecation
 of Configuration access in ServiceContributor...
In-Reply-To: <c2ac5331-02e4-e7de-a970-c7f207752c1c@redhat.com>
References: <c2ac5331-02e4-e7de-a970-c7f207752c1c@redhat.com>
Message-ID: <CAFdSV9tfw5OqKifewyhQvaKSJjnX5_ZQ24sT-6905DSyAtjQRg@mail.gmail.com>

By "read only" I assume you mean immutable (aka,
Collections#immutableMap)?  If so, sure, that is a decent solution...


On Wed, May 23, 2018 at 7:55 AM Scott Marlow <smarlow at redhat.com> wrote:

> For the WildFly use of ServiceContributor [1], which registers for each
> SF/EMF, the 2lc RegionFactoryInitiator + JtaPlatform, I am worried that
> we don't yet have a "per app deployment" way to disable the WF
> ServiceContributorImpl.
>
> I'm thinking that some applications (e.g. Spring) may not want to use
> the WF 2lc RegionFactoryInitiator + JtaPlatform classes.  To accomadate
> that need, I'm thinking of introducing WF configuration properties for
> controlling this:
>
> * wildfly.jpa.jtaplatform will default to true but if set to false, [1]
> will not call serviceRegistryBuilder.addInitiator(new
> WildFlyCustomJtaPlatformInitiator()).
>
> * wildfly.jpa.regionfactory will default to true but if set to false,
> [1] will not call serviceRegistryBuilder.addInitiator(new
> WildFlyCustomRegionFactoryInitiator()).
>
> My request is that we keep the
> StandardServiceRegistryBuilder.getSettings() call and document that in
> the future, instead of removing it, we will change it to return a read
> only copy of the configuration settings.  Then, I can update [1] to
> check for these new properties and know that I can depend on using
> StandardServiceRegistryBuilder.getSettings().
>
> An alternative could be to add a new method
> StandardServiceRegistryBuilder.getReadOnlySettings().
>
> I'd like to make the WF code change now for WF13, so a quick response is
> appreciated! :)
>
> Scott
>
> [1]
>
> https://github.com/scottmarlow/wildfly/blob/WFLY-10427/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L30
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed May 23 09:39:49 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 23 May 2018 08:39:49 -0500
Subject: [hibernate-dev] Multiple ResultSets from JDBC execution
Message-ID: <CAFdSV9tfJFc6abR63f8QfjBScLgaLfTbZVRcx7rx_EEU_gFNkQ@mail.gmail.com>

Execution of procedure calls, function calls and anonymous blocks can all
lead to JDBC returning us multiple ResultSets.

To account for this (for the first 2 anyway) JPA allows defining multiple
ResultSetMapping references for the StoredProcesdureQuery.  Alternatively,
it allows specifying multiple "result classes".  However, JPA is silently
on how a provider is to treat these.  Specifically, are these  "aggregated"
into a single "row reader"?  Or do they represent individual row readers
specific to each expected ResultSet?  In other words, are the ResultSets
heterogeneous or homogeneous?

At the moment, Hibernate treats these by building a single aggregated row
reader that it applies to reading all ResultSets.  Like I said, JPA is
silent on what this "means" (and the TCK does not test it) so we are free
to interpret this as we see fit.

In retrospect I think the multiple ResultSetMappping case is probably best
interpreted using the "distinct row reader per ResultSet" approach.  I'm
not so convinced that is always the best interpretation of the multiple
result classes case.  But I also think these should probably be handled
consistently.

So what is everybody's preference here?  Which interpretation do we pick?
Worth it to make this configurable (per-SF + per-Query)?

From steve at hibernate.org  Wed May 23 13:55:19 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 23 May 2018 12:55:19 -0500
Subject: [hibernate-dev] 6.0 Design Doc
Message-ID: <CAFdSV9v9L_k+RyeiL5YATgTcAvZ=-3AvOX2r=+n_X=q7LiXgDQ@mail.gmail.com>

Andrea and I have spent some time getting the SQL execution design doc
up-to-date.  Would be nice to get any feedback.  Thanks :)

https://github.com/sebersole/hibernate-core/blob/wip/6.0-merge/sql-engine-design.adoc

From sanne at hibernate.org  Wed May 23 18:10:27 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 23 May 2018 23:10:27 +0100
Subject: [hibernate-dev] Preparing the 5.3.1 release
Message-ID: <CAFm4XO1jSOGDSmky-Jmb74J-ZoRd=XoSCAPSgOA7tnyx2QaT+w@mail.gmail.com>

Hi Steve,

are we free to release a 5.3.1 this weekend?

As I mentioned in the parallel thread "WildFly 14 requirements for
Hibernate libraries", we can still get some fixes for WildFly 13 but
the deadline is this weekend.

I think you and Andrea can keep the focus on the ORM6 meeting;
everyone else chipped in some fixes already.

Thanks,
Sanne

From steve at hibernate.org  Wed May 23 18:20:46 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 23 May 2018 17:20:46 -0500
Subject: [hibernate-dev] Preparing the 5.3.1 release
In-Reply-To: <CAFm4XO1jSOGDSmky-Jmb74J-ZoRd=XoSCAPSgOA7tnyx2QaT+w@mail.gmail.com>
References: <CAFm4XO1jSOGDSmky-Jmb74J-ZoRd=XoSCAPSgOA7tnyx2QaT+w@mail.gmail.com>
Message-ID: <CAFdSV9taSsRP8kvBp50+Zns95QTsi7h41OVjFQrbwYEud168oQ@mail.gmail.com>

If someone can do the release, +1 from me

On Wed, May 23, 2018 at 5:11 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Steve,
>
> are we free to release a 5.3.1 this weekend?
>
> As I mentioned in the parallel thread "WildFly 14 requirements for
> Hibernate libraries", we can still get some fixes for WildFly 13 but
> the deadline is this weekend.
>
> I think you and Andrea can keep the focus on the ORM6 meeting;
> everyone else chipped in some fixes already.
>
> Thanks,
> Sanne
>

From sanne at hibernate.org  Wed May 23 18:25:36 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 23 May 2018 23:25:36 +0100
Subject: [hibernate-dev] Preparing the 5.3.1 release
In-Reply-To: <CAFdSV9taSsRP8kvBp50+Zns95QTsi7h41OVjFQrbwYEud168oQ@mail.gmail.com>
References: <CAFm4XO1jSOGDSmky-Jmb74J-ZoRd=XoSCAPSgOA7tnyx2QaT+w@mail.gmail.com>
	<CAFdSV9taSsRP8kvBp50+Zns95QTsi7h41OVjFQrbwYEud168oQ@mail.gmail.com>
Message-ID: <CAFm4XO2e6vR_J12JAcuU1EYFxWBi-QpRoWX6CzV0cfKXxfar1w@mail.gmail.com>

we'll draft a "volunteer" :)

Thanks!

On 23 May 2018 at 23:20, Steve Ebersole <steve at hibernate.org> wrote:
> If someone can do the release, +1 from me
>
> On Wed, May 23, 2018 at 5:11 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi Steve,
>>
>> are we free to release a 5.3.1 this weekend?
>>
>> As I mentioned in the parallel thread "WildFly 14 requirements for
>> Hibernate libraries", we can still get some fixes for WildFly 13 but
>> the deadline is this weekend.
>>
>> I think you and Andrea can keep the focus on the ORM6 meeting;
>> everyone else chipped in some fixes already.
>>
>> Thanks,
>> Sanne

From crancran at gmail.com  Wed May 23 18:36:49 2018
From: crancran at gmail.com (Chris Cranford)
Date: Wed, 23 May 2018 18:36:49 -0400
Subject: [hibernate-dev] Preparing the 5.3.1 release
In-Reply-To: <CAFm4XO2e6vR_J12JAcuU1EYFxWBi-QpRoWX6CzV0cfKXxfar1w@mail.gmail.com>
References: <CAFm4XO1jSOGDSmky-Jmb74J-ZoRd=XoSCAPSgOA7tnyx2QaT+w@mail.gmail.com>
	<CAFdSV9taSsRP8kvBp50+Zns95QTsi7h41OVjFQrbwYEud168oQ@mail.gmail.com>
	<CAFm4XO2e6vR_J12JAcuU1EYFxWBi-QpRoWX6CzV0cfKXxfar1w@mail.gmail.com>
Message-ID: <eee6ead9-067b-71ea-4c0c-77375d92e35f@gmail.com>

I already mentioned to Sanne I'd handle it.?

I might run into some publishing issues and might need to recruit some
help as needed since it'll be my first attempt, but we'll see.

Chris

On 05/23/2018 06:25 PM, Sanne Grinovero wrote:
> we'll draft a "volunteer" :)
>
> Thanks!
>
> On 23 May 2018 at 23:20, Steve Ebersole <steve at hibernate.org> wrote:
>> If someone can do the release, +1 from me
>>
>> On Wed, May 23, 2018 at 5:11 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>> Hi Steve,
>>>
>>> are we free to release a 5.3.1 this weekend?
>>>
>>> As I mentioned in the parallel thread "WildFly 14 requirements for
>>> Hibernate libraries", we can still get some fixes for WildFly 13 but
>>> the deadline is this weekend.
>>>
>>> I think you and Andrea can keep the focus on the ORM6 meeting;
>>> everyone else chipped in some fixes already.
>>>
>>> Thanks,
>>> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Wed May 23 20:26:11 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 23 May 2018 19:26:11 -0500
Subject: [hibernate-dev] Preparing the 5.3.1 release
In-Reply-To: <eee6ead9-067b-71ea-4c0c-77375d92e35f@gmail.com>
References: <CAFm4XO1jSOGDSmky-Jmb74J-ZoRd=XoSCAPSgOA7tnyx2QaT+w@mail.gmail.com>
	<CAFdSV9taSsRP8kvBp50+Zns95QTsi7h41OVjFQrbwYEud168oQ@mail.gmail.com>
	<CAFm4XO2e6vR_J12JAcuU1EYFxWBi-QpRoWX6CzV0cfKXxfar1w@mail.gmail.com>
	<eee6ead9-067b-71ea-4c0c-77375d92e35f@gmail.com>
Message-ID: <CAFdSV9u_U3M=rw8MjxWOXaEyXbYu=p6jP6dovszHcUYuwu9vvg@mail.gmail.com>

Currently Bintray is not automatically publishing to Central.  I'm not sure
why yet. But it's easy to manually sync after.

I can walk you through that if you need.

Other than that, it usually goes pretty smoothly


On Wed, May 23, 2018, 5:37 PM Chris Cranford <crancran at gmail.com> wrote:

> I already mentioned to Sanne I'd handle it.
>
> I might run into some publishing issues and might need to recruit some
> help as needed since it'll be my first attempt, but we'll see.
>
> Chris
>
> On 05/23/2018 06:25 PM, Sanne Grinovero wrote:
>
> we'll draft a "volunteer" :)
>
> Thanks!
>
> On 23 May 2018 at 23:20, Steve Ebersole <steve at hibernate.org> <steve at hibernate.org> wrote:
>
> If someone can do the release, +1 from me
>
> On Wed, May 23, 2018 at 5:11 PM Sanne Grinovero <sanne at hibernate.org> <sanne at hibernate.org> wrote:
>
> Hi Steve,
>
> are we free to release a 5.3.1 this weekend?
>
> As I mentioned in the parallel thread "WildFly 14 requirements for
> Hibernate libraries", we can still get some fixes for WildFly 13 but
> the deadline is this weekend.
>
> I think you and Andrea can keep the focus on the ORM6 meeting;
> everyone else chipped in some fixes already.
>
> Thanks,
> Sanne
>
> _______________________________________________
> hibernate-dev mailing listhibernate-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>

From fercoli at redhat.com  Fri May 25 06:36:11 2018
From: fercoli at redhat.com (Fabio Massimo Ercoli)
Date: Fri, 25 May 2018 12:36:11 +0200
Subject: [hibernate-dev] HIbernate OGM 5.4.0.Beta1 is out
Message-ID: <CAFiQRE_pfUWVH3bkfrDfmUyc9bNCOU9t9poBfDC_MYxh5_WWdw@mail.gmail.com>

HIbernate OGM 5.4.0.Beta1 is ready!

Some improvement was the version upgrade for Hibernate ORM 5.3.0.Final and
Hibernate Search (5.10.0.Final),
the support for Infinispan Remote native and JPQL queries (without
requiring Hibernate Search)
and the use of cluster counters for local caches when generating sequences
with Infinispan Embedded.

All the details in the blog post:
*http://in.relation.to/2018/05/25/hibernate-ogm-5-4-Beta1-released/
<http://in.relation.to/2018/05/25/hibernate-ogm-5-4-Beta1-released/>*

Thanks, ?Fabio

-- 

FABIO MASSIMO ERCOLI

HIBERNATE TEAM

fabio.ercoli at redhat.com   fabio at hibernate.org
<https://red.ht/sig>

From steve at hibernate.org  Fri May 25 08:59:13 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 25 May 2018 07:59:13 -0500
Subject: [hibernate-dev] Multiple ResultSets from JDBC execution
In-Reply-To: <CA+gWKMD-jQxGrKrCYAXxvVUS-P=yohtSKrNk1bU5cxyMrqc95Q@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>
Message-ID: <CAFdSV9tvoWoM1nwSqzrvFVu=QM3eQD7qmx_U2p7jwBB44iX9vQ@mail.gmail.com>

Great that was actually my thought as well.

Anyone else?


On Fri, May 25, 2018, 12:03 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I think that by default we should not assume the result sets are the same.
>
> Only if we provide a certain QueryHint (JPA) or call a specific method
> (Hibernate API) should we instruct Hibernate to process all ResultSets, in
> the same way, using a single ResultSetMapping.
>
> Vlad
>
>
>
> On Fri, May 25, 2018 at 12:15 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I'm not saying to have a single result over all of the result
>> types/mappings.  I am questioning whether the proper interpretation is to
>> uniformly process all result sets (assuming all result sets have same
>> columns and domain results) versus one per ResultSet.
>>
>> E.g, let's say we have a ProcedureCall that returns 2 ResultSets that
>> each should return some scalar value, lets say an Integer... Would this
>> require passing 2 result set mappings (the same one twice), one per
>> ResultSet.  Or should use be able to just pass one mapping and have us
>> apply that one to each ResultSet?
>>
>> I think there are cases where both might make sense.
>>
>>
>>
>> On Thu, May 24, 2018, 2:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> I this Hibernate forum discussion is on the same topic:
>>>
>>>
>>> https://discourse.hibernate.org/t/oracle-stored-procedure-with-multiple-out-ref-cursors/782
>>>
>>> So, if we have multiple REF_CURSOR sent back from a stored procedure,
>>> should we allow getResultList to be called multiple times, right?
>>>
>>> I don't think we should aggregate those to a single List<Object []> and
>>> allow a single getResultList call.
>>>
>>> Vlad
>>>
>>> On Wed, 23 May 2018, 15:52 Steve Ebersole, <steve at hibernate.org> wrote:
>>>
>>>> Execution of procedure calls, function calls and anonymous blocks can
>>>> all
>>>> lead to JDBC returning us multiple ResultSets.
>>>>
>>>> To account for this (for the first 2 anyway) JPA allows defining
>>>> multiple
>>>> ResultSetMapping references for the StoredProcesdureQuery.
>>>> Alternatively,
>>>> it allows specifying multiple "result classes".  However, JPA is
>>>> silently
>>>> on how a provider is to treat these.  Specifically, are these
>>>> "aggregated"
>>>> into a single "row reader"?  Or do they represent individual row readers
>>>> specific to each expected ResultSet?  In other words, are the ResultSets
>>>> heterogeneous or homogeneous?
>>>>
>>>> At the moment, Hibernate treats these by building a single aggregated
>>>> row
>>>> reader that it applies to reading all ResultSets.  Like I said, JPA is
>>>> silent on what this "means" (and the TCK does not test it) so we are
>>>> free
>>>> to interpret this as we see fit.
>>>>
>>>> In retrospect I think the multiple ResultSetMappping case is probably
>>>> best
>>>> interpreted using the "distinct row reader per ResultSet" approach.  I'm
>>>> not so convinced that is always the best interpretation of the multiple
>>>> result classes case.  But I also think these should probably be handled
>>>> consistently.
>>>>
>>>> So what is everybody's preference here?  Which interpretation do we
>>>> pick?
>>>> Worth it to make this configurable (per-SF + per-Query)?
>>>>
>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>

From smarlow at redhat.com  Fri May 25 10:26:21 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 25 May 2018 10:26:21 -0400
Subject: [hibernate-dev] Is bytecode enhancement enabled by default in
 5.3?
In-Reply-To: <CAFdSV9viwYX9uDKzq0U2VKpfV4VOt5M7fDp9jYdhcURLKbGzpQ@mail.gmail.com>
References: <CAFDzhiRmiKcbWn=HVuMG+CQSMJ_kR8GRH76Tzueqq3c2TTj_vg@mail.gmail.com>
	<850f8263-c48e-0a4c-c634-d6cd8da59f29@redhat.com>
	<CAFm4XO2iYqR_32UeJW=3_hoa4wgHF2zRCXs0fG2w+Uhcadjdng@mail.gmail.com>
	<CAJtdNN4YqSc47v4MjTV8tfRKEyqs6QtOJC9Vo9aeN7G-b8sPwA@mail.gmail.com>
	<CAFm4XO1uLygeGPjKqC+LVVLoLO+JquL3rKhH0RSy=eohFrxcNg@mail.gmail.com>
	<ce338acb-90bf-e2cf-4fd0-b2c90b17cbd7@redhat.com>
	<CAFdSV9viwYX9uDKzq0U2VKpfV4VOt5M7fDp9jYdhcURLKbGzpQ@mail.gmail.com>
Message-ID: <b70ce23f-fd7c-b123-e7b0-c472f16fd9f0@redhat.com>



On 05/23/2018 09:17 AM, Steve Ebersole wrote:
> I never understood this `DataSourceDefinitions` part.? Why can't they 
> just be discovered via jipijapa prior to doing anything with Hibernate/JPA?

The @DataSourceDefinition DataSource that ORM needs, doesn't start until 
after application classes are loaded/defined.

> 
> See inline...
> 
>     Steve Ebersole and I have talked about adding additional phases to the
>     PU bootstrap, but that was so long ago, I forget if it was about
>     registering the ORM class transformer [1] earlier.? If ORM 5.3 or 6.0,
>     is depending on [1] to work correctly in order to implement the ORM
>     features, we need to take some action.
> 
> 
> So the rub right now (up through and including) 5.3 is that we sometimes 
> load domain model Class references during this "first bootstrap phase".  
> What really needs to happen is for Hibernate to unequivocally delay 
> loading domain model Class references until after this phase is over - 
> at least delay loading them into the "real" ClassLoader, we can use the 
> JPA temp ClassLoader if it is available.
> 
> 6.0 will delay loading these Class references even more so than today.  
> However, even with 6.0 we cannot fully guarantee that we will never load 
> them during this 1st phase.? That is a design goal for 7.0 and the move 
> to Jandex.
> 
>     In the past, I recall someone mentioning that lazy loading or dirty
>     flag
>     handling, would depend on bytecode enhancing.? If that happened or will
>     happen, we should discuss what the fallback solution is for when
>     bytecode enhancing is not working.
> 
> 
> Bytecode enhancement is not needed for either of these - Hibernate can 
> (and has forever) supported these without enhancement.? That will 
> continue to be the case.? Bytecode enhancement is simply an alternative 
> means for adding these features.

This is good news, so applications will still work correctly.

> 
> However, certain features such as automatic bi-dir association 
> management does require enhancement to work.

Should we document that applications with entity classes using bi-dir 
association, also depend on enhancement working?  And also mention why 
run-time enhancement might not work and perhaps mention build-time 
enhancement as a workaround to run-time enhancement not working?

> 
>     Another subject, is how should a user find out that bytecode enhancing
>     is actually updating application entity classes.? Should that operation
>     have trace logging and should that be at the WF or ORM level?
> 
> 
> Well based on what you described it sounds to me like there ought to be 
> at least 2 different log events here:
> 
>  1. The transformer is registered (this could be either WF or Hibernate
>     or both)
>  2. The transformer calls the Enhancer

https://issues.jboss.org/browse/WFLY-10456 is for #1 + #2.

>  3. (?) Enhancer enhances a class.? Enhancer is an interface though and
>     this would rely on the impls (Javassist and Byte Buddy) to do this.
> 

+10 for ORM to also log #2 + #3. :)

Scott

From smarlow at redhat.com  Fri May 25 11:24:56 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 25 May 2018 11:24:56 -0400
Subject: [hibernate-dev] Multiple ResultSets from JDBC execution
In-Reply-To: <CAFdSV9tvoWoM1nwSqzrvFVu=QM3eQD7qmx_U2p7jwBB44iX9vQ@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>
Message-ID: <CAJtdNN4oxE3kxjB4GD1RX_0q4=1Gk_qB5C38xCzTL6HrAwfgLA@mail.gmail.com>

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

From chris at hibernate.org  Fri May 25 12:08:39 2018
From: chris at hibernate.org (Chris Cranford)
Date: Fri, 25 May 2018 12:08:39 -0400
Subject: [hibernate-dev] 6.0 Design Doc
In-Reply-To: <CAFdSV9v9L_k+RyeiL5YATgTcAvZ=-3AvOX2r=+n_X=q7LiXgDQ@mail.gmail.com>
References: <CAFdSV9v9L_k+RyeiL5YATgTcAvZ=-3AvOX2r=+n_X=q7LiXgDQ@mail.gmail.com>
Message-ID: <a914e750-80dc-d925-2802-cf1c8884738c@hibernate.org>

In case anyone tries to locate this file more recently, its now under:
https://github.com/sebersole/hibernate-core/blob/wip/6.0-merge/design/sql-engine.adoc

On 05/23/2018 01:55 PM, Steve Ebersole wrote:
> Andrea and I have spent some time getting the SQL execution design doc
> up-to-date.  Would be nice to get any feedback.  Thanks :)
>
> https://github.com/sebersole/hibernate-core/blob/wip/6.0-merge/sql-engine-design.adoc
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From chris at hibernate.org  Fri May 25 17:22:50 2018
From: chris at hibernate.org (Chris Cranford)
Date: Fri, 25 May 2018 17:22:50 -0400
Subject: [hibernate-dev] Starting 5.3.1 release
Message-ID: <89e346b1-ef3a-a115-a30d-4162f9c2d35f@hibernate.org>

Please do not push anything to master branch.
Thanks,
Chris

From steve at hibernate.org  Fri May 25 18:35:15 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 25 May 2018 17:35:15 -0500
Subject: [hibernate-dev] 6.0 Design Doc
In-Reply-To: <a914e750-80dc-d925-2802-cf1c8884738c@hibernate.org>
References: <CAFdSV9v9L_k+RyeiL5YATgTcAvZ=-3AvOX2r=+n_X=q7LiXgDQ@mail.gmail.com>
	<a914e750-80dc-d925-2802-cf1c8884738c@hibernate.org>
Message-ID: <CAFdSV9s-kOAO-Fd3AgCk4MGJqYHYbgE-emBHQgzuy-P3t8qeRw@mail.gmail.com>

Funny timing :P

https://github.com/sebersole/hibernate-core/blob/wip/6.0/design/sql-engine.adoc

We integrated that branch into wip/6.0.  6.0 is successfully building now :
https://travis-ci.org/sebersole/hibernate-core/builds/383918214

:)

On Fri, May 25, 2018 at 11:18 AM Chris Cranford <chris at hibernate.org> wrote:

> In case anyone tries to locate this file more recently, its now under:
>
> https://github.com/sebersole/hibernate-core/blob/wip/6.0-merge/design/sql-engine.adoc
>
> On 05/23/2018 01:55 PM, Steve Ebersole wrote:
> > Andrea and I have spent some time getting the SQL execution design doc
> > up-to-date.  Would be nice to get any feedback.  Thanks :)
> >
> >
> https://github.com/sebersole/hibernate-core/blob/wip/6.0-merge/sql-engine-design.adoc
> > _______________________________________________
> > 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  Sat May 26 09:04:44 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 26 May 2018 14:04:44 +0100
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
Message-ID: <CAFm4XO0ZL3b4AG6Te+sFPjEJCwe_oBUVbbPxLhOVQoNtjyyKBw@mail.gmail.com>

Hi Scott,

I see you changed JBossStandAloneJtaPlatform to use a new API in WildFly;

this breaks all existing applications using a generic "JBoss -
standalone" platform which isn't using the very latest WildFly.

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

So two questions:
 - could this be reverted and you introduce some new-gen
WildflyStandAloneJtaPlatform instead?
 - bootstrap exceptions: may I change those to error level?

Thanks,
Sanne

From smarlow at redhat.com  Sat May 26 17:05:14 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Sat, 26 May 2018 17:05:14 -0400
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <CAFm4XO0ZL3b4AG6Te+sFPjEJCwe_oBUVbbPxLhOVQoNtjyyKBw@mail.gmail.com>
References: <CAFm4XO0ZL3b4AG6Te+sFPjEJCwe_oBUVbbPxLhOVQoNtjyyKBw@mail.gmail.com>
Message-ID: <CAJtdNN6vg+-wRDLxj06WgFHeZPMMZU+C7FkTiAzVdT+XVaJhbQ@mail.gmail.com>

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).
>
> So two questions:
>  - could this be reverted and you introduce some new-gen
> WildflyStandAloneJtaPlatform instead?
>

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
>

From smarlow at redhat.com  Sat May 26 18:05:12 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Sat, 26 May 2018 18:05:12 -0400
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <CAJtdNN6vg+-wRDLxj06WgFHeZPMMZU+C7FkTiAzVdT+XVaJhbQ@mail.gmail.com>
References: <CAFm4XO0ZL3b4AG6Te+sFPjEJCwe_oBUVbbPxLhOVQoNtjyyKBw@mail.gmail.com>
	<CAJtdNN6vg+-wRDLxj06WgFHeZPMMZU+C7FkTiAzVdT+XVaJhbQ@mail.gmail.com>
Message-ID: <CAJtdNN7R1N0zXgRjLYK54fhFjGcAAPycjLEesHdwZ7r3qt-n_w@mail.gmail.com>

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.

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).
>>
>> So two questions:
>>  - could this be reverted and you introduce some new-gen
>> WildflyStandAloneJtaPlatform instead?
>>
>
> 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
>>
>
>

From smarlow at redhat.com  Sat May 26 19:12:00 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Sat, 26 May 2018 19:12:00 -0400
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <CAJtdNN7R1N0zXgRjLYK54fhFjGcAAPycjLEesHdwZ7r3qt-n_w@mail.gmail.com>
References: <CAFm4XO0ZL3b4AG6Te+sFPjEJCwe_oBUVbbPxLhOVQoNtjyyKBw@mail.gmail.com>
	<CAJtdNN6vg+-wRDLxj06WgFHeZPMMZU+C7FkTiAzVdT+XVaJhbQ@mail.gmail.com>
	<CAJtdNN7R1N0zXgRjLYK54fhFjGcAAPycjLEesHdwZ7r3qt-n_w@mail.gmail.com>
Message-ID: <CAJtdNN4W_xR+Zxw02wrTOexYo2L7==8NiQ8ptNMWYv_xLWM62Q@mail.gmail.com>

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).
>>>
>>> So two questions:
>>>  - could this be reverted and you introduce some new-gen
>>> WildflyStandAloneJtaPlatform instead?
>>>
>>
>> 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
>>>
>>
>>
>

From smarlow at redhat.com  Sat May 26 19:30:30 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Sat, 26 May 2018 19:30:30 -0400
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <CAJtdNN4W_xR+Zxw02wrTOexYo2L7==8NiQ8ptNMWYv_xLWM62Q@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>
Message-ID: <CAJtdNN5PRhcfWCApfMEy439EXO4=bDpivqhNEb1ogi2=ivyFKw@mail.gmail.com>

Next idea, we should first look for the WFTC classes, if not found, then
look for Arjuna classes.

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).
>>>>
>>>> So two questions:
>>>>  - could this be reverted and you introduce some new-gen
>>>> WildflyStandAloneJtaPlatform instead?
>>>>
>>>
>>> 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
>>>>
>>>
>>>
>>

From sanne at hibernate.org  Sun May 27 08:17:22 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 27 May 2018 13:17:22 +0100
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <CAJtdNN5PRhcfWCApfMEy439EXO4=bDpivqhNEb1ogi2=ivyFKw@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>
Message-ID: <CAFm4XO2H8cVBfNO4EHmkoLDBD+qAwSE4qLr0hJNV+aR3S11XqQ@mail.gmail.com>

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

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).
>>>>>
>>>>> So two questions:
>>>>>  - could this be reverted and you introduce some new-gen
>>>>> WildflyStandAloneJtaPlatform instead?
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>
>

From smarlow at redhat.com  Sun May 27 10:29:56 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Sun, 27 May 2018 10:29:56 -0400
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <CAFm4XO2H8cVBfNO4EHmkoLDBD+qAwSE4qLr0hJNV+aR3S11XqQ@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>
Message-ID: <CAJtdNN71PpjLsNkrjNSOFOtpB1CGQ+DnP4aeE6UDcYrUWrEQJg@mail.gmail.com>

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.


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

From sanne at hibernate.org  Sun May 27 16:57:46 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 27 May 2018 21:57:46 +0100
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <CAJtdNN71PpjLsNkrjNSOFOtpB1CGQ+DnP4aeE6UDcYrUWrEQJg@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>
Message-ID: <CAFm4XO1pSwYxBRqNrWNi+USWPNX3LYjRrJ6jLgbhEKMmy=9joQ@mail.gmail.com>

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

From steve at hibernate.org  Sun May 27 19:05:45 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 27 May 2018 18:05:45 -0500
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <CAFm4XO1pSwYxBRqNrWNi+USWPNX3LYjRrJ6jLgbhEKMmy=9joQ@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>
Message-ID: <CAFdSV9swCEFY-zLqTEY2=D3+T7giXpOzYO2v6tPg7tWt63=ktw@mail.gmail.com>

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.


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 guillaume.smet at gmail.com  Mon May 28 06:40:17 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 28 May 2018 12:40:17 +0200
Subject: [hibernate-dev] AbstractStandardBasicType#getReplacement()
 prototype is incorrect since HHH-12054
Message-ID: <CALt0+o-mpRG8JKMj5ayanjn5YXco2NxhfEBFEH6Dx+uCvGbmuA@mail.gmail.com>

Hi,

When HHH-12054 was fixed (see
https://github.com/hibernate/hibernate-orm/pull/2042/files), we took into
account the fact that original and target could be set to
LazyPropertyInitializer.UNFETCHED_PROPERTY in the
AbstractStandardBasicType#getReplacement() method whereas we haven't
changed the prototype of the method.

Meaning we expect for instance LazyPropertyInitializer.UNFETCHED_PROPERTY
to be a T, which is not the case.

This led to ClassCastException such as in
https://hibernate.atlassian.net/browse/HHH-12555 . To be honest, I'm
wondering why we don't have more of them.

We have 2 ways of fixing this issue:
1- change the getReplacement() prototype to take Object parameters and
return an Object as the originating replace() method
2- move the LazyPropertyInitializer.UNFETCHED_PROPERTY logic up to
replace() and make getReplacement() a "I'm sure everything is OK, now get
me a clone of my original object" thing.

1- will obviously break compatibility with any user type extending
AbstractStandardBasicType#getReplacement(). 2- will slightly change the
meaning of replace() and getReplacement() and might lead to subtle behavior
changes in user applications.

2- also means that we would have to override both replace() and
getReplacement() in BlobType and allegates.

I pushed a commit for 1- at
https://github.com/gsmet/hibernate-orm/commit/73e66e40f3438794375451145af45214d7d1dc00
so that you can fully grasp the issue.

Not saying it's the path we should take.

Thoughts?

-- 
Guillaume

From sanne at hibernate.org  Mon May 28 07:23:57 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 28 May 2018 12:23:57 +0100
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <CAFdSV9swCEFY-zLqTEY2=D3+T7giXpOzYO2v6tPg7tWt63=ktw@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>
Message-ID: <CAFm4XO0Dpn7XP2X8wMMvksr41Tf-f=ZYGEdJwZVtaxN9Ahu7cQ@mail.gmail.com>

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.

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 chris at hibernate.org  Mon May 28 10:46:17 2018
From: chris at hibernate.org (Chris Cranford)
Date: Mon, 28 May 2018 10:46:17 -0400
Subject: [hibernate-dev] Hibernate ORM 5.3.1.Final has been released
Message-ID: <c013236a-53c5-3f89-6f38-2a336c7f3db6@hibernate.org>

For details:
http://in.relation.to/2018/05/28/hibernate-orm-531-final-release/

From smarlow at redhat.com  Mon May 28 13:32:03 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 28 May 2018 13:32:03 -0400
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <CAFdSV9swCEFY-zLqTEY2=D3+T7giXpOzYO2v6tPg7tWt63=ktw@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>
Message-ID: <CAJtdNN5K8U7cTUsf6rKa6J9op+++0h4WGdrgGgQ-Ug-mtCoagA@mail.gmail.com>

A fix is merged to orm master branch, which should be in 5.3.2, as soon as
that is available.

On Sun, May 27, 2018, 7:06 PM 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.


WildFly also supports non-jpa container managed deployments, that may not
want to use the JtaPlatformInitiator.  These apps can opt out of the
JtaPlatformInitiator but will need the correct TX status.

Inside WildFly, jipijapa ought to be defining that however it needs through
> a custom JtaPlatform and probably the JtaPlatformInitiator.
>
We do, by default.


>
> 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 rory.odonnell at oracle.com  Tue May 29 05:51:41 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 29 May 2018 10:51:41 +0100
Subject: [hibernate-dev] JDK 11 Early Access build 15 is available for
	download.
Message-ID: <d901e688-14cd-483c-a2cf-6ea6810e9f25@oracle.com>

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


From yoann at hibernate.org  Tue May 29 06:00:17 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 29 May 2018 12:00:17 +0200
Subject: [hibernate-dev] Hibernate Search 5.10.1.Final,
	5.9.2.Final and 5.6.5.Final released
Message-ID: <CAEqagppnCuFPfEX0zByzMV=BrfkX6uku_7U_gDfa2AZU=7usCA@mail.gmail.com>

Hello,

We just published bugfix releases for the branches we actively maintain:
5.10, 5.9 and 5.6.

Check out our blog for more information about these releases:

http://in.relation.to/2018/05/29/hibernate-search-5-10-1-Final-5-9-2-Final-5-6-5-Final/

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

From steve at hibernate.org  Tue May 29 08:48:30 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 29 May 2018 07:48:30 -0500
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <CAJtdNN5K8U7cTUsf6rKa6J9op+++0h4WGdrgGgQ-Ug-mtCoagA@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>
	<CAJtdNN5K8U7cTUsf6rKa6J9op+++0h4WGdrgGgQ-Ug-mtCoagA@mail.gmail.com>
Message-ID: <CAFdSV9szuRAN+7avD2gioq9LYrMuv28dxeenGmLutHWirX=egw@mail.gmail.com>

By "non-jpa container managed deployments" you mean injecting Hibernate
Sessions?  Otherwise, I am not sure what this is supposed to mean.  Nor why
it is a differentiator in how we use JtaPlatform / JtaPlatformInitiator.

On Mon, May 28, 2018 at 12:31 PM Scott Marlow <smarlow at redhat.com> wrote:

> A fix is merged to orm master branch, which should be in 5.3.2, as soon as
> that is available.
>
>
> On Sun, May 27, 2018, 7:06 PM 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.
>
>
> WildFly also supports non-jpa container managed deployments, that may not
> want to use the JtaPlatformInitiator.  These apps can opt out of the
> JtaPlatformInitiator but will need the correct TX status.
>
> Inside WildFly, jipijapa ought to be defining that however it needs
>> through a custom JtaPlatform and probably the JtaPlatformInitiator.
>>
> We do, by default.
>
>
>>
>> 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 smarlow at redhat.com  Tue May 29 09:38:42 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 29 May 2018 09:38:42 -0400
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
 compatibility
In-Reply-To: <CAFdSV9szuRAN+7avD2gioq9LYrMuv28dxeenGmLutHWirX=egw@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>
	<CAJtdNN5K8U7cTUsf6rKa6J9op+++0h4WGdrgGgQ-Ug-mtCoagA@mail.gmail.com>
	<CAFdSV9szuRAN+7avD2gioq9LYrMuv28dxeenGmLutHWirX=egw@mail.gmail.com>
Message-ID: <1ebd2687-f30c-15ca-9eca-cf079bc2b68e@redhat.com>


On 05/29/2018 08:48 AM, Steve Ebersole wrote:
> By "non-jpa container managed deployments" you mean injecting Hibernate 
> Sessions?? Otherwise, I am not sure what this is supposed to mean.? Nor 
> why it is a differentiator in how we use?JtaPlatform /?JtaPlatformInitiator.

Applications that deploy on WF, will use the WildFly 
JtaPlatformInitiator, unless they add a persistence unit hint 
"wildfly.jpa.jtaplatform" set to "false", in which case the WildFly 
JtaPlatformInitiator will not be added for the deployment.  We added 
this for allowing applications to have more control over which 
JtaPlatform is used (e.g. they can use an app configured JtaPlatform or 
the determined correct ORM JtaPlatform).

I do see that Hibernate ORM will always succeed to use the 
JBossAppServerJtaPlatform on WF, since we will only try using the 
JBossStandalone if the JNDI lookup of the WF TM fails.

What happens if the deployment, is configured to use 
JBossStandAloneJtaPlatform directly on WF?  I assume they will need to 
switch to use our new WildFlyStandAloneJtaPlatform class on ORM 5.3.2, 
so that the app sees correct JTA TX status?

There is also now the problem that in 5.3.1, JBossStandAloneJtaPlatform 
referred to the WildFly Transaction Client but is now reverted in 5.3.2, 
to only refer to the Arjuna classes.  Perhaps instead in 5.3.2, we 
should delete WildFlyStandAloneJtaPlatform and merge the logic into the 
existing JBossStandAloneJtaPlatform (so that we first check for WildFly 
Transaction Client classes, failing that, we then try the Arjuna classes.)

> 
> On Mon, May 28, 2018 at 12:31 PM Scott Marlow <smarlow at redhat.com 
> <mailto:smarlow at redhat.com>> wrote:
> 
>     A fix is merged to orm master branch, which should be in 5.3.2, as
>     soon as that is available.
> 
> 
>     On Sun, May 27, 2018, 7:06 PM Steve Ebersole <steve at hibernate.org
>     <mailto:steve at hibernate.org>> wrote:
> 
>         JBossStandalone is meant for use of JBoss Transactions outside
>         of WildFly.? Why are we using it inside WildFly. 
> 
> 
>     WildFly also supports non-jpa container managed deployments, that
>     may not want to use the JtaPlatformInitiator.? These apps can opt
>     out of the JtaPlatformInitiator but will need the correct TX status.
> 
>         Inside WildFly, jipijapa ought to be defining that however it
>         needs through a custom JtaPlatform and probably the
>         JtaPlatformInitiator.
> 
>     We do, by default.
> 
> 
> 
>         On Sun, May 27, 2018, 3:58 PM Sanne Grinovero
>         <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
> 
>             On 27 May 2018 at 15:29, Scott Marlow <smarlow at redhat.com
>             <mailto:smarlow at redhat.com>> wrote:
>              >
>              >
>              > On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero
>             <sanne at hibernate.org <mailto:sanne at hibernate.org>>
>              > wrote:
>              >>
>              >> On 27 May 2018 at 00:30, Scott Marlow
>             <smarlow at redhat.com <mailto: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 <mailto:smarlow at redhat.com>> wrote:
>              >> >>
>              >> >>
>              >> >>
>              >> >> On Sat, May 26, 2018, 6:05 PM Scott Marlow
>             <smarlow at redhat.com <mailto: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 <mailto:smarlow at redhat.com>>
>              >> >>> wrote:
>              >> >>>>
>              >> >>>>
>              >> >>>> On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero
>              >> >>>> <sanne at hibernate.org <mailto: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
>             <mailto:hibernate-dev at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From steve at hibernate.org  Tue May 29 10:05:56 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 29 May 2018 09:05:56 -0500
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <1ebd2687-f30c-15ca-9eca-cf079bc2b68e@redhat.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>
	<CAJtdNN5K8U7cTUsf6rKa6J9op+++0h4WGdrgGgQ-Ug-mtCoagA@mail.gmail.com>
	<CAFdSV9szuRAN+7avD2gioq9LYrMuv28dxeenGmLutHWirX=egw@mail.gmail.com>
	<1ebd2687-f30c-15ca-9eca-cf079bc2b68e@redhat.com>
Message-ID: <CAFdSV9ttQcL7aqjW5d6rR4PQ0bs-G5EjEFL6Tuu1JfU2swvTKA@mail.gmail.com>

On Tue, May 29, 2018 at 8:38 AM Scott Marlow <smarlow at redhat.com> wrote:

>
> On 05/29/2018 08:48 AM, Steve Ebersole wrote:
> > By "non-jpa container managed deployments" you mean injecting Hibernate
> > Sessions?  Otherwise, I am not sure what this is supposed to mean.  Nor
> > why it is a differentiator in how we use JtaPlatform
> / JtaPlatformInitiator.
>
> Applications that deploy on WF, will use the WildFly
> JtaPlatformInitiator, unless they add a persistence unit hint
> "wildfly.jpa.jtaplatform" set to "false", in which case the WildFly
> JtaPlatformInitiator will not be added for the deployment.  We added
> this for allowing applications to have more control over which
> JtaPlatform is used (e.g. they can use an app configured JtaPlatform or
> the determined correct ORM JtaPlatform).
>

Well that may be how your jipijapa works.  That's not how mine works.  I
really wish we would keep this code in sync, or if you could use
hibernate-jipijapa.  Maybe you mean against 5.1?

Anyway, in hibernate-jipijapa I simply extend the normal
`JtaPlatformInitiator` and override `#getFallbackProvider`.  The way that
should work is that it will prefer any value explicitly set by the user;
but, if they do not specify anything explicitly, I use the "fallback".  At
least that is how it should work - if it does not, I would consider that a
bug and we should fix it.

Or if you mean against 5.1 or an earlier version... the only difference is
the inclusion of the explicit `#getFallbackProvider` hook - you can still
effect the same change simply by fully implementing
`JtaPlatformInitiator#initiateService`


I do see that Hibernate ORM will always succeed to use the
> JBossAppServerJtaPlatform on WF, since we will only try using the
> JBossStandalone if the JNDI lookup of the WF TM fails.
>

Sure, because you are not telling it to do anything different with an
initiator.


What happens if the deployment, is configured to use
> JBossStandAloneJtaPlatform directly on WF?  I assume they will need to
> switch to use our new WildFlyStandAloneJtaPlatform class on ORM 5.3.2,
> so that the app sees correct JTA TX status?
>

Nope, on 5.3 hibernate-jipijapa simply works.  You have problems because
you are not following that paradigm.



> There is also now the problem that in 5.3.1, JBossStandAloneJtaPlatform
> referred to the WildFly Transaction Client but is now reverted in 5.3.2,
> to only refer to the Arjuna classes.  Perhaps instead in 5.3.2, we
> should delete WildFlyStandAloneJtaPlatform and merge the logic into the
> existing JBossStandAloneJtaPlatform (so that we first check for WildFly
> Transaction Client classes, failing that, we then try the Arjuna classes.)
>

I agree that this is a problem and should not have been changed.  At least
without looking.  IMO JBossStandAloneJtaPlatform ought to look for any of
the classes it can use.

From mihalcea.vlad at gmail.com  Tue May 29 10:59:04 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 29 May 2018 17:59:04 +0300
Subject: [hibernate-dev] Hibernate-orm-modules nmartifacts not publish
Message-ID: <CA+gWKMDzBnAjLE_VUxaT7YgO5sQCKLpyto6cvLSM-tDy4gHtuw@mail.gmail.com>

I checked this forum question:

https://discourse.hibernate.org/t/org-hibernate-hibernate-orm-modules-no-longer-published/861/2

And, indeed, the Hibernate-orm-modules artefacts are missing from Maven
Central.

Was this intentional or do we have a problem related to publishing them?

Vlad

From chris at hibernate.org  Tue May 29 11:21:38 2018
From: chris at hibernate.org (Chris Cranford)
Date: Tue, 29 May 2018 11:21:38 -0400
Subject: [hibernate-dev] Hibernate-orm-modules nmartifacts not publish
In-Reply-To: <CA+gWKMDzBnAjLE_VUxaT7YgO5sQCKLpyto6cvLSM-tDy4gHtuw@mail.gmail.com>
References: <CA+gWKMDzBnAjLE_VUxaT7YgO5sQCKLpyto6cvLSM-tDy4gHtuw@mail.gmail.com>
Message-ID: <21651f6a-6be6-8d00-b2b3-40714e98f6a5@hibernate.org>

I believe we renamed it to `hibernate-orm-jbossmodules` in 5.3.0.CR2 as
I see that with 5.3.1.Final too.

On 05/29/2018 10:59 AM, Vlad Mihalcea wrote:
> I checked this forum question:
>
> https://discourse.hibernate.org/t/org-hibernate-hibernate-orm-modules-no-longer-published/861/2
>
> And, indeed, the Hibernate-orm-modules artefacts are missing from Maven
> Central.
>
> Was this intentional or do we have a problem related to publishing them?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From mihalcea.vlad at gmail.com  Tue May 29 11:58:43 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 29 May 2018 18:58:43 +0300
Subject: [hibernate-dev] Hibernate-orm-modules nmartifacts not publish
In-Reply-To: <21651f6a-6be6-8d00-b2b3-40714e98f6a5@hibernate.org>
References: <CA+gWKMDzBnAjLE_VUxaT7YgO5sQCKLpyto6cvLSM-tDy4gHtuw@mail.gmail.com>
	<21651f6a-6be6-8d00-b2b3-40714e98f6a5@hibernate.org>
Message-ID: <CA+gWKMDopqNMMAJghfk903CddQTgbO9FakJR6Knz9eeC-MBDEQ@mail.gmail.com>

Thanks. I will have to look if we have some outdated docs pointing to the
old artefact.

On Tue, 29 May 2018, 18:21 Chris Cranford, <chris at hibernate.org> wrote:

> I believe we renamed it to `hibernate-orm-jbossmodules` in 5.3.0.CR2 as I
> see that with 5.3.1.Final too.
>
> On 05/29/2018 10:59 AM, Vlad Mihalcea wrote:
>
> I checked this forum question:
> https://discourse.hibernate.org/t/org-hibernate-hibernate-orm-modules-no-longer-published/861/2
>
> And, indeed, the Hibernate-orm-modules artefacts are missing from Maven
> Central.
>
> Was this intentional or do we have a problem related to publishing them?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing listhibernate-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>

From smarlow at redhat.com  Tue May 29 13:49:54 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 29 May 2018 13:49:54 -0400
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
 compatibility
In-Reply-To: <CAFdSV9ttQcL7aqjW5d6rR4PQ0bs-G5EjEFL6Tuu1JfU2swvTKA@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>
	<CAJtdNN5K8U7cTUsf6rKa6J9op+++0h4WGdrgGgQ-Ug-mtCoagA@mail.gmail.com>
	<CAFdSV9szuRAN+7avD2gioq9LYrMuv28dxeenGmLutHWirX=egw@mail.gmail.com>
	<1ebd2687-f30c-15ca-9eca-cf079bc2b68e@redhat.com>
	<CAFdSV9ttQcL7aqjW5d6rR4PQ0bs-G5EjEFL6Tuu1JfU2swvTKA@mail.gmail.com>
Message-ID: <6c479ee3-ed3e-900c-6565-41508f5d2900@redhat.com>



On 05/29/2018 10:05 AM, Steve Ebersole wrote:
> On Tue, May 29, 2018 at 8:38 AM Scott Marlow <smarlow at redhat.com 
> <mailto:smarlow at redhat.com>> wrote:
> 
> 
>     On 05/29/2018 08:48 AM, Steve Ebersole wrote:
>      > By "non-jpa container managed deployments" you mean injecting
>     Hibernate
>      > Sessions?? Otherwise, I am not sure what this is supposed to
>     mean.? Nor
>      > why it is a differentiator in how we use?JtaPlatform
>     /?JtaPlatformInitiator.
> 
>     Applications that deploy on WF, will use the WildFly
>     JtaPlatformInitiator, unless they add a persistence unit hint
>     "wildfly.jpa.jtaplatform" set to "false", in which case the WildFly
>     JtaPlatformInitiator will not be added for the deployment.? We added
>     this for allowing applications to have more control over which
>     JtaPlatform is used (e.g. they can use an app configured JtaPlatform or
>     the determined correct ORM JtaPlatform).
> 
> 
> Well that may be how your jipijapa works.? That's not how mine works.? I 
> really wish we would keep this code in sync, or if you could use 
> hibernate-jipijapa.? Maybe you mean against 5.1?

I think we both agreed that for now, we should maintain the jipijapa 
code in WF, with a fork being kept in ORM, for testing and other 
purposes (like making a new ORM version available to already shipped WF 
versions).

I agree that we should sync our copies of this code, just not sure of 
how, other than discussing a comparison and picking which changes should 
be merged to the other copy.

> 
> Anyway, in hibernate-jipijapa I simply extend the normal 
> `JtaPlatformInitiator` and override `#getFallbackProvider`.? The way 
> that should work is that it will prefer any value explicitly set by the 
> user; but, if they do not specify anything explicitly, I use the 
> "fallback".? At least that is how it should work - if it does not, I 
> would consider that a bug and we should fix it.

Interesting, should RegionFactoryInitiator also support automatic 
"fallback" to the user configured region factory?  I assume not since we 
are enabling the second level cache on Hibernate ORM but currently are 
not able to do that in WildFly (as the Infinispan cache needs to be made 
available first).

> 
> Or if you mean against 5.1 or an earlier version... the only difference 
> is the inclusion of the explicit `#getFallbackProvider` hook - you can 
> still effect the same change simply by fully implementing 
> `JtaPlatformInitiator#initiateService`
> 
> 
>     I do see that Hibernate ORM will always succeed to use the
>     JBossAppServerJtaPlatform on WF, since we will only try using the
>     JBossStandalone if the JNDI lookup of the WF TM fails.
> 
> 
> Sure, because you are not telling it to do anything different with an 
> initiator.
> 
> 
>     What happens if the deployment, is configured to use
>     JBossStandAloneJtaPlatform directly on WF?? I assume they will need to
>     switch to use our new WildFlyStandAloneJtaPlatform class on ORM 5.3.2,
>     so that the app sees correct JTA TX status?
> 
> 
> Nope, on 5.3 hibernate-jipijapa simply works.? You have problems because 
> you are not following that paradigm.
> 
>     There is also now the problem that in 5.3.1, JBossStandAloneJtaPlatform
>     referred to the WildFly Transaction Client but is now reverted in
>     5.3.2,
>     to only refer to the Arjuna classes.? Perhaps instead in 5.3.2, we
>     should delete WildFlyStandAloneJtaPlatform and merge the logic into the
>     existing JBossStandAloneJtaPlatform (so that we first check for WildFly
>     Transaction Client classes, failing that, we then try the Arjuna
>     classes.)
> 
> 
> I agree that this is a problem and should not have been changed.? At 
> least without looking.? IMO?JBossStandAloneJtaPlatform ought to look for 
> any of the classes it can use.

I reopened HHH-12640, so we can delete WildFlyStandAloneJtaPlatform and 
have JBossStandAloneJtaPlatform look for any of the classes it can use. 
https://github.com/hibernate/hibernate-orm/pull/2317 is the PR for this 
change.

From steve at hibernate.org  Tue May 29 17:07:14 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 29 May 2018 16:07:14 -0500
Subject: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards
	compatibility
In-Reply-To: <6c479ee3-ed3e-900c-6565-41508f5d2900@redhat.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>
	<CAJtdNN5K8U7cTUsf6rKa6J9op+++0h4WGdrgGgQ-Ug-mtCoagA@mail.gmail.com>
	<CAFdSV9szuRAN+7avD2gioq9LYrMuv28dxeenGmLutHWirX=egw@mail.gmail.com>
	<1ebd2687-f30c-15ca-9eca-cf079bc2b68e@redhat.com>
	<CAFdSV9ttQcL7aqjW5d6rR4PQ0bs-G5EjEFL6Tuu1JfU2swvTKA@mail.gmail.com>
	<6c479ee3-ed3e-900c-6565-41508f5d2900@redhat.com>
Message-ID: <CAFdSV9u+q0ctQeDRytrX9vc8GhCJOZW86po90Qgzo=GfpynsJQ@mail.gmail.com>

The implementation from hibernate-jipijapa returns disabling caching at all
if the user did not specify any value.  That was what you wanted to happen
per our discussion at that time.  Really I can make it do whatever you want
- just not sure of a better answer.

Also the point of a "fallback" is what happens when the user does not
explicitly specify.  That is what both the RegionFactoryInitiator and
JtaPlatformInitiator in hibernate-jipijapa do

On Tue, May 29, 2018 at 12:49 PM Scott Marlow <smarlow at redhat.com> wrote:

>
>
> On 05/29/2018 10:05 AM, Steve Ebersole wrote:
> > On Tue, May 29, 2018 at 8:38 AM Scott Marlow <smarlow at redhat.com
> > <mailto:smarlow at redhat.com>> wrote:
> >
> >
> >     On 05/29/2018 08:48 AM, Steve Ebersole wrote:
> >      > By "non-jpa container managed deployments" you mean injecting
> >     Hibernate
> >      > Sessions?  Otherwise, I am not sure what this is supposed to
> >     mean.  Nor
> >      > why it is a differentiator in how we use JtaPlatform
> >     / JtaPlatformInitiator.
> >
> >     Applications that deploy on WF, will use the WildFly
> >     JtaPlatformInitiator, unless they add a persistence unit hint
> >     "wildfly.jpa.jtaplatform" set to "false", in which case the WildFly
> >     JtaPlatformInitiator will not be added for the deployment.  We added
> >     this for allowing applications to have more control over which
> >     JtaPlatform is used (e.g. they can use an app configured JtaPlatform
> or
> >     the determined correct ORM JtaPlatform).
> >
> >
> > Well that may be how your jipijapa works.  That's not how mine works.  I
> > really wish we would keep this code in sync, or if you could use
> > hibernate-jipijapa.  Maybe you mean against 5.1?
>
> I think we both agreed that for now, we should maintain the jipijapa
> code in WF, with a fork being kept in ORM, for testing and other
> purposes (like making a new ORM version available to already shipped WF
> versions).
>
> I agree that we should sync our copies of this code, just not sure of
> how, other than discussing a comparison and picking which changes should
> be merged to the other copy.
>
> >
> > Anyway, in hibernate-jipijapa I simply extend the normal
> > `JtaPlatformInitiator` and override `#getFallbackProvider`.  The way
> > that should work is that it will prefer any value explicitly set by the
> > user; but, if they do not specify anything explicitly, I use the
> > "fallback".  At least that is how it should work - if it does not, I
> > would consider that a bug and we should fix it.
>
> Interesting, should RegionFactoryInitiator also support automatic
> "fallback" to the user configured region factory?  I assume not since we
> are enabling the second level cache on Hibernate ORM but currently are
> not able to do that in WildFly (as the Infinispan cache needs to be made
> available first).
>
> >
> > Or if you mean against 5.1 or an earlier version... the only difference
> > is the inclusion of the explicit `#getFallbackProvider` hook - you can
> > still effect the same change simply by fully implementing
> > `JtaPlatformInitiator#initiateService`
> >
> >
> >     I do see that Hibernate ORM will always succeed to use the
> >     JBossAppServerJtaPlatform on WF, since we will only try using the
> >     JBossStandalone if the JNDI lookup of the WF TM fails.
> >
> >
> > Sure, because you are not telling it to do anything different with an
> > initiator.
> >
> >
> >     What happens if the deployment, is configured to use
> >     JBossStandAloneJtaPlatform directly on WF?  I assume they will need
> to
> >     switch to use our new WildFlyStandAloneJtaPlatform class on ORM
> 5.3.2,
> >     so that the app sees correct JTA TX status?
> >
> >
> > Nope, on 5.3 hibernate-jipijapa simply works.  You have problems because
> > you are not following that paradigm.
> >
> >     There is also now the problem that in 5.3.1,
> JBossStandAloneJtaPlatform
> >     referred to the WildFly Transaction Client but is now reverted in
> >     5.3.2,
> >     to only refer to the Arjuna classes.  Perhaps instead in 5.3.2, we
> >     should delete WildFlyStandAloneJtaPlatform and merge the logic into
> the
> >     existing JBossStandAloneJtaPlatform (so that we first check for
> WildFly
> >     Transaction Client classes, failing that, we then try the Arjuna
> >     classes.)
> >
> >
> > I agree that this is a problem and should not have been changed.  At
> > least without looking.  IMO JBossStandAloneJtaPlatform ought to look for
> > any of the classes it can use.
>
> I reopened HHH-12640, so we can delete WildFlyStandAloneJtaPlatform and
> have JBossStandAloneJtaPlatform look for any of the classes it can use.
> https://github.com/hibernate/hibernate-orm/pull/2317 is the PR for this
> change.
>

From smarlow at redhat.com  Tue May 29 17:28:25 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 29 May 2018 17:28:25 -0400
Subject: [hibernate-dev] Is bytecode enhancement enabled by default in
	5.3?
In-Reply-To: <b70ce23f-fd7c-b123-e7b0-c472f16fd9f0@redhat.com>
References: <CAFDzhiRmiKcbWn=HVuMG+CQSMJ_kR8GRH76Tzueqq3c2TTj_vg@mail.gmail.com>
	<850f8263-c48e-0a4c-c634-d6cd8da59f29@redhat.com>
	<CAFm4XO2iYqR_32UeJW=3_hoa4wgHF2zRCXs0fG2w+Uhcadjdng@mail.gmail.com>
	<CAJtdNN4YqSc47v4MjTV8tfRKEyqs6QtOJC9Vo9aeN7G-b8sPwA@mail.gmail.com>
	<CAFm4XO1uLygeGPjKqC+LVVLoLO+JquL3rKhH0RSy=eohFrxcNg@mail.gmail.com>
	<ce338acb-90bf-e2cf-4fd0-b2c90b17cbd7@redhat.com>
	<CAFdSV9viwYX9uDKzq0U2VKpfV4VOt5M7fDp9jYdhcURLKbGzpQ@mail.gmail.com>
	<b70ce23f-fd7c-b123-e7b0-c472f16fd9f0@redhat.com>
Message-ID: <CAJtdNN6c2Vp0GAU1JUCXNy1yHxZOVM5tjEkK1L3sH+1WrAFdLw@mail.gmail.com>

>
> Well based on what you described it sounds to me like there ought to be at
>> least 2 different log events here:
>>
>>  1. The transformer is registered (this could be either WF or Hibernate
>>     or both)
>>  2. The transformer calls the Enhancer
>>
>
> https://issues.jboss.org/browse/WFLY-10456 is for #1 + #2.
>
>  3. (?) Enhancer enhances a class.  Enhancer is an interface though and
>>     this would rely on the impls (Javassist and Byte Buddy) to do this.
>>
>>
Created https://github.com/wildfly/wildfly/pull/11297 for the WF logging
change.

From gbadner at redhat.com  Wed May 30 02:32:31 2018
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 29 May 2018 23:32:31 -0700
Subject: [hibernate-dev] Unidirectional @OneToMany @JoinColumn associations
Message-ID: <CAFDzhiTmbx3HuTVHq=NY1WrUaj8V0PbdK40=EgR3AdDFQHCpiA@mail.gmail.com>

Unidirectional OneToMany associations using @JoinColumn that reference
columns that are not PK columns is not currently supported.

The JPA 2.1 documentation for @JoinTable says:

"Support for referenced columns that are not primary key columns of the
referenced table is optional. Applications that use such mappings will not
be portable."

I don't see anything in the user doc that explicitly states that Hibernate
does not support this.

Is this considered a bug?

Also, what about a unidirectional OneToMany using a @JoinColumn that
references some, but not all, of primary key columns? Hibernate does not
support that either. Should Hibernate support it since they are primary key
columns?

Thanks,
Gail

From mihalcea.vlad at gmail.com  Wed May 30 03:47:18 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 30 May 2018 10:47:18 +0300
Subject: [hibernate-dev] Unidirectional @OneToMany @JoinColumn
	associations
In-Reply-To: <CAFDzhiTmbx3HuTVHq=NY1WrUaj8V0PbdK40=EgR3AdDFQHCpiA@mail.gmail.com>
References: <CAFDzhiTmbx3HuTVHq=NY1WrUaj8V0PbdK40=EgR3AdDFQHCpiA@mail.gmail.com>
Message-ID: <CA+gWKMCu07NYGR84ZKGwDkJN6MOkZOrK-_wtEZfT2Vx68em64A@mail.gmail.com>

Hi,

For the OneToMany with @JoinColumn, the user can workaround this limitation
by just using the @ManyToOne on the child side on any column they want
and turning the unidirectional association into a bidirectional one. I
remember I tested it and it worked just fine.

For the  OneToMany with @JoinTable, the only workaround would be if they
map the join table as an entity and use the @ManyToOne on the columns they
want
the association to be based on.

Since unidirectional associations don't perform that well, I'm not sure
whether it's worth adding support for these use cases.

Vlad

On Wed, May 30, 2018 at 9:32 AM, Gail Badner <gbadner at redhat.com> wrote:

> Unidirectional OneToMany associations using @JoinColumn that reference
> columns that are not PK columns is not currently supported.
>
> The JPA 2.1 documentation for @JoinTable says:
>
> "Support for referenced columns that are not primary key columns of the
> referenced table is optional. Applications that use such mappings will not
> be portable."
>
> I don't see anything in the user doc that explicitly states that Hibernate
> does not support this.
>
> Is this considered a bug?
>
> Also, what about a unidirectional OneToMany using a @JoinColumn that
> references some, but not all, of primary key columns? Hibernate does not
> support that either. Should Hibernate support it since they are primary key
> columns?
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed May 30 10:27:55 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 30 May 2018 17:27:55 +0300
Subject: [hibernate-dev] Auto-registering the cacheable entities and
	collections
Message-ID: <CA+gWKMCKpnJLZ7E=jhmzHTXrmrHFsJSgT8LD4e3ug4v9GibXiQ@mail.gmail.com>

Hi,

While upgrading my Hibernate testing repository to 5.3, I realized that we
no longer auto-register the 2nd-level cache for entities and the
collections even if those are annotated with the Hibernate @Cache
annotation.

I noticed that the Hibernate tests have been modified and we require to
register those manually:

for ( Map.Entry<Class, String> entry : getCachedClasses().entrySet() ) {
config.put( AvailableSettings.CLASS_CACHE_PREFIX + "." +
entry.getKey().getName(), entry.getValue() );
}
for ( Map.Entry<String, String> entry : getCachedCollections().entrySet() )
{
config.put( AvailableSettings.COLLECTION_CACHE_PREFIX + "." +
entry.getKey(), entry.getValue() );
}

Now, if I don't do that, I get the following exception:

Caused by: org.hibernate.cache.CacheException: On-the-fly creation of
JCache Cache objects is not supported
[com.vladmihalcea.book.hpjp.hibernate.cache.query.QueryCacheTest$Post.comments]
at
org.hibernate.cache.ehcache.internal.EhcacheRegionFactory.createCache(EhcacheRegionFactory.java:106)
at
org.hibernate.cache.ehcache.internal.EhcacheRegionFactory.getOrCreateCache(EhcacheRegionFactory.java:100)
at
org.hibernate.cache.ehcache.internal.EhcacheRegionFactory.createDomainDataStorageAccess(EhcacheRegionFactory.java:71)
at
org.hibernate.cache.spi.support.RegionFactoryTemplate.buildDomainDataRegion(RegionFactoryTemplate.java:31)
at
org.hibernate.cache.internal.EnabledCaching.prime(EnabledCaching.java:108)
at
org.hibernate.metamodel.internal.MetamodelImpl.primeSecondLevelCacheRegions(MetamodelImpl.java:284)
at
org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:116)
at
org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:295)
at
org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:467)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:939)


However, I don't even use JCache. I use "ehcache" instead.

properties.put("hibernate.cache.region.factory_class", "ehcache");

Was a JCache requirement?

Can we auto-register the entities and collections for other cache providers?

I'm worried about all those applications trying to upgrade to 5.3. Imagine
if they have hundreds of entities and collections. People will surely start
complaining if we force them to do that manually during bootstrap. More,
I'm not sure how they can do when they just bootstrap via a JPA
persistence.xml configuration file.

Vlad

From steve at hibernate.org  Wed May 30 11:50:38 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 30 May 2018 10:50:38 -0500
Subject: [hibernate-dev] Auto-registering the cacheable entities and
	collections
In-Reply-To: <CA+gWKMCKpnJLZ7E=jhmzHTXrmrHFsJSgT8LD4e3ug4v9GibXiQ@mail.gmail.com>
References: <CA+gWKMCKpnJLZ7E=jhmzHTXrmrHFsJSgT8LD4e3ug4v9GibXiQ@mail.gmail.com>
Message-ID: <CAFdSV9vjV2YWFWL4aAQOH4pbPetsnmJd=BOoWR0fZ-iRVTwn0A@mail.gmail.com>

That is unintended, likely from the L2C service changes.  Yes we should
change that to match the old behavior.

On Wed, May 30, 2018 at 9:43 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> While upgrading my Hibernate testing repository to 5.3, I realized that we
> no longer auto-register the 2nd-level cache for entities and the
> collections even if those are annotated with the Hibernate @Cache
> annotation.
>
> I noticed that the Hibernate tests have been modified and we require to
> register those manually:
>
> for ( Map.Entry<Class, String> entry : getCachedClasses().entrySet() ) {
> config.put( AvailableSettings.CLASS_CACHE_PREFIX + "." +
> entry.getKey().getName(), entry.getValue() );
> }
> for ( Map.Entry<String, String> entry : getCachedCollections().entrySet() )
> {
> config.put( AvailableSettings.COLLECTION_CACHE_PREFIX + "." +
> entry.getKey(), entry.getValue() );
> }
>
> Now, if I don't do that, I get the following exception:
>
> Caused by: org.hibernate.cache.CacheException: On-the-fly creation of
> JCache Cache objects is not supported
>
> [com.vladmihalcea.book.hpjp.hibernate.cache.query.QueryCacheTest$Post.comments]
> at
>
> org.hibernate.cache.ehcache.internal.EhcacheRegionFactory.createCache(EhcacheRegionFactory.java:106)
> at
>
> org.hibernate.cache.ehcache.internal.EhcacheRegionFactory.getOrCreateCache(EhcacheRegionFactory.java:100)
> at
>
> org.hibernate.cache.ehcache.internal.EhcacheRegionFactory.createDomainDataStorageAccess(EhcacheRegionFactory.java:71)
> at
>
> org.hibernate.cache.spi.support.RegionFactoryTemplate.buildDomainDataRegion(RegionFactoryTemplate.java:31)
> at
> org.hibernate.cache.internal.EnabledCaching.prime(EnabledCaching.java:108)
> at
>
> org.hibernate.metamodel.internal.MetamodelImpl.primeSecondLevelCacheRegions(MetamodelImpl.java:284)
> at
>
> org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:116)
> at
>
> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:295)
> at
>
> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:467)
> at
>
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:939)
>
>
> However, I don't even use JCache. I use "ehcache" instead.
>
> properties.put("hibernate.cache.region.factory_class", "ehcache");
>
> Was a JCache requirement?
>
> Can we auto-register the entities and collections for other cache
> providers?
>
> I'm worried about all those applications trying to upgrade to 5.3. Imagine
> if they have hundreds of entities and collections. People will surely start
> complaining if we force them to do that manually during bootstrap. More,
> I'm not sure how they can do when they just bootstrap via a JPA
> persistence.xml configuration file.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Wed May 30 14:45:14 2018
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 30 May 2018 11:45:14 -0700
Subject: [hibernate-dev] Unidirectional @OneToMany @JoinColumn
	associations
In-Reply-To: <CA+gWKMCu07NYGR84ZKGwDkJN6MOkZOrK-_wtEZfT2Vx68em64A@mail.gmail.com>
References: <CAFDzhiTmbx3HuTVHq=NY1WrUaj8V0PbdK40=EgR3AdDFQHCpiA@mail.gmail.com>
	<CA+gWKMCu07NYGR84ZKGwDkJN6MOkZOrK-_wtEZfT2Vx68em64A@mail.gmail.com>
Message-ID: <CAFDzhiQHcSJ+cJpd-bGWA=PBeMFVAeHbR2oAWZ-B+jaJo=5HAQ@mail.gmail.com>

Hi Vlad,

Thanks for your answer. There are definitely better ways to model this
association.

WRT the second example, where the referenced columns are a subset of the PK
columns -- I understand there are better ways to model this.

In particular, since the subset of PK columns needs to be unique (since
they are the referenced columns of a @JoinColumn), there is no reason for
any other columns to be in the PK.

My question is more about what the JPA spec says about whether this should
be supported.

Regards,
Gail





On Wed, May 30, 2018 at 12:47 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> For the OneToMany with @JoinColumn, the user can workaround this
> limitation by just using the @ManyToOne on the child side on any column
> they want
> and turning the unidirectional association into a bidirectional one. I
> remember I tested it and it worked just fine.
>
> For the  OneToMany with @JoinTable, the only workaround would be if they
> map the join table as an entity and use the @ManyToOne on the columns they
> want
> the association to be based on.
>
> Since unidirectional associations don't perform that well, I'm not sure
> whether it's worth adding support for these use cases.
>
> Vlad
>
> On Wed, May 30, 2018 at 9:32 AM, Gail Badner <gbadner at redhat.com> wrote:
>
>> Unidirectional OneToMany associations using @JoinColumn that reference
>> columns that are not PK columns is not currently supported.
>>
>> The JPA 2.1 documentation for @JoinTable says:
>>
>> "Support for referenced columns that are not primary key columns of the
>> referenced table is optional. Applications that use such mappings will not
>> be portable."
>>
>> I don't see anything in the user doc that explicitly states that Hibernate
>> does not support this.
>>
>> Is this considered a bug?
>>
>> Also, what about a unidirectional OneToMany using a @JoinColumn that
>> references some, but not all, of primary key columns? Hibernate does not
>> support that either. Should Hibernate support it since they are primary
>> key
>> columns?
>>
>> Thanks,
>> Gail
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From sanne at hibernate.org  Wed May 30 16:39:21 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 30 May 2018 21:39:21 +0100
Subject: [hibernate-dev] Unidirectional @OneToMany @JoinColumn
	associations
In-Reply-To: <CAFDzhiQHcSJ+cJpd-bGWA=PBeMFVAeHbR2oAWZ-B+jaJo=5HAQ@mail.gmail.com>
References: <CAFDzhiTmbx3HuTVHq=NY1WrUaj8V0PbdK40=EgR3AdDFQHCpiA@mail.gmail.com>
	<CA+gWKMCu07NYGR84ZKGwDkJN6MOkZOrK-_wtEZfT2Vx68em64A@mail.gmail.com>
	<CAFDzhiQHcSJ+cJpd-bGWA=PBeMFVAeHbR2oAWZ-B+jaJo=5HAQ@mail.gmail.com>
Message-ID: <CAFm4XO2LvHi+sZ++SDZEHSU2ym3mBA8Q_oyptUxx2hz79ZQb+Q@mail.gmail.com>

Hi Gail,

I would not consider it a bug to not have documented that we don't
support some non-mandatory feature.

And it's still optional in JPA 2.2, so I think we're good.

Thanks,
Sanne



On 30 May 2018 at 19:45, Gail Badner <gbadner at redhat.com> wrote:
> Hi Vlad,
>
> Thanks for your answer. There are definitely better ways to model this
> association.
>
> WRT the second example, where the referenced columns are a subset of the PK
> columns -- I understand there are better ways to model this.
>
> In particular, since the subset of PK columns needs to be unique (since
> they are the referenced columns of a @JoinColumn), there is no reason for
> any other columns to be in the PK.
>
> My question is more about what the JPA spec says about whether this should
> be supported.
>
> Regards,
> Gail
>
>
>
>
>
> On Wed, May 30, 2018 at 12:47 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> For the OneToMany with @JoinColumn, the user can workaround this
>> limitation by just using the @ManyToOne on the child side on any column
>> they want
>> and turning the unidirectional association into a bidirectional one. I
>> remember I tested it and it worked just fine.
>>
>> For the  OneToMany with @JoinTable, the only workaround would be if they
>> map the join table as an entity and use the @ManyToOne on the columns they
>> want
>> the association to be based on.
>>
>> Since unidirectional associations don't perform that well, I'm not sure
>> whether it's worth adding support for these use cases.
>>
>> Vlad
>>
>> On Wed, May 30, 2018 at 9:32 AM, Gail Badner <gbadner at redhat.com> wrote:
>>
>>> Unidirectional OneToMany associations using @JoinColumn that reference
>>> columns that are not PK columns is not currently supported.
>>>
>>> The JPA 2.1 documentation for @JoinTable says:
>>>
>>> "Support for referenced columns that are not primary key columns of the
>>> referenced table is optional. Applications that use such mappings will not
>>> be portable."
>>>
>>> I don't see anything in the user doc that explicitly states that Hibernate
>>> does not support this.
>>>
>>> Is this considered a bug?
>>>
>>> Also, what about a unidirectional OneToMany using a @JoinColumn that
>>> references some, but not all, of primary key columns? Hibernate does not
>>> support that either. Should Hibernate support it since they are primary
>>> key
>>> columns?
>>>
>>> Thanks,
>>> Gail
>>> _______________________________________________
>>> 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 sfikes at redhat.com  Wed May 30 16:44:19 2018
From: sfikes at redhat.com (Stephen Fikes)
Date: Wed, 30 May 2018 15:44:19 -0500
Subject: [hibernate-dev] Unidirectional @OneToMany @JoinColumn
 associations
In-Reply-To: <CAFm4XO2LvHi+sZ++SDZEHSU2ym3mBA8Q_oyptUxx2hz79ZQb+Q@mail.gmail.com>
References: <CAFDzhiTmbx3HuTVHq=NY1WrUaj8V0PbdK40=EgR3AdDFQHCpiA@mail.gmail.com>
	<CA+gWKMCu07NYGR84ZKGwDkJN6MOkZOrK-_wtEZfT2Vx68em64A@mail.gmail.com>
	<CAFDzhiQHcSJ+cJpd-bGWA=PBeMFVAeHbR2oAWZ-B+jaJo=5HAQ@mail.gmail.com>
	<CAFm4XO2LvHi+sZ++SDZEHSU2ym3mBA8Q_oyptUxx2hz79ZQb+Q@mail.gmail.com>
Message-ID: <c5efc385-7efa-f0f0-7d59-1d4af7bb7792@redhat.com>

The referenced attributes *are* key attributes .. just a subset of the 
key. So ... odd mapping ... but I don't think it is included in the 
"optional" category for JPA 2.x.

Stephen


On 05/30/2018 03:39 PM, Sanne Grinovero wrote:
> Hi Gail,
>
> I would not consider it a bug to not have documented that we don't
> support some non-mandatory feature.
>
> And it's still optional in JPA 2.2, so I think we're good.
>
> Thanks,
> Sanne
>
>
>
> On 30 May 2018 at 19:45, Gail Badner <gbadner at redhat.com> wrote:
>> Hi Vlad,
>>
>> Thanks for your answer. There are definitely better ways to model this
>> association.
>>
>> WRT the second example, where the referenced columns are a subset of the PK
>> columns -- I understand there are better ways to model this.
>>
>> In particular, since the subset of PK columns needs to be unique (since
>> they are the referenced columns of a @JoinColumn), there is no reason for
>> any other columns to be in the PK.
>>
>> My question is more about what the JPA spec says about whether this should
>> be supported.
>>
>> Regards,
>> Gail
>>
>>
>>
>>
>>
>> On Wed, May 30, 2018 at 12:47 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> For the OneToMany with @JoinColumn, the user can workaround this
>>> limitation by just using the @ManyToOne on the child side on any column
>>> they want
>>> and turning the unidirectional association into a bidirectional one. I
>>> remember I tested it and it worked just fine.
>>>
>>> For the  OneToMany with @JoinTable, the only workaround would be if they
>>> map the join table as an entity and use the @ManyToOne on the columns they
>>> want
>>> the association to be based on.
>>>
>>> Since unidirectional associations don't perform that well, I'm not sure
>>> whether it's worth adding support for these use cases.
>>>
>>> Vlad
>>>
>>> On Wed, May 30, 2018 at 9:32 AM, Gail Badner <gbadner at redhat.com> wrote:
>>>
>>>> Unidirectional OneToMany associations using @JoinColumn that reference
>>>> columns that are not PK columns is not currently supported.
>>>>
>>>> The JPA 2.1 documentation for @JoinTable says:
>>>>
>>>> "Support for referenced columns that are not primary key columns of the
>>>> referenced table is optional. Applications that use such mappings will not
>>>> be portable."
>>>>
>>>> I don't see anything in the user doc that explicitly states that Hibernate
>>>> does not support this.
>>>>
>>>> Is this considered a bug?
>>>>
>>>> Also, what about a unidirectional OneToMany using a @JoinColumn that
>>>> references some, but not all, of primary key columns? Hibernate does not
>>>> support that either. Should Hibernate support it since they are primary
>>>> key
>>>> columns?
>>>>
>>>> Thanks,
>>>> Gail
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Wed May 30 16:47:47 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 30 May 2018 15:47:47 -0500
Subject: [hibernate-dev] Unidirectional @OneToMany @JoinColumn
	associations
In-Reply-To: <c5efc385-7efa-f0f0-7d59-1d4af7bb7792@redhat.com>
References: <CAFDzhiTmbx3HuTVHq=NY1WrUaj8V0PbdK40=EgR3AdDFQHCpiA@mail.gmail.com>
	<CA+gWKMCu07NYGR84ZKGwDkJN6MOkZOrK-_wtEZfT2Vx68em64A@mail.gmail.com>
	<CAFDzhiQHcSJ+cJpd-bGWA=PBeMFVAeHbR2oAWZ-B+jaJo=5HAQ@mail.gmail.com>
	<CAFm4XO2LvHi+sZ++SDZEHSU2ym3mBA8Q_oyptUxx2hz79ZQb+Q@mail.gmail.com>
	<c5efc385-7efa-f0f0-7d59-1d4af7bb7792@redhat.com>
Message-ID: <CAFdSV9sGFSx7XyW1vXFSb-O6euj7K46ThNC359TNjLz95LTO=A@mail.gmail.com>

The spec says ".... referenced columns that are not primary key
columns...".  Nothing in here says full or partial.

I completely agree with Sanne - its not a bug and it is something we have
never supported.

On Wed, May 30, 2018 at 3:44 PM Stephen Fikes <sfikes at redhat.com> wrote:

> The referenced attributes *are* key attributes .. just a subset of the
> key. So ... odd mapping ... but I don't think it is included in the
> "optional" category for JPA 2.x.
>
> Stephen
>
>
> On 05/30/2018 03:39 PM, Sanne Grinovero wrote:
> > Hi Gail,
> >
> > I would not consider it a bug to not have documented that we don't
> > support some non-mandatory feature.
> >
> > And it's still optional in JPA 2.2, so I think we're good.
> >
> > Thanks,
> > Sanne
> >
> >
> >
> > On 30 May 2018 at 19:45, Gail Badner <gbadner at redhat.com> wrote:
> >> Hi Vlad,
> >>
> >> Thanks for your answer. There are definitely better ways to model this
> >> association.
> >>
> >> WRT the second example, where the referenced columns are a subset of
> the PK
> >> columns -- I understand there are better ways to model this.
> >>
> >> In particular, since the subset of PK columns needs to be unique (since
> >> they are the referenced columns of a @JoinColumn), there is no reason
> for
> >> any other columns to be in the PK.
> >>
> >> My question is more about what the JPA spec says about whether this
> should
> >> be supported.
> >>
> >> Regards,
> >> Gail
> >>
> >>
> >>
> >>
> >>
> >> On Wed, May 30, 2018 at 12:47 AM, Vlad Mihalcea <
> mihalcea.vlad at gmail.com>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> For the OneToMany with @JoinColumn, the user can workaround this
> >>> limitation by just using the @ManyToOne on the child side on any column
> >>> they want
> >>> and turning the unidirectional association into a bidirectional one. I
> >>> remember I tested it and it worked just fine.
> >>>
> >>> For the  OneToMany with @JoinTable, the only workaround would be if
> they
> >>> map the join table as an entity and use the @ManyToOne on the columns
> they
> >>> want
> >>> the association to be based on.
> >>>
> >>> Since unidirectional associations don't perform that well, I'm not sure
> >>> whether it's worth adding support for these use cases.
> >>>
> >>> Vlad
> >>>
> >>> On Wed, May 30, 2018 at 9:32 AM, Gail Badner <gbadner at redhat.com>
> wrote:
> >>>
> >>>> Unidirectional OneToMany associations using @JoinColumn that reference
> >>>> columns that are not PK columns is not currently supported.
> >>>>
> >>>> The JPA 2.1 documentation for @JoinTable says:
> >>>>
> >>>> "Support for referenced columns that are not primary key columns of
> the
> >>>> referenced table is optional. Applications that use such mappings
> will not
> >>>> be portable."
> >>>>
> >>>> I don't see anything in the user doc that explicitly states that
> Hibernate
> >>>> does not support this.
> >>>>
> >>>> Is this considered a bug?
> >>>>
> >>>> Also, what about a unidirectional OneToMany using a @JoinColumn that
> >>>> references some, but not all, of primary key columns? Hibernate does
> not
> >>>> support that either. Should Hibernate support it since they are
> primary
> >>>> key
> >>>> columns?
> >>>>
> >>>> Thanks,
> >>>> Gail
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>
> >>>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sfikes at redhat.com  Thu May 31 09:54:47 2018
From: sfikes at redhat.com (Stephen Fikes)
Date: Thu, 31 May 2018 08:54:47 -0500
Subject: [hibernate-dev] Unidirectional @OneToMany @JoinColumn
 associations
In-Reply-To: <CAFdSV9sGFSx7XyW1vXFSb-O6euj7K46ThNC359TNjLz95LTO=A@mail.gmail.com>
References: <CAFDzhiTmbx3HuTVHq=NY1WrUaj8V0PbdK40=EgR3AdDFQHCpiA@mail.gmail.com>
	<CA+gWKMCu07NYGR84ZKGwDkJN6MOkZOrK-_wtEZfT2Vx68em64A@mail.gmail.com>
	<CAFDzhiQHcSJ+cJpd-bGWA=PBeMFVAeHbR2oAWZ-B+jaJo=5HAQ@mail.gmail.com>
	<CAFm4XO2LvHi+sZ++SDZEHSU2ym3mBA8Q_oyptUxx2hz79ZQb+Q@mail.gmail.com>
	<c5efc385-7efa-f0f0-7d59-1d4af7bb7792@redhat.com>
	<CAFdSV9sGFSx7XyW1vXFSb-O6euj7K46ThNC359TNjLz95LTO=A@mail.gmail.com>
Message-ID: <bb0ec310-13a3-dc2b-5ac5-e904bd95d38b@redhat.com>

The only referenced column is one of the *primary* key columns. I left 
out the word "primary" in my previous reply.

To make sure I understand, are you saying that a primary key column 
isn't a primary key column when part of a composite primary key? In 
other words, only the complete set of primary key columns that make up 
the composite primary key would be considered primary key columns and 
the individual primary key columns that make it up would not, 
themselves, be considered primary key columns?

Stephen


On 05/30/2018 03:47 PM, Steve Ebersole wrote:
> The spec says ".... referenced columns that are not primary key 
> columns...".? Nothing in here says full or partial.
>
> I completely agree with Sanne - its not a bug and it is something we 
> have never supported.
>
> On Wed, May 30, 2018 at 3:44 PM Stephen Fikes <sfikes at redhat.com 
> <mailto:sfikes at redhat.com>> wrote:
>
>     The referenced attributes *are* key attributes .. just a subset of
>     the
>     key. So ... odd mapping ... but I don't think it is included in the
>     "optional" category for JPA 2.x.
>
>     Stephen
>
>
>     On 05/30/2018 03:39 PM, Sanne Grinovero wrote:
>     > Hi Gail,
>     >
>     > I would not consider it a bug to not have documented that we don't
>     > support some non-mandatory feature.
>     >
>     > And it's still optional in JPA 2.2, so I think we're good.
>     >
>     > Thanks,
>     > Sanne
>     >
>     >
>     >
>     > On 30 May 2018 at 19:45, Gail Badner <gbadner at redhat.com
>     <mailto:gbadner at redhat.com>> wrote:
>     >> Hi Vlad,
>     >>
>     >> Thanks for your answer. There are definitely better ways to
>     model this
>     >> association.
>     >>
>     >> WRT the second example, where the referenced columns are a
>     subset of the PK
>     >> columns -- I understand there are better ways to model this.
>     >>
>     >> In particular, since the subset of PK columns needs to be
>     unique (since
>     >> they are the referenced columns of a @JoinColumn), there is no
>     reason for
>     >> any other columns to be in the PK.
>     >>
>     >> My question is more about what the JPA spec says about whether
>     this should
>     >> be supported.
>     >>
>     >> Regards,
>     >> Gail
>     >>
>     >>
>     >>
>     >>
>     >>
>     >> On Wed, May 30, 2018 at 12:47 AM, Vlad Mihalcea
>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
>     >> wrote:
>     >>
>     >>> Hi,
>     >>>
>     >>> For the OneToMany with @JoinColumn, the user can workaround this
>     >>> limitation by just using the @ManyToOne on the child side on
>     any column
>     >>> they want
>     >>> and turning the unidirectional association into a
>     bidirectional one. I
>     >>> remember I tested it and it worked just fine.
>     >>>
>     >>> For the? OneToMany with @JoinTable, the only workaround would
>     be if they
>     >>> map the join table as an entity and use the @ManyToOne on the
>     columns they
>     >>> want
>     >>> the association to be based on.
>     >>>
>     >>> Since unidirectional associations don't perform that well, I'm
>     not sure
>     >>> whether it's worth adding support for these use cases.
>     >>>
>     >>> Vlad
>     >>>
>     >>> On Wed, May 30, 2018 at 9:32 AM, Gail Badner
>     <gbadner at redhat.com <mailto:gbadner at redhat.com>> wrote:
>     >>>
>     >>>> Unidirectional OneToMany associations using @JoinColumn that
>     reference
>     >>>> columns that are not PK columns is not currently supported.
>     >>>>
>     >>>> The JPA 2.1 documentation for @JoinTable says:
>     >>>>
>     >>>> "Support for referenced columns that are not primary key
>     columns of the
>     >>>> referenced table is optional. Applications that use such
>     mappings will not
>     >>>> be portable."
>     >>>>
>     >>>> I don't see anything in the user doc that explicitly states
>     that Hibernate
>     >>>> does not support this.
>     >>>>
>     >>>> Is this considered a bug?
>     >>>>
>     >>>> Also, what about a unidirectional OneToMany using a
>     @JoinColumn that
>     >>>> references some, but not all, of primary key columns?
>     Hibernate does not
>     >>>> support that either. Should Hibernate support it since they
>     are primary
>     >>>> key
>     >>>> columns?
>     >>>>
>     >>>> Thanks,
>     >>>> Gail
>     >>>> _______________________________________________
>     >>>> hibernate-dev mailing list
>     >>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     >>>>
>     >>>
>     >> _______________________________________________
>     >> hibernate-dev mailing list
>     >> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     > _______________________________________________
>     > hibernate-dev mailing list
>     > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From sanne at hibernate.org  Thu May 31 10:59:00 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 31 May 2018 15:59:00 +0100
Subject: [hibernate-dev] JDK 11 Early Access build 15 is available for
	download.
In-Reply-To: <d901e688-14cd-483c-a2cf-6ea6810e9f25@oracle.com>
References: <d901e688-14cd-483c-a2cf-6ea6810e9f25@oracle.com>
Message-ID: <CAFm4XO1yUn==8UoCqSUDRzWt082F5iLLWz08n=yAExH1gk9ZHw@mail.gmail.com>

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

From rory.odonnell at oracle.com  Thu May 31 11:00:39 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Thu, 31 May 2018 16:00:39 +0100
Subject: [hibernate-dev] JDK 11 Early Access build 15 is available for
 download.
In-Reply-To: <CAFm4XO1yUn==8UoCqSUDRzWt082F5iLLWz08n=yAExH1gk9ZHw@mail.gmail.com>
References: <d901e688-14cd-483c-a2cf-6ea6810e9f25@oracle.com>
	<CAFm4XO1yUn==8UoCqSUDRzWt082F5iLLWz08n=yAExH1gk9ZHw@mail.gmail.com>
Message-ID: <bf944b3d-df79-ef01-90b9-b6eea0aa8cc2@oracle.com>

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  Thu May 31 12:40:23 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 31 May 2018 17:40:23 +0100
Subject: [hibernate-dev] Health check status API
Message-ID: <CAFm4XO0303CTonPNKTVW++5=yxEyjr0mwTACNUZLL7nZrRjLWw@mail.gmail.com>

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

From mihalcea.vlad at gmail.com  Thu May 31 16:35:00 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 31 May 2018 23:35:00 +0300
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: <CA+gWKMDbe0imeXyK-bKXBBYziDA3u9RxR7tcZjpiu_ONd3NsOw@mail.gmail.com>

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
>