From emmanuel at hibernate.org  Wed Aug  1 04:05:59 2018
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 1 Aug 2018 10:05:59 +0200
Subject: [hibernate-dev] orm.xml scanning issue
In-Reply-To: <CALt0+o8UQswK7Vv5zABM3+Y_9SoZDaO_t301hXBNSKqZAjdFDQ@mail.gmail.com>
References: <CALt0+o9woGAu+P5DwP4aRqanJJ1rEwRdQPpT94sKKMLaKt4_PA@mail.gmail.com>
	<20180731154547.GE45197@hibernate.org>
	<CALt0+o8UQswK7Vv5zABM3+Y_9SoZDaO_t301hXBNSKqZAjdFDQ@mail.gmail.com>
Message-ID: <20180801080559.GB50210@hibernate.org>

What does that even mean the "root of the classpath"?
Which classlaoder do we use to look up the resources? That's the one
showing us multiple entries.

On Tue 18-07-31 17:51, Guillaume Smet wrote:
>From what I understand, the issue is that we don't consider only the root
>file but also files deep in the hierarchy:
>https://github.com/spring-projects/spring-boot/issues/10363 .
>
>On Tue, Jul 31, 2018 at 5:46 PM Emmanuel Bernard <emmanuel at hibernate.org>
>wrote:
>
>> You'll need to check but AFAIR the spec says that META-INF/orm.xml is
>> automatically added. So the fault is on the builder of
>> PersistenceUnitInfo to include it. But we could be friendly and detect
>> the addition of the same file twice.
>>
>> Emmanuel
>>
>> On Tue 18-07-31 17:23, Guillaume Smet wrote:
>> >Hi,
>> >
>> >This issue seems legit to me:
>> >https://hibernate.atlassian.net/browse/HHH-12873
>> >
>> >That being said, I'm not familiar at all with the boot process so I might
>> >be wrong.
>> >
>> >Could someone confirm and take a look at this issue? It looks annoying for
>> >people using Spring Boot.
>> >
>> >Thanks!
>> >
>> >--
>> >Guillaume
>> >_______________________________________________
>> >hibernate-dev mailing list
>> >hibernate-dev at lists.jboss.org
>> >https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>

From sanne at hibernate.org  Wed Aug  1 07:19:08 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 1 Aug 2018 12:19:08 +0100
Subject: [hibernate-dev] OracleTypesHelper doing reflection based
	initialization
Message-ID: <CAFm4XO0nQ71t0Yzp-TnE-8RYuqGg-54W3Ujr9YzoXXXa61S_ig@mail.gmail.com>

This class seems to have a single purpose, which is to extract a
constant from the Oracle JDBC driver:
 - https://github.com/hibernate/hibernate-orm/blob/bd256e4783219f4a765219cf625bb658fcb5fde1/hibernate-core/src/main/java/org/hibernate/dialect/OracleTypesHelper.java#L20

Would it be possible to just have a human read what number it is and
hard code it in the sources?

I guess we could add an integration test to verify that this still is
the right number when drivers are updated.

Is there more to it?

This is what I have in mind:
 - https://github.com/hibernate/hibernate-orm/commit/b9f8e4a7bb2dbec864e0ed5702b2f9b15182892b

Thanks,
Sanne

From yoann at hibernate.org  Thu Aug  2 12:34:50 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Thu, 2 Aug 2018 18:34:50 +0200
Subject: [hibernate-dev] Re-enabling the BlueOcean interface in Jenkins
Message-ID: <CAEqagpqUyXdNrL8_70whGaxEa29-VkAgeD-LsC6zC7-S6-PhfA@mail.gmail.com>

Hi,

We're about to make use of Jenkins pipelines in Hibernate Search, and for
that purpose, the BlueOcean is much easier to read. So I'd like to
re-enable it.

This should not affect other projects much, as the default interface when
you go to ci.hibernate.org will still be the "old" one. However, this will
unfortunately change the URL in emails sent by Jenkins so that the URL
points to the BlueOcean interface; and unfortunately, there doesn't seem to
be a way around that. You do have a button on the top right of the
BlueOcean interface to go back to the "old" interface, though.

For anyone wondering, this
<https://plugins.jenkins.io/blueocean-display-url> is the plugin
responsible for this behavior, and we can't uninstall it as long as
BlueOcean is installed.

Given the inconvenience is minor, and pipeline logs are pretty much
unreadable without the interface (seriously, good luck spotting the problem
in this
<http://ci.hibernate.org/view/Search/job/hibernate-search-6-poc/job/HSEARCH-3239/142/flowGraphTable/>),
is it alright for everyone if I re-enable the BlueOcean interface?

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

From sanne at hibernate.org  Thu Aug  2 12:59:41 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 2 Aug 2018 17:59:41 +0100
Subject: [hibernate-dev] Re-enabling the BlueOcean interface in Jenkins
In-Reply-To: <CAEqagpqUyXdNrL8_70whGaxEa29-VkAgeD-LsC6zC7-S6-PhfA@mail.gmail.com>
References: <CAEqagpqUyXdNrL8_70whGaxEa29-VkAgeD-LsC6zC7-S6-PhfA@mail.gmail.com>
Message-ID: <CAFm4XO3eOvmtSWNtWEEdqA3mvr0m_ZGE6XAHEqNVLPsZTboFjQ@mail.gmail.com>

+1

I think we can live with minor inconveniences, especially as I hope
we'll be moving more projects to take advantage of the pipelines.

On Thu, 2 Aug 2018 at 17:56, Yoann Rodiere <yoann at hibernate.org> wrote:
>
> Hi,
>
> We're about to make use of Jenkins pipelines in Hibernate Search, and for
> that purpose, the BlueOcean is much easier to read. So I'd like to
> re-enable it.
>
> This should not affect other projects much, as the default interface when
> you go to ci.hibernate.org will still be the "old" one. However, this will
> unfortunately change the URL in emails sent by Jenkins so that the URL
> points to the BlueOcean interface; and unfortunately, there doesn't seem to
> be a way around that. You do have a button on the top right of the
> BlueOcean interface to go back to the "old" interface, though.
>
> For anyone wondering, this
> <https://plugins.jenkins.io/blueocean-display-url> is the plugin
> responsible for this behavior, and we can't uninstall it as long as
> BlueOcean is installed.
>
> Given the inconvenience is minor, and pipeline logs are pretty much
> unreadable without the interface (seriously, good luck spotting the problem
> in this
> <http://ci.hibernate.org/view/Search/job/hibernate-search-6-poc/job/HSEARCH-3239/142/flowGraphTable/>),
> is it alright for everyone if I re-enable the BlueOcean interface?
>
> Yoann Rodi?re
> Hibernate NoORM Team
> yoann at hibernate.org
> _______________________________________________
> 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 Aug  2 14:31:27 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 2 Aug 2018 20:31:27 +0200
Subject: [hibernate-dev] Hibernate ORM 5.3.4.Final released
Message-ID: <CALt0+o8ZhZLAnrrUwtXKFBEo+YEFxMdC4ehrkQZpTX1xCozqSQ@mail.gmail.com>

Hi,

We just released Hibernate ORM 5.3.4.Final with several bugfixes.

Recommended upgrade for everyone.

More details here:
http://staging.in.relation.to/2018/08/02/hibernate-orm-534-final-out/ .

Happy upgrading!

-- 
Guillaume

From rory.odonnell at oracle.com  Tue Aug  7 04:30:23 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 7 Aug 2018 09:30:23 +0100
Subject: [hibernate-dev] JDK 11 ,
 JDK 12 and JDK 8u192 Early Access builds are available on
 jdk.java.net
Message-ID: <5737c92a-cf5f-538e-561e-4ca21b08717d@oracle.com>

Hi Sanne,

*JDK 11 Early Access? build 25 is available at : - **jdk.java.net/11/*

  * *JDK 11 entered Rampdown Phase 2 on 26-July [1]*
      o The overall feature set is frozen. No further JEPs will be
        targeted to this release.
      o We now turn our focus to P1 and P2 bugs.
  * Release notes are available here? [2]

*JDK 12 Early Access? build 05 is available at : - **jdk.java.net/12/*

  * Changes in this build here
    <http://hg.openjdk.java.net/jdk/jdk/log?revcount=10000&rev=reverse%28%22jdk-12%2B4%22%3A%3A%22jdk-12%2B5%22%29>.

*JDK 8u192 Early Access build 04 is available at : - http://jdk.java.net/8/*

  * JDK 8u192 timeline is available [3]
      o GA is scheduled for October 2018

**Conference videos online*
*

  * *OpenJDK Committers? Workshop [4]*
  * JVM Language Summit 2018 [5]:


Regards,
Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-July/001669.html
[2] http://jdk.java.net/11/release-notes
[3] http://openjdk.java.net/projects/jdk8u/releases/8u192.html
[4] https://www.youtube.com/playlist?list=PLX8CzqL3ArzXY_9Ornabhxs-j2h4hnvJ3
[5] https://www.youtube.com/playlist?list=PLX8CzqL3ArzVnxC6PYxMlngEMv3W1pIkn


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


From guillaume.smet at gmail.com  Thu Aug  9 09:54:24 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 9 Aug 2018 15:54:24 +0200
Subject: [hibernate-dev] Reducing the memory usage of HQLQueryPlan
Message-ID: <CALt0+o8oRgVcney46HfNBARy3sTJt4qS2h1rYWoSDbkj4OuZzw@mail.gmail.com>

Hi,

>From what I can see, the HQLQueryPlan objects are rather big, mostly due to
the sqlAst element of the QueryTranslators.

They can consume a fair amount of memory when you have a lot of HQL queries.

We need at least some of the information collected by the AST but I'm
wondering if we really need to keep all the AST information in memory once
the query has been parsed and the SQL query generated.

The purpose of this email is mostly to know if this element has been
accounted for in 6 development?

I haven't checked if it would be doable to improve the situation without
breaking too much stuff in 5.x.

Thanks.

-- 
Guillaume

From sanne at hibernate.org  Thu Aug  9 10:24:59 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 9 Aug 2018 15:24:59 +0100
Subject: [hibernate-dev] [!] Changing how to run tests with proprietary JDBC
	drivers: Oracle, HANA
Message-ID: <CAFm4XO1Pfq1EGyvi1tmkD29fnLV1k7mAjVgmNecHeC6A4m_ajw@mail.gmail.com>

I'm setting up some new Oracle integration tests on ci.hibernate.org,
and we're having again a similar issue to what we had with SAP HANA:

 - some JDBC drivers can not be distributed freely
 - we do not want to allow the Hibernate ORM build to load
dependencies from a local Maven repository

So I'm introducing a new (optional) environment variable described on:
 - https://hibernate.atlassian.net/browse/HHH-12901

This implies that if you were running these tests locally you will
need to adjust; I hope it's not too inconvenient.

N.B. the `jdbcDependency` attribute for the matrix configuration needs
to change to match the jar name. I'll commit the change for Oracle
soon.

Thanks,
Sanne

From steve at hibernate.org  Thu Aug  9 10:57:58 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 9 Aug 2018 09:57:58 -0500
Subject: [hibernate-dev] Reducing the memory usage of HQLQueryPlan
In-Reply-To: <CALt0+o8oRgVcney46HfNBARy3sTJt4qS2h1rYWoSDbkj4OuZzw@mail.gmail.com>
References: <CALt0+o8oRgVcney46HfNBARy3sTJt4qS2h1rYWoSDbkj4OuZzw@mail.gmail.com>
Message-ID: <CAFdSV9tBAHurX9DCU7-7U0SrCHPx_StWw1a91PohRBw17wkttA@mail.gmail.com>

In 6.0 HQLQueryPlan is replaced by AggregatedSelectQueryPlanImpl[1]
(polymorphic queries) and ConcreteSqmSelectQueryPlan[2].

ConcreteSqmSelectQueryPlan holds a reference to the SQM AST;
AggregatedSelectQueryPlanImpl
hold 2+ ConcreteSqmSelectQueryPlans.  AggregatedSelectQueryPlan operates
much like HQLQueryPlan when holding more than one QueryTranslator.

ConcreteSqmSelectQueryPlan ought to hold much less state (and hence use
less memory) than QueryTranslator.  And it follows that
AggregatedSelectQueryPlan
ought to consume less memory than HQLQueryPlan+QueryTranslators.

The other win, which is likely much bigger gain, is that previously
parameter expansions (think `... where x in (:someListOfValues)`) resulted
in separate plans based on the number of values in `someListOfValues` -
more HQLQueryPlan instances for the same HQL.  This is actually one of the
(many) explicit design goals for 6.  The cached plan is the same regardless
of the number of values in `someListOfValues`; the expansion happens during
execution.

Relatedly, this last part also lets us reuse cached plans in more scenarios
than we do currently: enabled Filters, enabled FetchProfiles, etc.  All of
these things are applied/resolved during execution.  So there is a slight
trade off between reducing the number of cached plans versus translating
the SQM AST to a SQL AST.  This is important too because often times the
query plan cache is "overrun" due to all of the "different cache keys"
aspect (parameter list expansion, filters, etc) - so that often the queries
get pushed from the cache and need complete re-building.

We cannot really verify this though until Luis, et.al, are able to resume
the performance testing...

[1]
https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/query/sqm/internal/AggregatedSelectQueryPlanImpl.java
[2]
https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/query/sqm/internal/ConcreteSqmSelectQueryPlan.java


On Thu, Aug 9, 2018 at 9:21 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> >From what I can see, the HQLQueryPlan objects are rather big, mostly due
> to
> the sqlAst element of the QueryTranslators.
>
> They can consume a fair amount of memory when you have a lot of HQL
> queries.
>
> We need at least some of the information collected by the AST but I'm
> wondering if we really need to keep all the AST information in memory once
> the query has been parsed and the SQL query generated.
>
> The purpose of this email is mostly to know if this element has been
> accounted for in 6 development?
>
> I haven't checked if it would be doable to improve the situation without
> breaking too much stuff in 5.x.
>
> Thanks.
>
> --
> 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 Aug  9 11:00:36 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 9 Aug 2018 10:00:36 -0500
Subject: [hibernate-dev] [!] Changing how to run tests with proprietary
 JDBC drivers: Oracle, HANA
In-Reply-To: <CAFm4XO1Pfq1EGyvi1tmkD29fnLV1k7mAjVgmNecHeC6A4m_ajw@mail.gmail.com>
References: <CAFm4XO1Pfq1EGyvi1tmkD29fnLV1k7mAjVgmNecHeC6A4m_ajw@mail.gmail.com>
Message-ID: <CAFdSV9ucpd5_zvFKyyBVAfct22u5qmS8_8OJWyLMeH0JmHSdpg@mail.gmail.com>

"Maven repository" is any thing we want it to be, even a locally hosted
repo manager into which we can install any dependencies we want - so it is
not available in any "public" repo, but still referrable via normal Gradle
means.  Seems by far easier solution...


On Thu, Aug 9, 2018 at 9:42 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> I'm setting up some new Oracle integration tests on ci.hibernate.org,
> and we're having again a similar issue to what we had with SAP HANA:
>
>  - some JDBC drivers can not be distributed freely
>  - we do not want to allow the Hibernate ORM build to load
> dependencies from a local Maven repository
>
> So I'm introducing a new (optional) environment variable described on:
>  - https://hibernate.atlassian.net/browse/HHH-12901
>
> This implies that if you were running these tests locally you will
> need to adjust; I hope it's not too inconvenient.
>
> N.B. the `jdbcDependency` attribute for the matrix configuration needs
> to change to match the jar name. I'll commit the change for Oracle
> soon.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Aug  9 12:02:03 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 9 Aug 2018 17:02:03 +0100
Subject: [hibernate-dev] [!] Changing how to run tests with proprietary
 JDBC drivers: Oracle, HANA
In-Reply-To: <CAFdSV9ucpd5_zvFKyyBVAfct22u5qmS8_8OJWyLMeH0JmHSdpg@mail.gmail.com>
References: <CAFm4XO1Pfq1EGyvi1tmkD29fnLV1k7mAjVgmNecHeC6A4m_ajw@mail.gmail.com>
	<CAFdSV9ucpd5_zvFKyyBVAfct22u5qmS8_8OJWyLMeH0JmHSdpg@mail.gmail.com>
Message-ID: <CAFm4XO19cQL627M+zdJvx904WXgFPDwHmHqPRsTm+mSzxZR7Aw@mail.gmail.com>

On Thu, 9 Aug 2018 at 16:00, Steve Ebersole <steve at hibernate.org> wrote:
>
> "Maven repository" is any thing we want it to be, even a locally hosted repo manager into which we can install any dependencies we want - so it is not available in any "public" repo, but still referrable via normal Gradle means.  Seems by far easier solution...

I hope you like this? It was easy enough, once I learned about it:
 - https://github.com/hibernate/hibernate-orm/blob/cd8b754494617e722097d3612f9bdde7a17710aa/build.gradle#L43-L49

>
>
> On Thu, Aug 9, 2018 at 9:42 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> I'm setting up some new Oracle integration tests on ci.hibernate.org,
>> and we're having again a similar issue to what we had with SAP HANA:
>>
>>  - some JDBC drivers can not be distributed freely
>>  - we do not want to allow the Hibernate ORM build to load
>> dependencies from a local Maven repository
>>
>> So I'm introducing a new (optional) environment variable described on:
>>  - https://hibernate.atlassian.net/browse/HHH-12901
>>
>> This implies that if you were running these tests locally you will
>> need to adjust; I hope it's not too inconvenient.
>>
>> N.B. the `jdbcDependency` attribute for the matrix configuration needs
>> to change to match the jar name. I'll commit the change for Oracle
>> soon.
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Fri Aug 10 05:56:44 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 10 Aug 2018 10:56:44 +0100
Subject: [hibernate-dev] Now testing SQL Server and Oracle DBs on the public
	facing ci.hibernate.org
Message-ID: <CAFm4XO26VXANasRz11qDzKOPBpi9=tLP-tYB6cyjwP9spgPaEA@mail.gmail.com>

Hi all,

we have these new databases running on AWS now:
 - SQL Server Express Edition 14.00.3015.40.v1
 - Oracle Standard Edition Two 12.1.0.2.v12

CI jobs are setup for Hibernate ORM to watch the master branch;
connection settings are committed in ORM's upstream.
See the usual matrix configurations in the sources if you need
details, or look at the job configurations.

Jobs are not looking too bad but there are a couple of failures which
will need investigation:
 - http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-oracle/
 - http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-mssql/

I have not setup email notifications, please enlist yourself if you're
interested in actively watching these.

Please be mindful of the restrictions:
 - can't connect from home.
 - there's nothing preventing multiple jobs to share these database so
don't enable any other jobs to use them - at least until we figure out
a reliable locking strategy.

I suspect time sharing is going to be the best answer - considering
we've lived fine without them for months, it should be ok to not run
them all the time.

Thanks,
Sanne

From christian.beikov at gmail.com  Fri Aug 10 09:03:11 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Fri, 10 Aug 2018 15:03:11 +0200
Subject: [hibernate-dev] Reducing the memory usage of HQLQueryPlan
In-Reply-To: <CAFdSV9tBAHurX9DCU7-7U0SrCHPx_StWw1a91PohRBw17wkttA@mail.gmail.com>
References: <CALt0+o8oRgVcney46HfNBARy3sTJt4qS2h1rYWoSDbkj4OuZzw@mail.gmail.com>
	<CAFdSV9tBAHurX9DCU7-7U0SrCHPx_StWw1a91PohRBw17wkttA@mail.gmail.com>
Message-ID: <2a46b693-f9a4-a81e-2613-2bdc40869b78@gmail.com>

I'd like to note that with the array rendering strategy i.e. `where x = 
ANY(?)` and the padding strategy i.e. pad the JDBC params, we can reduce 
the cache trashing and avoid re-walking of the SQL-AST. IMO it's not 
necessary to keep the SQL-AST around for the purpose of parameter 
expansion, but maybe there are other reasons to keep it around?

Wdyt?


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 09.08.2018 um 16:57 schrieb Steve Ebersole:
> In 6.0 HQLQueryPlan is replaced by AggregatedSelectQueryPlanImpl[1]
> (polymorphic queries) and ConcreteSqmSelectQueryPlan[2].
>
> ConcreteSqmSelectQueryPlan holds a reference to the SQM AST;
> AggregatedSelectQueryPlanImpl
> hold 2+ ConcreteSqmSelectQueryPlans.  AggregatedSelectQueryPlan operates
> much like HQLQueryPlan when holding more than one QueryTranslator.
>
> ConcreteSqmSelectQueryPlan ought to hold much less state (and hence use
> less memory) than QueryTranslator.  And it follows that
> AggregatedSelectQueryPlan
> ought to consume less memory than HQLQueryPlan+QueryTranslators.
>
> The other win, which is likely much bigger gain, is that previously
> parameter expansions (think `... where x in (:someListOfValues)`) resulted
> in separate plans based on the number of values in `someListOfValues` -
> more HQLQueryPlan instances for the same HQL.  This is actually one of the
> (many) explicit design goals for 6.  The cached plan is the same regardless
> of the number of values in `someListOfValues`; the expansion happens during
> execution.
>
> Relatedly, this last part also lets us reuse cached plans in more scenarios
> than we do currently: enabled Filters, enabled FetchProfiles, etc.  All of
> these things are applied/resolved during execution.  So there is a slight
> trade off between reducing the number of cached plans versus translating
> the SQM AST to a SQL AST.  This is important too because often times the
> query plan cache is "overrun" due to all of the "different cache keys"
> aspect (parameter list expansion, filters, etc) - so that often the queries
> get pushed from the cache and need complete re-building.
>
> We cannot really verify this though until Luis, et.al, are able to resume
> the performance testing...
>
> [1]
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/query/sqm/internal/AggregatedSelectQueryPlanImpl.java
> [2]
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/query/sqm/internal/ConcreteSqmSelectQueryPlan.java
>
>
> On Thu, Aug 9, 2018 at 9:21 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> Hi,
>>
>> >From what I can see, the HQLQueryPlan objects are rather big, mostly due
>> to
>> the sqlAst element of the QueryTranslators.
>>
>> They can consume a fair amount of memory when you have a lot of HQL
>> queries.
>>
>> We need at least some of the information collected by the AST but I'm
>> wondering if we really need to keep all the AST information in memory once
>> the query has been parsed and the SQL query generated.
>>
>> The purpose of this email is mostly to know if this element has been
>> accounted for in 6 development?
>>
>> I haven't checked if it would be doable to improve the situation without
>> breaking too much stuff in 5.x.
>>
>> Thanks.
>>
>> --
>> 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 mihalcea.vlad at gmail.com  Fri Aug 10 09:27:04 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 10 Aug 2018 16:27:04 +0300
Subject: [hibernate-dev] Reducing the memory usage of HQLQueryPlan
In-Reply-To: <2a46b693-f9a4-a81e-2613-2bdc40869b78@gmail.com>
References: <CALt0+o8oRgVcney46HfNBARy3sTJt4qS2h1rYWoSDbkj4OuZzw@mail.gmail.com>
	<CAFdSV9tBAHurX9DCU7-7U0SrCHPx_StWw1a91PohRBw17wkttA@mail.gmail.com>
	<2a46b693-f9a4-a81e-2613-2bdc40869b78@gmail.com>
Message-ID: <CA+gWKMBv74XbRrpAec6BVoK6g8Np+=UODnfj5PCHHvAZFb2jHg@mail.gmail.com>

We already have the parameter padding for IN queries, and there's a PR for
supplying ARRAY via ANY(?).

For the second approach, we just have to test it thoroughly to make sure
that all major JDBC Driver support it properly.
Also, I'd only have the second approach activated via a config property as
I'm not sure how efficient the Execution Plan gets with this approach.
That also needs some testing.

Vlad

On Fri, Aug 10, 2018 at 4:03 PM, Christian Beikov <
christian.beikov at gmail.com> wrote:

> I'd like to note that with the array rendering strategy i.e. `where x =
> ANY(?)` and the padding strategy i.e. pad the JDBC params, we can reduce
> the cache trashing and avoid re-walking of the SQL-AST. IMO it's not
> necessary to keep the SQL-AST around for the purpose of parameter
> expansion, but maybe there are other reasons to keep it around?
>
> Wdyt?
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 09.08.2018 um 16:57 schrieb Steve Ebersole:
> > In 6.0 HQLQueryPlan is replaced by AggregatedSelectQueryPlanImpl[1]
> > (polymorphic queries) and ConcreteSqmSelectQueryPlan[2].
> >
> > ConcreteSqmSelectQueryPlan holds a reference to the SQM AST;
> > AggregatedSelectQueryPlanImpl
> > hold 2+ ConcreteSqmSelectQueryPlans.  AggregatedSelectQueryPlan operates
> > much like HQLQueryPlan when holding more than one QueryTranslator.
> >
> > ConcreteSqmSelectQueryPlan ought to hold much less state (and hence use
> > less memory) than QueryTranslator.  And it follows that
> > AggregatedSelectQueryPlan
> > ought to consume less memory than HQLQueryPlan+QueryTranslators.
> >
> > The other win, which is likely much bigger gain, is that previously
> > parameter expansions (think `... where x in (:someListOfValues)`)
> resulted
> > in separate plans based on the number of values in `someListOfValues` -
> > more HQLQueryPlan instances for the same HQL.  This is actually one of
> the
> > (many) explicit design goals for 6.  The cached plan is the same
> regardless
> > of the number of values in `someListOfValues`; the expansion happens
> during
> > execution.
> >
> > Relatedly, this last part also lets us reuse cached plans in more
> scenarios
> > than we do currently: enabled Filters, enabled FetchProfiles, etc.  All
> of
> > these things are applied/resolved during execution.  So there is a slight
> > trade off between reducing the number of cached plans versus translating
> > the SQM AST to a SQL AST.  This is important too because often times the
> > query plan cache is "overrun" due to all of the "different cache keys"
> > aspect (parameter list expansion, filters, etc) - so that often the
> queries
> > get pushed from the cache and need complete re-building.
> >
> > We cannot really verify this though until Luis, et.al, are able to
> resume
> > the performance testing...
> >
> > [1]
> > https://github.com/sebersole/hibernate-core/blob/wip/6.0/
> hibernate-core/src/main/java/org/hibernate/query/sqm/internal/
> AggregatedSelectQueryPlanImpl.java
> > [2]
> > https://github.com/sebersole/hibernate-core/blob/wip/6.0/
> hibernate-core/src/main/java/org/hibernate/query/sqm/internal/
> ConcreteSqmSelectQueryPlan.java
> >
> >
> > On Thu, Aug 9, 2018 at 9:21 AM Guillaume Smet <guillaume.smet at gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> >From what I can see, the HQLQueryPlan objects are rather big, mostly
> due
> >> to
> >> the sqlAst element of the QueryTranslators.
> >>
> >> They can consume a fair amount of memory when you have a lot of HQL
> >> queries.
> >>
> >> We need at least some of the information collected by the AST but I'm
> >> wondering if we really need to keep all the AST information in memory
> once
> >> the query has been parsed and the SQL query generated.
> >>
> >> The purpose of this email is mostly to know if this element has been
> >> accounted for in 6 development?
> >>
> >> I haven't checked if it would be doable to improve the situation without
> >> breaking too much stuff in 5.x.
> >>
> >> Thanks.
> >>
> >> --
> >> 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 Aug 10 09:59:38 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 10 Aug 2018 15:59:38 +0200
Subject: [hibernate-dev] Reducing the memory usage of HQLQueryPlan
In-Reply-To: <2a46b693-f9a4-a81e-2613-2bdc40869b78@gmail.com>
References: <CALt0+o8oRgVcney46HfNBARy3sTJt4qS2h1rYWoSDbkj4OuZzw@mail.gmail.com>
	<CAFdSV9tBAHurX9DCU7-7U0SrCHPx_StWw1a91PohRBw17wkttA@mail.gmail.com>
	<2a46b693-f9a4-a81e-2613-2bdc40869b78@gmail.com>
Message-ID: <CALt0+o8aN4CwYtmafqDMaBA1vst2+=1_=L1ZfkAVV1_BSDtJ9Q@mail.gmail.com>

If we can avoid keeping the AST, that would have my preference too.

In 5.x, the AST contains elements that are collected while parsing and then
kept there. We are then forced to keep the AST around. They should be
pushed in a specific container so that we can keep only the strictly
necessary information and get rid of the AST.

6 improvements look great but I agree with Christian that if we can get
entirely rid of the AST, that would be better. Unless there are good
reasons to keep it around.

-- 
Guillaume

On Fri, Aug 10, 2018 at 3:12 PM Christian Beikov <christian.beikov at gmail.com>
wrote:

> I'd like to note that with the array rendering strategy i.e. `where x =
> ANY(?)` and the padding strategy i.e. pad the JDBC params, we can reduce
> the cache trashing and avoid re-walking of the SQL-AST. IMO it's not
> necessary to keep the SQL-AST around for the purpose of parameter
> expansion, but maybe there are other reasons to keep it around?
>
> Wdyt?
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 09.08.2018 um 16:57 schrieb Steve Ebersole:
> > In 6.0 HQLQueryPlan is replaced by AggregatedSelectQueryPlanImpl[1]
> > (polymorphic queries) and ConcreteSqmSelectQueryPlan[2].
> >
> > ConcreteSqmSelectQueryPlan holds a reference to the SQM AST;
> > AggregatedSelectQueryPlanImpl
> > hold 2+ ConcreteSqmSelectQueryPlans.  AggregatedSelectQueryPlan operates
> > much like HQLQueryPlan when holding more than one QueryTranslator.
> >
> > ConcreteSqmSelectQueryPlan ought to hold much less state (and hence use
> > less memory) than QueryTranslator.  And it follows that
> > AggregatedSelectQueryPlan
> > ought to consume less memory than HQLQueryPlan+QueryTranslators.
> >
> > The other win, which is likely much bigger gain, is that previously
> > parameter expansions (think `... where x in (:someListOfValues)`)
> resulted
> > in separate plans based on the number of values in `someListOfValues` -
> > more HQLQueryPlan instances for the same HQL.  This is actually one of
> the
> > (many) explicit design goals for 6.  The cached plan is the same
> regardless
> > of the number of values in `someListOfValues`; the expansion happens
> during
> > execution.
> >
> > Relatedly, this last part also lets us reuse cached plans in more
> scenarios
> > than we do currently: enabled Filters, enabled FetchProfiles, etc.  All
> of
> > these things are applied/resolved during execution.  So there is a slight
> > trade off between reducing the number of cached plans versus translating
> > the SQM AST to a SQL AST.  This is important too because often times the
> > query plan cache is "overrun" due to all of the "different cache keys"
> > aspect (parameter list expansion, filters, etc) - so that often the
> queries
> > get pushed from the cache and need complete re-building.
> >
> > We cannot really verify this though until Luis, et.al, are able to
> resume
> > the performance testing...
> >
> > [1]
> >
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/query/sqm/internal/AggregatedSelectQueryPlanImpl.java
> > [2]
> >
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/query/sqm/internal/ConcreteSqmSelectQueryPlan.java
> >
> >
> > On Thu, Aug 9, 2018 at 9:21 AM Guillaume Smet <guillaume.smet at gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> >From what I can see, the HQLQueryPlan objects are rather big, mostly
> due
> >> to
> >> the sqlAst element of the QueryTranslators.
> >>
> >> They can consume a fair amount of memory when you have a lot of HQL
> >> queries.
> >>
> >> We need at least some of the information collected by the AST but I'm
> >> wondering if we really need to keep all the AST information in memory
> once
> >> the query has been parsed and the SQL query generated.
> >>
> >> The purpose of this email is mostly to know if this element has been
> >> accounted for in 6 development?
> >>
> >> I haven't checked if it would be doable to improve the situation without
> >> breaking too much stuff in 5.x.
> >>
> >> Thanks.
> >>
> >> --
> >> 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 steve at hibernate.org  Fri Aug 10 10:02:23 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 10 Aug 2018 09:02:23 -0500
Subject: [hibernate-dev] Reducing the memory usage of HQLQueryPlan
In-Reply-To: <2a46b693-f9a4-a81e-2613-2bdc40869b78@gmail.com>
References: <CALt0+o8oRgVcney46HfNBARy3sTJt4qS2h1rYWoSDbkj4OuZzw@mail.gmail.com>
	<CAFdSV9tBAHurX9DCU7-7U0SrCHPx_StWw1a91PohRBw17wkttA@mail.gmail.com>
	<2a46b693-f9a4-a81e-2613-2bdc40869b78@gmail.com>
Message-ID: <CAFdSV9sGo4tXJevAwgPtm0W2TkRttKXCC_iDZ_3_KL45LJ8S7w@mail.gmail.com>

Pad to what?  The number of elements in that passed list can literally be
anything between 1 and Interger#MAX_VALUE.  Are you saying that we should
expand any/all multi-valued parameters to Interger#MAX_VALUE JDBC params?

I guess we could do "buckets" of padding, but I am not convinced that
really buys us any performance.  Especially when you started considering
queries with multiple multi-valued parameters where we'd end up with a
product of the padding buckets for each.

I'm up for trying anything we think might improve performance.  But that
implies a baseline to make a comparison anyway - so I plan on continuing
with the current approach for now...


On Fri, Aug 10, 2018, 8:11 AM Christian Beikov <christian.beikov at gmail.com>
wrote:

> I'd like to note that with the array rendering strategy i.e. `where x =
> ANY(?)` and the padding strategy i.e. pad the JDBC params, we can reduce
> the cache trashing and avoid re-walking of the SQL-AST. IMO it's not
> necessary to keep the SQL-AST around for the purpose of parameter
> expansion, but maybe there are other reasons to keep it around?
>
> Wdyt?
>
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 09.08.2018 um 16:57 schrieb Steve Ebersole:
> > In 6.0 HQLQueryPlan is replaced by AggregatedSelectQueryPlanImpl[1]
> > (polymorphic queries) and ConcreteSqmSelectQueryPlan[2].
> >
> > ConcreteSqmSelectQueryPlan holds a reference to the SQM AST;
> > AggregatedSelectQueryPlanImpl
> > hold 2+ ConcreteSqmSelectQueryPlans.  AggregatedSelectQueryPlan operates
> > much like HQLQueryPlan when holding more than one QueryTranslator.
> >
> > ConcreteSqmSelectQueryPlan ought to hold much less state (and hence use
> > less memory) than QueryTranslator.  And it follows that
> > AggregatedSelectQueryPlan
> > ought to consume less memory than HQLQueryPlan+QueryTranslators.
> >
> > The other win, which is likely much bigger gain, is that previously
> > parameter expansions (think `... where x in (:someListOfValues)`)
> resulted
> > in separate plans based on the number of values in `someListOfValues` -
> > more HQLQueryPlan instances for the same HQL.  This is actually one of
> the
> > (many) explicit design goals for 6.  The cached plan is the same
> regardless
> > of the number of values in `someListOfValues`; the expansion happens
> during
> > execution.
> >
> > Relatedly, this last part also lets us reuse cached plans in more
> scenarios
> > than we do currently: enabled Filters, enabled FetchProfiles, etc.  All
> of
> > these things are applied/resolved during execution.  So there is a slight
> > trade off between reducing the number of cached plans versus translating
> > the SQM AST to a SQL AST.  This is important too because often times the
> > query plan cache is "overrun" due to all of the "different cache keys"
> > aspect (parameter list expansion, filters, etc) - so that often the
> queries
> > get pushed from the cache and need complete re-building.
> >
> > We cannot really verify this though until Luis, et.al, are able to
> resume
> > the performance testing...
> >
> > [1]
> >
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/query/sqm/internal/AggregatedSelectQueryPlanImpl.java
> > [2]
> >
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/query/sqm/internal/ConcreteSqmSelectQueryPlan.java
> >
> >
> > On Thu, Aug 9, 2018 at 9:21 AM Guillaume Smet <guillaume.smet at gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> >From what I can see, the HQLQueryPlan objects are rather big, mostly
> due
> >> to
> >> the sqlAst element of the QueryTranslators.
> >>
> >> They can consume a fair amount of memory when you have a lot of HQL
> >> queries.
> >>
> >> We need at least some of the information collected by the AST but I'm
> >> wondering if we really need to keep all the AST information in memory
> once
> >> the query has been parsed and the SQL query generated.
> >>
> >> The purpose of this email is mostly to know if this element has been
> >> accounted for in 6 development?
> >>
> >> I haven't checked if it would be doable to improve the situation without
> >> breaking too much stuff in 5.x.
> >>
> >> Thanks.
> >>
> >> --
> >> 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 steve at hibernate.org  Fri Aug 10 10:34:04 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 10 Aug 2018 09:34:04 -0500
Subject: [hibernate-dev] Reducing the memory usage of HQLQueryPlan
In-Reply-To: <CA+gWKMBv74XbRrpAec6BVoK6g8Np+=UODnfj5PCHHvAZFb2jHg@mail.gmail.com>
References: <CALt0+o8oRgVcney46HfNBARy3sTJt4qS2h1rYWoSDbkj4OuZzw@mail.gmail.com>
	<CAFdSV9tBAHurX9DCU7-7U0SrCHPx_StWw1a91PohRBw17wkttA@mail.gmail.com>
	<2a46b693-f9a4-a81e-2613-2bdc40869b78@gmail.com>
	<CA+gWKMBv74XbRrpAec6BVoK6g8Np+=UODnfj5PCHHvAZFb2jHg@mail.gmail.com>
Message-ID: <CAFdSV9vu3Y8y3X5q4vLwBwM-QV0Bjc=2fPs6wMNQLKJ8H3LgYQ@mail.gmail.com>

Unless someone added support for it recently, the padding for IN is not for
Query handling, it's for batch loading which is a very different scenario.
With batch loading we know a finite number of JDBC params - the batch size.


On Fri, Aug 10, 2018, 9:17 AM Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> We already have the parameter padding for IN queries, and there's a PR for
> supplying ARRAY via ANY(?).
>
> For the second approach, we just have to test it thoroughly to make sure
> that all major JDBC Driver support it properly.
> Also, I'd only have the second approach activated via a config property as
> I'm not sure how efficient the Execution Plan gets with this approach.
> That also needs some testing.
>
> Vlad
>
> On Fri, Aug 10, 2018 at 4:03 PM, Christian Beikov <
> christian.beikov at gmail.com> wrote:
>
> > I'd like to note that with the array rendering strategy i.e. `where x =
> > ANY(?)` and the padding strategy i.e. pad the JDBC params, we can reduce
> > the cache trashing and avoid re-walking of the SQL-AST. IMO it's not
> > necessary to keep the SQL-AST around for the purpose of parameter
> > expansion, but maybe there are other reasons to keep it around?
> >
> > Wdyt?
> >
> >
> > Mit freundlichen Gr??en,
> > ------------------------------------------------------------------------
> > *Christian Beikov*
> > Am 09.08.2018 um 16:57 schrieb Steve Ebersole:
> > > In 6.0 HQLQueryPlan is replaced by AggregatedSelectQueryPlanImpl[1]
> > > (polymorphic queries) and ConcreteSqmSelectQueryPlan[2].
> > >
> > > ConcreteSqmSelectQueryPlan holds a reference to the SQM AST;
> > > AggregatedSelectQueryPlanImpl
> > > hold 2+ ConcreteSqmSelectQueryPlans.  AggregatedSelectQueryPlan
> operates
> > > much like HQLQueryPlan when holding more than one QueryTranslator.
> > >
> > > ConcreteSqmSelectQueryPlan ought to hold much less state (and hence use
> > > less memory) than QueryTranslator.  And it follows that
> > > AggregatedSelectQueryPlan
> > > ought to consume less memory than HQLQueryPlan+QueryTranslators.
> > >
> > > The other win, which is likely much bigger gain, is that previously
> > > parameter expansions (think `... where x in (:someListOfValues)`)
> > resulted
> > > in separate plans based on the number of values in `someListOfValues` -
> > > more HQLQueryPlan instances for the same HQL.  This is actually one of
> > the
> > > (many) explicit design goals for 6.  The cached plan is the same
> > regardless
> > > of the number of values in `someListOfValues`; the expansion happens
> > during
> > > execution.
> > >
> > > Relatedly, this last part also lets us reuse cached plans in more
> > scenarios
> > > than we do currently: enabled Filters, enabled FetchProfiles, etc.  All
> > of
> > > these things are applied/resolved during execution.  So there is a
> slight
> > > trade off between reducing the number of cached plans versus
> translating
> > > the SQM AST to a SQL AST.  This is important too because often times
> the
> > > query plan cache is "overrun" due to all of the "different cache keys"
> > > aspect (parameter list expansion, filters, etc) - so that often the
> > queries
> > > get pushed from the cache and need complete re-building.
> > >
> > > We cannot really verify this though until Luis, et.al, are able to
> > resume
> > > the performance testing...
> > >
> > > [1]
> > > https://github.com/sebersole/hibernate-core/blob/wip/6.0/
> > hibernate-core/src/main/java/org/hibernate/query/sqm/internal/
> > AggregatedSelectQueryPlanImpl.java
> > > [2]
> > > https://github.com/sebersole/hibernate-core/blob/wip/6.0/
> > hibernate-core/src/main/java/org/hibernate/query/sqm/internal/
> > ConcreteSqmSelectQueryPlan.java
> > >
> > >
> > > On Thu, Aug 9, 2018 at 9:21 AM Guillaume Smet <
> guillaume.smet at gmail.com>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> >From what I can see, the HQLQueryPlan objects are rather big, mostly
> > due
> > >> to
> > >> the sqlAst element of the QueryTranslators.
> > >>
> > >> They can consume a fair amount of memory when you have a lot of HQL
> > >> queries.
> > >>
> > >> We need at least some of the information collected by the AST but I'm
> > >> wondering if we really need to keep all the AST information in memory
> > once
> > >> the query has been parsed and the SQL query generated.
> > >>
> > >> The purpose of this email is mostly to know if this element has been
> > >> accounted for in 6 development?
> > >>
> > >> I haven't checked if it would be doable to improve the situation
> without
> > >> breaking too much stuff in 5.x.
> > >>
> > >> Thanks.
> > >>
> > >> --
> > >> 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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Fri Aug 10 10:59:51 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 10 Aug 2018 17:59:51 +0300
Subject: [hibernate-dev] Reducing the memory usage of HQLQueryPlan
In-Reply-To: <CAFdSV9vu3Y8y3X5q4vLwBwM-QV0Bjc=2fPs6wMNQLKJ8H3LgYQ@mail.gmail.com>
References: <CALt0+o8oRgVcney46HfNBARy3sTJt4qS2h1rYWoSDbkj4OuZzw@mail.gmail.com>
	<CAFdSV9tBAHurX9DCU7-7U0SrCHPx_StWw1a91PohRBw17wkttA@mail.gmail.com>
	<2a46b693-f9a4-a81e-2613-2bdc40869b78@gmail.com>
	<CA+gWKMBv74XbRrpAec6BVoK6g8Np+=UODnfj5PCHHvAZFb2jHg@mail.gmail.com>
	<CAFdSV9vu3Y8y3X5q4vLwBwM-QV0Bjc=2fPs6wMNQLKJ8H3LgYQ@mail.gmail.com>
Message-ID: <CA+gWKMBivE43JFf-t2ffmJoDEYSPbLQWgw3_tKO+ToSR9pJbog@mail.gmail.com>

I added support for IN query clause parameter padding:

https://vladmihalcea.com/improve-statement-caching-efficiency-in-clause-parameter-padding/

So, we also support this feature since Hibernate 5.2.18 and 5.3.

Vlad

On Fri, Aug 10, 2018 at 5:34 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Unless someone added support for it recently, the padding for IN is not
> for Query handling, it's for batch loading which is a very different
> scenario.  With batch loading we know a finite number of JDBC params - the
> batch size.
>
>
> On Fri, Aug 10, 2018, 9:17 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> We already have the parameter padding for IN queries, and there's a PR for
>> supplying ARRAY via ANY(?).
>>
>> For the second approach, we just have to test it thoroughly to make sure
>> that all major JDBC Driver support it properly.
>> Also, I'd only have the second approach activated via a config property as
>> I'm not sure how efficient the Execution Plan gets with this approach.
>> That also needs some testing.
>>
>> Vlad
>>
>> On Fri, Aug 10, 2018 at 4:03 PM, Christian Beikov <
>> christian.beikov at gmail.com> wrote:
>>
>> > I'd like to note that with the array rendering strategy i.e. `where x =
>> > ANY(?)` and the padding strategy i.e. pad the JDBC params, we can reduce
>> > the cache trashing and avoid re-walking of the SQL-AST. IMO it's not
>> > necessary to keep the SQL-AST around for the purpose of parameter
>> > expansion, but maybe there are other reasons to keep it around?
>> >
>> > Wdyt?
>> >
>> >
>> > Mit freundlichen Gr??en,
>> > ------------------------------------------------------------
>> ------------
>> > *Christian Beikov*
>> > Am 09.08.2018 um 16:57 schrieb Steve Ebersole:
>> > > In 6.0 HQLQueryPlan is replaced by AggregatedSelectQueryPlanImpl[1]
>> > > (polymorphic queries) and ConcreteSqmSelectQueryPlan[2].
>> > >
>> > > ConcreteSqmSelectQueryPlan holds a reference to the SQM AST;
>> > > AggregatedSelectQueryPlanImpl
>> > > hold 2+ ConcreteSqmSelectQueryPlans.  AggregatedSelectQueryPlan
>> operates
>> > > much like HQLQueryPlan when holding more than one QueryTranslator.
>> > >
>> > > ConcreteSqmSelectQueryPlan ought to hold much less state (and hence
>> use
>> > > less memory) than QueryTranslator.  And it follows that
>> > > AggregatedSelectQueryPlan
>> > > ought to consume less memory than HQLQueryPlan+QueryTranslators.
>> > >
>> > > The other win, which is likely much bigger gain, is that previously
>> > > parameter expansions (think `... where x in (:someListOfValues)`)
>> > resulted
>> > > in separate plans based on the number of values in `someListOfValues`
>> -
>> > > more HQLQueryPlan instances for the same HQL.  This is actually one of
>> > the
>> > > (many) explicit design goals for 6.  The cached plan is the same
>> > regardless
>> > > of the number of values in `someListOfValues`; the expansion happens
>> > during
>> > > execution.
>> > >
>> > > Relatedly, this last part also lets us reuse cached plans in more
>> > scenarios
>> > > than we do currently: enabled Filters, enabled FetchProfiles, etc.
>> All
>> > of
>> > > these things are applied/resolved during execution.  So there is a
>> slight
>> > > trade off between reducing the number of cached plans versus
>> translating
>> > > the SQM AST to a SQL AST.  This is important too because often times
>> the
>> > > query plan cache is "overrun" due to all of the "different cache keys"
>> > > aspect (parameter list expansion, filters, etc) - so that often the
>> > queries
>> > > get pushed from the cache and need complete re-building.
>> > >
>> > > We cannot really verify this though until Luis, et.al, are able to
>> > resume
>> > > the performance testing...
>> > >
>> > > [1]
>> > > https://github.com/sebersole/hibernate-core/blob/wip/6.0/
>> > hibernate-core/src/main/java/org/hibernate/query/sqm/internal/
>> > AggregatedSelectQueryPlanImpl.java
>> > > [2]
>> > > https://github.com/sebersole/hibernate-core/blob/wip/6.0/
>> > hibernate-core/src/main/java/org/hibernate/query/sqm/internal/
>> > ConcreteSqmSelectQueryPlan.java
>> > >
>> > >
>> > > On Thu, Aug 9, 2018 at 9:21 AM Guillaume Smet <
>> guillaume.smet at gmail.com>
>> > > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> >From what I can see, the HQLQueryPlan objects are rather big, mostly
>> > due
>> > >> to
>> > >> the sqlAst element of the QueryTranslators.
>> > >>
>> > >> They can consume a fair amount of memory when you have a lot of HQL
>> > >> queries.
>> > >>
>> > >> We need at least some of the information collected by the AST but I'm
>> > >> wondering if we really need to keep all the AST information in memory
>> > once
>> > >> the query has been parsed and the SQL query generated.
>> > >>
>> > >> The purpose of this email is mostly to know if this element has been
>> > >> accounted for in 6 development?
>> > >>
>> > >> I haven't checked if it would be doable to improve the situation
>> without
>> > >> breaking too much stuff in 5.x.
>> > >>
>> > >> Thanks.
>> > >>
>> > >> --
>> > >> 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
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From mihalcea.vlad at gmail.com  Sun Aug 12 08:15:59 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sun, 12 Aug 2018 15:15:59 +0300
Subject: [hibernate-dev] Reducing the memory usage of HQLQueryPlan
In-Reply-To: <CAFdSV9sGo4tXJevAwgPtm0W2TkRttKXCC_iDZ_3_KL45LJ8S7w@mail.gmail.com>
References: <CALt0+o8oRgVcney46HfNBARy3sTJt4qS2h1rYWoSDbkj4OuZzw@mail.gmail.com>
	<CAFdSV9tBAHurX9DCU7-7U0SrCHPx_StWw1a91PohRBw17wkttA@mail.gmail.com>
	<2a46b693-f9a4-a81e-2613-2bdc40869b78@gmail.com>
	<CAFdSV9sGo4tXJevAwgPtm0W2TkRttKXCC_iDZ_3_KL45LJ8S7w@mail.gmail.com>
Message-ID: <CA+gWKMBS2z7MmtAHEw4+8jufij8WcoDQS_gHTUfNy89=u=g77w@mail.gmail.com>

Pad to the nearest power of 2. The performance improvement comes from the
likelihood of reusing the SQL Execution Plan on DBs that have a cache for
that: Oracle, SQL Server, DB2.

Vlad

On Sun, 12 Aug 2018, 04:43 Steve Ebersole, <steve at hibernate.org> wrote:

> Pad to what?  The number of elements in that passed list can literally be
> anything between 1 and Interger#MAX_VALUE.  Are you saying that we should
> expand any/all multi-valued parameters to Interger#MAX_VALUE JDBC params?
>
> I guess we could do "buckets" of padding, but I am not convinced that
> really buys us any performance.  Especially when you started considering
> queries with multiple multi-valued parameters where we'd end up with a
> product of the padding buckets for each.
>
> I'm up for trying anything we think might improve performance.  But that
> implies a baseline to make a comparison anyway - so I plan on continuing
> with the current approach for now...
>
>
> On Fri, Aug 10, 2018, 8:11 AM Christian Beikov <christian.beikov at gmail.com
> >
> wrote:
>
> > I'd like to note that with the array rendering strategy i.e. `where x =
> > ANY(?)` and the padding strategy i.e. pad the JDBC params, we can reduce
> > the cache trashing and avoid re-walking of the SQL-AST. IMO it's not
> > necessary to keep the SQL-AST around for the purpose of parameter
> > expansion, but maybe there are other reasons to keep it around?
> >
> > Wdyt?
> >
> >
> > Mit freundlichen Gr??en,
> > ------------------------------------------------------------------------
> > *Christian Beikov*
> > Am 09.08.2018 um 16:57 schrieb Steve Ebersole:
> > > In 6.0 HQLQueryPlan is replaced by AggregatedSelectQueryPlanImpl[1]
> > > (polymorphic queries) and ConcreteSqmSelectQueryPlan[2].
> > >
> > > ConcreteSqmSelectQueryPlan holds a reference to the SQM AST;
> > > AggregatedSelectQueryPlanImpl
> > > hold 2+ ConcreteSqmSelectQueryPlans.  AggregatedSelectQueryPlan
> operates
> > > much like HQLQueryPlan when holding more than one QueryTranslator.
> > >
> > > ConcreteSqmSelectQueryPlan ought to hold much less state (and hence use
> > > less memory) than QueryTranslator.  And it follows that
> > > AggregatedSelectQueryPlan
> > > ought to consume less memory than HQLQueryPlan+QueryTranslators.
> > >
> > > The other win, which is likely much bigger gain, is that previously
> > > parameter expansions (think `... where x in (:someListOfValues)`)
> > resulted
> > > in separate plans based on the number of values in `someListOfValues` -
> > > more HQLQueryPlan instances for the same HQL.  This is actually one of
> > the
> > > (many) explicit design goals for 6.  The cached plan is the same
> > regardless
> > > of the number of values in `someListOfValues`; the expansion happens
> > during
> > > execution.
> > >
> > > Relatedly, this last part also lets us reuse cached plans in more
> > scenarios
> > > than we do currently: enabled Filters, enabled FetchProfiles, etc.  All
> > of
> > > these things are applied/resolved during execution.  So there is a
> slight
> > > trade off between reducing the number of cached plans versus
> translating
> > > the SQM AST to a SQL AST.  This is important too because often times
> the
> > > query plan cache is "overrun" due to all of the "different cache keys"
> > > aspect (parameter list expansion, filters, etc) - so that often the
> > queries
> > > get pushed from the cache and need complete re-building.
> > >
> > > We cannot really verify this though until Luis, et.al, are able to
> > resume
> > > the performance testing...
> > >
> > > [1]
> > >
> >
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/query/sqm/internal/AggregatedSelectQueryPlanImpl.java
> > > [2]
> > >
> >
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/query/sqm/internal/ConcreteSqmSelectQueryPlan.java
> > >
> > >
> > > On Thu, Aug 9, 2018 at 9:21 AM Guillaume Smet <
> guillaume.smet at gmail.com>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> >From what I can see, the HQLQueryPlan objects are rather big, mostly
> > due
> > >> to
> > >> the sqlAst element of the QueryTranslators.
> > >>
> > >> They can consume a fair amount of memory when you have a lot of HQL
> > >> queries.
> > >>
> > >> We need at least some of the information collected by the AST but I'm
> > >> wondering if we really need to keep all the AST information in memory
> > once
> > >> the query has been parsed and the SQL query generated.
> > >>
> > >> The purpose of this email is mostly to know if this element has been
> > >> accounted for in 6 development?
> > >>
> > >> I haven't checked if it would be doable to improve the situation
> without
> > >> breaking too much stuff in 5.x.
> > >>
> > >> Thanks.
> > >>
> > >> --
> > >> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at hibernate.org  Mon Aug 13 09:52:30 2018
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Mon, 13 Aug 2018 15:52:30 +0200
Subject: [hibernate-dev] Hibernate Validator 6.0.12.Final released
Message-ID: <CALt0+o8hOz6NLGWJ7eTTJez88yrdtkWvDo-Aq_-kntGqFS9m_g@mail.gmail.com>

Hi,

We just released Hibernate Validator 6.0.12.Final: the main change was made
to the CDI integration to fix a startup time regression. Please take a
closer look at the announcement if you're using CDI with Hibernate
Validator.

The full announcement is here:
http://in.relation.to/2018/08/13/hibernate-validator-6012-final-out/ .

Have a nice day!

-- 
Guillaume

From guillaume.smet at gmail.com  Tue Aug 14 09:20:35 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 14 Aug 2018 15:20:35 +0200
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o_RKyWXP30jX_+soxhHsgTvhCsq72zqnn6Fhpxi68sp=A@mail.gmail.com>

Hi all,

Here are the minutes of our NoORM IRC meeting:

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

Cheers,

-- 
Guillaume

From guillaume.smet at hibernate.org  Tue Aug 14 09:42:06 2018
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Tue, 14 Aug 2018 15:42:06 +0200
Subject: [hibernate-dev] Hibernate ORM 5.3.5.Final released
Message-ID: <CALt0+o-TKLcJ9+ufOkCO=EPSdOMb7vX+vh30de0zF9_ODJjQMQ@mail.gmail.com>

Hi,

We released today a new maintenance version of ORM: 5.3.5.Final.

It mostly contain bugfixes.

You can read the full announcement here:
http://in.relation.to/2018/08/14/hibernate-orm-535-final-out/ .

Have a nice day.

-- 
Guillaume

From sanne at hibernate.org  Wed Aug 15 11:56:12 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 15 Aug 2018 16:56:12 +0100
Subject: [hibernate-dev] BlobProxy,
	Reducing the amount of Proxies we rely on at runtime
Message-ID: <CAFm4XO1yxypcyNDXN1sT9k3-q64ms2HEGPhbXHMUwxLj0DsAQA@mail.gmail.com>

I'm trying to understand if we could remove some of the usages of
`java.lang.reflect.Proxy`.

Clearly it's a long journey and maybe we will never be able to remove
them all, but I would at least want to try avoiding most of their neet
at runtime - limiting their usage at bootstrap/configuration or other
similar "one time" contexts.

We're all aware that these proxies have not been introduced lightly:
most are necessary or very useful; at least useful enough to prefer
having them to not having them; surely the tradeoffs have been
considered.

So what I'm trying to understand now is if all the tradeoffs made in
the past are still actual; some of the related code is > 10 years old;
I could use some help with evaluating what could be safely removed.

One example: org.hibernate.engine.jdbc.BlobProxy has the following comment:
"We use proxies here solely to avoid JDBC version incompatibilities."

Today we require Java8 as baseline, and the `java.sql.Blob` did not
change in any more recent JDK (I just thouroughly diff-ed the
JDK8,9,10,11,12 on this package using Gunnar's jdk-api-diff tool).

Would that be a reasonable candidate to replace the Proxy usage with a
plain implementation of the relevant interfaces? Clearly this implies
I'm betting that future JDKs will not break this again, still I'd
rather cleanup this usage today.

1 - Could I go ahead with that?

2 - Any more such cleanups come to mind?

Thanks,
Sanne

From guillaume.smet at gmail.com  Wed Aug 15 12:23:41 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 15 Aug 2018 18:23:41 +0200
Subject: [hibernate-dev] CDI related issue
Message-ID: <CALt0+o8tW3cm6Yh4=+8MEszsh1jb08JE7Fdw9Y_REspUjfz1oQ@mail.gmail.com>

Hi Steve,

Scott reported https://hibernate.atlassian.net/browse/HHH-12912 recently
and I was wondering if you could take a look at it, considering you worked
on the new CDI features of 5.3.

Asking for help as it would be nice to have a fix for WF 14 (released at
the end of this month) and time flies.

If you have some time to fix the issue or give us some guidance on the best
way to fix it, that would be helpful.

Thanks!

-- 
Guillaume

From steve at hibernate.org  Wed Aug 15 16:14:35 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 15 Aug 2018 15:14:35 -0500
Subject: [hibernate-dev] CDI related issue
In-Reply-To: <CALt0+o8tW3cm6Yh4=+8MEszsh1jb08JE7Fdw9Y_REspUjfz1oQ@mail.gmail.com>
References: <CALt0+o8tW3cm6Yh4=+8MEszsh1jb08JE7Fdw9Y_REspUjfz1oQ@mail.gmail.com>
Message-ID: <CAFdSV9ud-c4-jyVJusgjQQY7wUtjT9G4hS7Jt-hcj+b1PfmcYQ@mail.gmail.com>

Replied on Jira

On Wed, Aug 15, 2018 at 11:24 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi Steve,
>
> Scott reported https://hibernate.atlassian.net/browse/HHH-12912 recently
> and I was wondering if you could take a look at it, considering you worked
> on the new CDI features of 5.3.
>
> Asking for help as it would be nice to have a fix for WF 14 (released at
> the end of this month) and time flies.
>
> If you have some time to fix the issue or give us some guidance on the
> best way to fix it, that would be helpful.
>
> Thanks!
>
> --
> Guillaume
>

From steve at hibernate.org  Wed Aug 15 16:28:20 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 15 Aug 2018 15:28:20 -0500
Subject: [hibernate-dev] BlobProxy,
 Reducing the amount of Proxies we rely on at runtime
In-Reply-To: <CAFm4XO1yxypcyNDXN1sT9k3-q64ms2HEGPhbXHMUwxLj0DsAQA@mail.gmail.com>
References: <CAFm4XO1yxypcyNDXN1sT9k3-q64ms2HEGPhbXHMUwxLj0DsAQA@mail.gmail.com>
Message-ID: <CAFdSV9t6+e0sm--wFC746yiOoO8dYzXmsTe6bHsafErax7N0ZA@mail.gmail.com>

(Blob | Clob | NClob)Proxy are intended to do exactly what you said which
is exactly what the comment says.  They were developed when we still
base-lined on Java 4 or 5.  Java 6 added NClob and IIRC added methods to
Blob and Clob.

Hopefully if they add methods moving forward, they simply use default
impls.  If not we'd potentially be in the same boat sometime down the
road.  I'm not against removing them though if you wish.

If we go this route of statically implementing JDBC contracts, then another
one to consider is ResultSetWrapperProxy..

On Wed, Aug 15, 2018 at 2:26 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> I'm trying to understand if we could remove some of the usages of
> `java.lang.reflect.Proxy`.
>
> Clearly it's a long journey and maybe we will never be able to remove
> them all, but I would at least want to try avoiding most of their neet
> at runtime - limiting their usage at bootstrap/configuration or other
> similar "one time" contexts.
>
> We're all aware that these proxies have not been introduced lightly:
> most are necessary or very useful; at least useful enough to prefer
> having them to not having them; surely the tradeoffs have been
> considered.
>
> So what I'm trying to understand now is if all the tradeoffs made in
> the past are still actual; some of the related code is > 10 years old;
> I could use some help with evaluating what could be safely removed.
>
> One example: org.hibernate.engine.jdbc.BlobProxy has the following comment:
> "We use proxies here solely to avoid JDBC version incompatibilities."
>
> Today we require Java8 as baseline, and the `java.sql.Blob` did not
> change in any more recent JDK (I just thouroughly diff-ed the
> JDK8,9,10,11,12 on this package using Gunnar's jdk-api-diff tool).
>
> Would that be a reasonable candidate to replace the Proxy usage with a
> plain implementation of the relevant interfaces? Clearly this implies
> I'm betting that future JDKs will not break this again, still I'd
> rather cleanup this usage today.
>
> 1 - Could I go ahead with that?
>
> 2 - Any more such cleanups come to mind?
>
> 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  Thu Aug 16 05:15:22 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 16 Aug 2018 11:15:22 +0200
Subject: [hibernate-dev] CDI related issue
In-Reply-To: <CAFdSV9ud-c4-jyVJusgjQQY7wUtjT9G4hS7Jt-hcj+b1PfmcYQ@mail.gmail.com>
References: <CALt0+o8tW3cm6Yh4=+8MEszsh1jb08JE7Fdw9Y_REspUjfz1oQ@mail.gmail.com>
	<CAFdSV9ud-c4-jyVJusgjQQY7wUtjT9G4hS7Jt-hcj+b1PfmcYQ@mail.gmail.com>
Message-ID: <CALt0+o9go2SwWMCSVP7YM-7exZ09+eti96wAN_BjJGtemNy6uQ@mail.gmail.com>

Thanks!

From sanne at hibernate.org  Thu Aug 16 06:06:36 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 16 Aug 2018 11:06:36 +0100
Subject: [hibernate-dev] BlobProxy,
 Reducing the amount of Proxies we rely on at runtime
In-Reply-To: <CAFdSV9t6+e0sm--wFC746yiOoO8dYzXmsTe6bHsafErax7N0ZA@mail.gmail.com>
References: <CAFm4XO1yxypcyNDXN1sT9k3-q64ms2HEGPhbXHMUwxLj0DsAQA@mail.gmail.com>
	<CAFdSV9t6+e0sm--wFC746yiOoO8dYzXmsTe6bHsafErax7N0ZA@mail.gmail.com>
Message-ID: <CAFm4XO32WoLPe0uz9AOnnfZzSEY89QD4cRb=4uwM+UbpA8WV4g@mail.gmail.com>

Hi Steve,

thanks for confirming all that.

There's of course some risk that future JDBC drivers will break
things, but there's no breaking change in any version 9,10,11,12 ; I
believe it's unlikely and even if there's need for working around a
breaking change, we could evaluate various options. We might want to
re-introduce the usage of Proxy, but I suppose we'll also evaluate
alternatives which didn't exist 10y ago - like you mentioned one would
hope that the JDBC maintainer might introduce default method
implementations, or we could use Multi-Release-Jars to workaround JDK
specific defects. This is assuming the JDBC module isn't spin-off from
the JDK altogether.

It's all wild speculation today, so let's see.. either way I'm
confident that such challenges won't stop us; removing the proxy today
will help with both runtime efficiency and my prototypes with ahead of
time compilation.

I've pushed replacement code for the BlobProxy, will soon work on the
other ones you mentioned too.

Thanks,
Sanne

On Wed, 15 Aug 2018 at 21:28, Steve Ebersole <steve at hibernate.org> wrote:
>
> (Blob | Clob | NClob)Proxy are intended to do exactly what you said which is exactly what the comment says.  They were developed when we still base-lined on Java 4 or 5.  Java 6 added NClob and IIRC added methods to Blob and Clob.
>
> Hopefully if they add methods moving forward, they simply use default impls.  If not we'd potentially be in the same boat sometime down the road.  I'm not against removing them though if you wish.
>
> If we go this route of statically implementing JDBC contracts, then another one to consider is ResultSetWrapperProxy..
>
> On Wed, Aug 15, 2018 at 2:26 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> I'm trying to understand if we could remove some of the usages of
>> `java.lang.reflect.Proxy`.
>>
>> Clearly it's a long journey and maybe we will never be able to remove
>> them all, but I would at least want to try avoiding most of their neet
>> at runtime - limiting their usage at bootstrap/configuration or other
>> similar "one time" contexts.
>>
>> We're all aware that these proxies have not been introduced lightly:
>> most are necessary or very useful; at least useful enough to prefer
>> having them to not having them; surely the tradeoffs have been
>> considered.
>>
>> So what I'm trying to understand now is if all the tradeoffs made in
>> the past are still actual; some of the related code is > 10 years old;
>> I could use some help with evaluating what could be safely removed.
>>
>> One example: org.hibernate.engine.jdbc.BlobProxy has the following comment:
>> "We use proxies here solely to avoid JDBC version incompatibilities."
>>
>> Today we require Java8 as baseline, and the `java.sql.Blob` did not
>> change in any more recent JDK (I just thouroughly diff-ed the
>> JDK8,9,10,11,12 on this package using Gunnar's jdk-api-diff tool).
>>
>> Would that be a reasonable candidate to replace the Proxy usage with a
>> plain implementation of the relevant interfaces? Clearly this implies
>> I'm betting that future JDKs will not break this again, still I'd
>> rather cleanup this usage today.
>>
>> 1 - Could I go ahead with that?
>>
>> 2 - Any more such cleanups come to mind?
>>
>> 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  Thu Aug 16 09:46:21 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 16 Aug 2018 15:46:21 +0200
Subject: [hibernate-dev] Releasing Hibernate ORM 5.2.18.Final?
Message-ID: <CALt0+o-=O2Z7QV=A2TW21k0Qep67-7r0vHq9JhCU49B_y+2kiQ@mail.gmail.com>

Hi,

So, it's been a long time since we last released the ORM 5.2 branch and
some people are asking about it, some of them with good reasons not to
upgrade to 5.3.

I think we are making it something big because we wanted it to be THE last
5.2 release and this ends up in it not being released at all.

Also, we have a lot of other things to do, which doesn't help.

I propose the following plan:
- starting September 1st, I'll go through the 5.3 fixes and see what can be
easily backported - we already have important fixes in 5.2.18 so if some
issue is not easily backportable or worth it, I'll skip it altogether and
wait for someone to complain vocally about it;
- I'll wrap up a 5.2.18 by September 14th;
- if we need one more after that, I'll do another release.

If you have a 5.3 fix you absolutely want in 5.2.x, please be vocal about
it because there's a good chance I will be pretty aggressive in not
backporting the bugfixes we pushed to 5.3 recently (e.g. not cherry-picking
gracefully -> not in 5.2.18).

The idea is to let Gail focus as much as possible on the still opened 5.1
-> 5.3 regressions.

Does everybody agree with this plan?

-- 
Guillaume

From sanne at hibernate.org  Thu Aug 16 10:05:41 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 16 Aug 2018 15:05:41 +0100
Subject: [hibernate-dev] Releasing Hibernate ORM 5.2.18.Final?
In-Reply-To: <CALt0+o-=O2Z7QV=A2TW21k0Qep67-7r0vHq9JhCU49B_y+2kiQ@mail.gmail.com>
References: <CALt0+o-=O2Z7QV=A2TW21k0Qep67-7r0vHq9JhCU49B_y+2kiQ@mail.gmail.com>
Message-ID: <CAFm4XO0nwgUdcmSXrDvF+pijqZtqZQp=Sz32u=j9a_U97tNe_A@mail.gmail.com>

It's never realistic to say "it's THE last ..." so I guess I agree we
can show a bit of flexibility - but people should not get used to it,
we can not re-establish a plan of regular releases from 5.2.

We have to severely limit the time we can dedicate to it. Also please
make sure people are motivated to update to 5.3, they better have
extremely good reasons to not upgrade, and I would like to know more
about those reasons. Could you take some notes when you hear such war
stories?

Of course we can be more flexible with needs of contributors. If
someone needs a backport and is volunteering to do 90% of the work
then we can help, but we can't spend significant more time than
approve changes and trigger the release jobs. No blogs.

Thanks!

On Thu, 16 Aug 2018 at 14:54, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>
> Hi,
>
> So, it's been a long time since we last released the ORM 5.2 branch and
> some people are asking about it, some of them with good reasons not to
> upgrade to 5.3.
>
> I think we are making it something big because we wanted it to be THE last
> 5.2 release and this ends up in it not being released at all.
>
> Also, we have a lot of other things to do, which doesn't help.
>
> I propose the following plan:
> - starting September 1st, I'll go through the 5.3 fixes and see what can be
> easily backported - we already have important fixes in 5.2.18 so if some
> issue is not easily backportable or worth it, I'll skip it altogether and
> wait for someone to complain vocally about it;
> - I'll wrap up a 5.2.18 by September 14th;
> - if we need one more after that, I'll do another release.
>
> If you have a 5.3 fix you absolutely want in 5.2.x, please be vocal about
> it because there's a good chance I will be pretty aggressive in not
> backporting the bugfixes we pushed to 5.3 recently (e.g. not cherry-picking
> gracefully -> not in 5.2.18).
>
> The idea is to let Gail focus as much as possible on the still opened 5.1
> -> 5.3 regressions.
>
> Does everybody agree with this plan?
>
> --
> 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  Thu Aug 16 10:17:56 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 16 Aug 2018 16:17:56 +0200
Subject: [hibernate-dev] Releasing Hibernate ORM 5.2.18.Final?
In-Reply-To: <CAFm4XO0nwgUdcmSXrDvF+pijqZtqZQp=Sz32u=j9a_U97tNe_A@mail.gmail.com>
References: <CALt0+o-=O2Z7QV=A2TW21k0Qep67-7r0vHq9JhCU49B_y+2kiQ@mail.gmail.com>
	<CAFm4XO0nwgUdcmSXrDvF+pijqZtqZQp=Sz32u=j9a_U97tNe_A@mail.gmail.com>
Message-ID: <CALt0+o_GwHYEZY1kutHqF20TofmdzgESSHcRON7ZQydQKzWzXA@mail.gmail.com>

On Thu, Aug 16, 2018 at 4:05 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> It's never realistic to say "it's THE last ..." so I guess I agree we
> can show a bit of flexibility - but people should not get used to it,
> we can not re-establish a plan of regular releases from 5.2.
>

Sure, that's not what I suggest. Just that we shouldn't put too much
pressure on "it's THE LAST release, we need to get everything in order" or
we won't release anything at all.

So it's more about saying: if we find a big issue or if we introduce a big
regression, we can fix this one and release again.

FWIW, 5.2.18 was planned for June 18th and already contains *62* resolved
issues.

But yes, the idea is no more 5.2 release after this one if we can avoid it.
E.g. no active backport of 5.3 bugfixes.


> We have to severely limit the time we can dedicate to it. Also please
> make sure people are motivated to update to 5.3, they better have
> extremely good reasons to not upgrade, and I would like to know more
> about those reasons. Could you take some notes when you hear such war
> stories?
>

So, the last one I heard is a user needing to support JPA 2.1 containers. I
think it's a good one.


> Of course we can be more flexible with needs of contributors. If
> someone needs a backport and is volunteering to do 90% of the work
> then we can help, but we can't spend significant more time than
> approve changes and trigger the release jobs. No blogs.
>

I think we need to push an announcement but it can be really simple with
just a link to the fixed issues. There's really not much more to say about
it anyway.

-- 
Guillaume

From sanne at hibernate.org  Thu Aug 16 10:28:25 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 16 Aug 2018 15:28:25 +0100
Subject: [hibernate-dev] Releasing Hibernate ORM 5.2.18.Final?
In-Reply-To: <CALt0+o_GwHYEZY1kutHqF20TofmdzgESSHcRON7ZQydQKzWzXA@mail.gmail.com>
References: <CALt0+o-=O2Z7QV=A2TW21k0Qep67-7r0vHq9JhCU49B_y+2kiQ@mail.gmail.com>
	<CAFm4XO0nwgUdcmSXrDvF+pijqZtqZQp=Sz32u=j9a_U97tNe_A@mail.gmail.com>
	<CALt0+o_GwHYEZY1kutHqF20TofmdzgESSHcRON7ZQydQKzWzXA@mail.gmail.com>
Message-ID: <CAFm4XO0Gg1_QeLTJ6xUfShsoNtevHf02fW=k=VagTZ8oEgjH6A@mail.gmail.com>

On Thu, 16 Aug 2018 at 15:18, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>
> On Thu, Aug 16, 2018 at 4:05 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> It's never realistic to say "it's THE last ..." so I guess I agree we
>> can show a bit of flexibility - but people should not get used to it,
>> we can not re-establish a plan of regular releases from 5.2.
>
>
> Sure, that's not what I suggest. Just that we shouldn't put too much pressure on "it's THE LAST release, we need to get everything in order" or we won't release anything at all.

+1

> So it's more about saying: if we find a big issue or if we introduce a big regression, we can fix this one and release again.
>
> FWIW, 5.2.18 was planned for June 18th and already contains *62* resolved issues.
>
> But yes, the idea is no more 5.2 release after this one if we can avoid it. E.g. no active backport of 5.3 bugfixes.
>
>>
>> We have to severely limit the time we can dedicate to it. Also please
>> make sure people are motivated to update to 5.3, they better have
>> extremely good reasons to not upgrade, and I would like to know more
>> about those reasons. Could you take some notes when you hear such war
>> stories?
>
>
> So, the last one I heard is a user needing to support JPA 2.1 containers. I think it's a good one.

I'm not convinced it's a good one :) but not going to argue, thanks
for sharing it.

>>
>> Of course we can be more flexible with needs of contributors. If
>> someone needs a backport and is volunteering to do 90% of the work
>> then we can help, but we can't spend significant more time than
>> approve changes and trigger the release jobs. No blogs.
>
>
> I think we need to push an announcement but it can be really simple with just a link to the fixed issues. There's really not much more to say about it anyway.

Announce it, but no ad-hoc blogs please. We can mention the release in
the next weekly update or something like that.

>
> --
> Guillaume

From gbadner at redhat.com  Fri Aug 17 14:54:04 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 17 Aug 2018 11:54:04 -0700
Subject: [hibernate-dev] Releasing Hibernate ORM 5.2.18.Final?
In-Reply-To: <CAFm4XO0Gg1_QeLTJ6xUfShsoNtevHf02fW=k=VagTZ8oEgjH6A@mail.gmail.com>
References: <CALt0+o-=O2Z7QV=A2TW21k0Qep67-7r0vHq9JhCU49B_y+2kiQ@mail.gmail.com>
	<CAFm4XO0nwgUdcmSXrDvF+pijqZtqZQp=Sz32u=j9a_U97tNe_A@mail.gmail.com>
	<CALt0+o_GwHYEZY1kutHqF20TofmdzgESSHcRON7ZQydQKzWzXA@mail.gmail.com>
	<CAFm4XO0Gg1_QeLTJ6xUfShsoNtevHf02fW=k=VagTZ8oEgjH6A@mail.gmail.com>
Message-ID: <CAFDzhiRohHC=1=xWsB-8-8DfbxhaksVZ3ab=3XwnR5Ct4X6tig@mail.gmail.com>

Months ago Chris volunteered to do the release. I asked him to wait so I
could get HHH-12436 and HHH-11209 fixed.

I'm finally able to address those issues. I think I'll have HHH-12436 ready
to review by early next week. I've already done some some work on on the
last bit mentioned in the PR for HHH-11209, so if nothing else gets in the
way, I should have both fixed next week.

On Thu, Aug 16, 2018 at 7:28 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On Thu, 16 Aug 2018 at 15:18, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
> >
> > On Thu, Aug 16, 2018 at 4:05 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> It's never realistic to say "it's THE last ..." so I guess I agree we
> >> can show a bit of flexibility - but people should not get used to it,
> >> we can not re-establish a plan of regular releases from 5.2.
> >
> >
> > Sure, that's not what I suggest. Just that we shouldn't put too much
> pressure on "it's THE LAST release, we need to get everything in order" or
> we won't release anything at all.
>
> +1
>
> > So it's more about saying: if we find a big issue or if we introduce a
> big regression, we can fix this one and release again.
> >
> > FWIW, 5.2.18 was planned for June 18th and already contains *62*
> resolved issues.
> >
> > But yes, the idea is no more 5.2 release after this one if we can avoid
> it. E.g. no active backport of 5.3 bugfixes.
> >
> >>
> >> We have to severely limit the time we can dedicate to it. Also please
> >> make sure people are motivated to update to 5.3, they better have
> >> extremely good reasons to not upgrade, and I would like to know more
> >> about those reasons. Could you take some notes when you hear such war
> >> stories?
> >
> >
> > So, the last one I heard is a user needing to support JPA 2.1
> containers. I think it's a good one.
>
> I'm not convinced it's a good one :) but not going to argue, thanks
> for sharing it.
>
> >>
> >> Of course we can be more flexible with needs of contributors. If
> >> someone needs a backport and is volunteering to do 90% of the work
> >> then we can help, but we can't spend significant more time than
> >> approve changes and trigger the release jobs. No blogs.
> >
> >
> > I think we need to push an announcement but it can be really simple with
> just a link to the fixed issues. There's really not much more to say about
> it anyway.
>
> Announce it, but no ad-hoc blogs please. We can mention the release in
> the next weekly update or something like that.
>
> >
> > --
> > Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Fri Aug 17 15:00:39 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 17 Aug 2018 12:00:39 -0700
Subject: [hibernate-dev] BlobProxy,
 Reducing the amount of Proxies we rely on at runtime
In-Reply-To: <CAFm4XO32WoLPe0uz9AOnnfZzSEY89QD4cRb=4uwM+UbpA8WV4g@mail.gmail.com>
References: <CAFm4XO1yxypcyNDXN1sT9k3-q64ms2HEGPhbXHMUwxLj0DsAQA@mail.gmail.com>
	<CAFdSV9t6+e0sm--wFC746yiOoO8dYzXmsTe6bHsafErax7N0ZA@mail.gmail.com>
	<CAFm4XO32WoLPe0uz9AOnnfZzSEY89QD4cRb=4uwM+UbpA8WV4g@mail.gmail.com>
Message-ID: <CAFDzhiSeb190XzTO_kHsS_6mUvM-3vOpt=_h_drv1KS7N-U+cA@mail.gmail.com>

Just an FYI, I had to fix a bug recently to support a JDK6 version of JDBC.
I believe it was Oracle JDBC.

On Thu, Aug 16, 2018 at 3:06 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hi Steve,
>
> thanks for confirming all that.
>
> There's of course some risk that future JDBC drivers will break
> things, but there's no breaking change in any version 9,10,11,12 ; I
> believe it's unlikely and even if there's need for working around a
> breaking change, we could evaluate various options. We might want to
> re-introduce the usage of Proxy, but I suppose we'll also evaluate
> alternatives which didn't exist 10y ago - like you mentioned one would
> hope that the JDBC maintainer might introduce default method
> implementations, or we could use Multi-Release-Jars to workaround JDK
> specific defects. This is assuming the JDBC module isn't spin-off from
> the JDK altogether.
>
> It's all wild speculation today, so let's see.. either way I'm
> confident that such challenges won't stop us; removing the proxy today
> will help with both runtime efficiency and my prototypes with ahead of
> time compilation.
>
> I've pushed replacement code for the BlobProxy, will soon work on the
> other ones you mentioned too.
>
> Thanks,
> Sanne
>
> On Wed, 15 Aug 2018 at 21:28, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > (Blob | Clob | NClob)Proxy are intended to do exactly what you said
> which is exactly what the comment says.  They were developed when we still
> base-lined on Java 4 or 5.  Java 6 added NClob and IIRC added methods to
> Blob and Clob.
> >
> > Hopefully if they add methods moving forward, they simply use default
> impls.  If not we'd potentially be in the same boat sometime down the
> road.  I'm not against removing them though if you wish.
> >
> > If we go this route of statically implementing JDBC contracts, then
> another one to consider is ResultSetWrapperProxy..
> >
> > On Wed, Aug 15, 2018 at 2:26 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> I'm trying to understand if we could remove some of the usages of
> >> `java.lang.reflect.Proxy`.
> >>
> >> Clearly it's a long journey and maybe we will never be able to remove
> >> them all, but I would at least want to try avoiding most of their neet
> >> at runtime - limiting their usage at bootstrap/configuration or other
> >> similar "one time" contexts.
> >>
> >> We're all aware that these proxies have not been introduced lightly:
> >> most are necessary or very useful; at least useful enough to prefer
> >> having them to not having them; surely the tradeoffs have been
> >> considered.
> >>
> >> So what I'm trying to understand now is if all the tradeoffs made in
> >> the past are still actual; some of the related code is > 10 years old;
> >> I could use some help with evaluating what could be safely removed.
> >>
> >> One example: org.hibernate.engine.jdbc.BlobProxy has the following
> comment:
> >> "We use proxies here solely to avoid JDBC version incompatibilities."
> >>
> >> Today we require Java8 as baseline, and the `java.sql.Blob` did not
> >> change in any more recent JDK (I just thouroughly diff-ed the
> >> JDK8,9,10,11,12 on this package using Gunnar's jdk-api-diff tool).
> >>
> >> Would that be a reasonable candidate to replace the Proxy usage with a
> >> plain implementation of the relevant interfaces? Clearly this implies
> >> I'm betting that future JDKs will not break this again, still I'd
> >> rather cleanup this usage today.
> >>
> >> 1 - Could I go ahead with that?
> >>
> >> 2 - Any more such cleanups come to mind?
> >>
> >> 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 Aug 22 07:09:28 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 22 Aug 2018 13:09:28 +0200
Subject: [hibernate-dev] Please do not merge to ORM 5.3
Message-ID: <CALt0+o9M_W9aCQGKnEfCHykTANKeJ_3jb+6NhtWfNxHxB-NcFQ@mail.gmail.com>

Hi,

Please do not merge anything to ORM 5.3 for now, we need to have a
discussion about what we merge there.

Thanks!

-- 
Guillaume

From rory.odonnell at oracle.com  Fri Aug 24 05:15:17 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 24 Aug 2018 10:15:17 +0100
Subject: [hibernate-dev] JDK 11: First Release Candidate available
Message-ID: <ab2da3f5-1cdc-8df2-3886-cfae58aa3dce@oracle.com>

Hi Sanne,

*JDK 11 build 28 is our first JDK 11 Release Candidate [1]
*

  * JDK 11 Early Access? build 28 is available at : - jdk.java.net/11/

*FOSS fixes in recent builds.*

  * Eclipse Jetty - JDK-8207177
    <https://bugs.openjdk.java.net/browse/JDK-8207177> (b27)
  * Apache Tomcat ? -JDK-8208642
    <https://bugs.openjdk.java.net/browse/JDK-8208642>(b27)
  * JBoss Netty - JDK-8207029
    <https://bugs.openjdk.java.net/browse/JDK-8207029> (b23),
    JDK-8208166 <https://bugs.openjdk.java.net/browse/JDK-8208166> (b25)

*JDK 12 Early Access build 8 is available at : - jdk.java.net/12/*

  * Release Notes for JDK 12 [2]
  * Changes in this build include
      o JDK-8208350 <https://bugs.openjdk.java.net/browse/JDK-8208350> -
        Disable all DES TLS cipher suites

*OpenJFX Early-Access Build 24 is available at :-* 
*http://jdk.java.net/openjfx/*

  * This library is delivered as a set of modules, along with the native
    code needed to run JavaFX, that can be run using a JDK 10
    <http://jdk.java.net/10/> build or a JDK 11 EA
    <http://jdk.java.net/11/> build.
  * This build is intended to allow application developers and OpenJFX
    contributors to test their applications with an unbundled,
    standalone JavaFX library.

Regards,
Rory

[1] 
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001844.html 
<http://openjdk.java.net/projects/jdk/11/#Schedule>
[2] http://jdk.java.net/12/release-notes


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


From sanne at hibernate.org  Fri Aug 24 06:49:55 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 24 Aug 2018 11:49:55 +0100
Subject: [hibernate-dev] JDK 11: First Release Candidate available
In-Reply-To: <ab2da3f5-1cdc-8df2-3886-cfae58aa3dce@oracle.com>
References: <ab2da3f5-1cdc-8df2-3886-cfae58aa3dce@oracle.com>
Message-ID: <CAFm4XO2z822uRkH6GnXxZoqfjJRbAefZAjmNvcoEudLrukMLwA@mail.gmail.com>

Thanks Rory!
Updating our systems.

Regards,
Sanne

On Fri, 24 Aug 2018 at 10:25, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
>
> Hi Sanne,
>
> *JDK 11 build 28 is our first JDK 11 Release Candidate [1]
> *
>
>   * JDK 11 Early Access  build 28 is available at : - jdk.java.net/11/
>
> *FOSS fixes in recent builds.*
>
>   * Eclipse Jetty - JDK-8207177
>     <https://bugs.openjdk.java.net/browse/JDK-8207177> (b27)
>   * Apache Tomcat   -JDK-8208642
>     <https://bugs.openjdk.java.net/browse/JDK-8208642>(b27)
>   * JBoss Netty - JDK-8207029
>     <https://bugs.openjdk.java.net/browse/JDK-8207029> (b23),
>     JDK-8208166 <https://bugs.openjdk.java.net/browse/JDK-8208166> (b25)
>
> *JDK 12 Early Access build 8 is available at : - jdk.java.net/12/*
>
>   * Release Notes for JDK 12 [2]
>   * Changes in this build include
>       o JDK-8208350 <https://bugs.openjdk.java.net/browse/JDK-8208350> -
>         Disable all DES TLS cipher suites
>
> *OpenJFX Early-Access Build 24 is available at :-*
> *http://jdk.java.net/openjfx/*
>
>   * This library is delivered as a set of modules, along with the native
>     code needed to run JavaFX, that can be run using a JDK 10
>     <http://jdk.java.net/10/> build or a JDK 11 EA
>     <http://jdk.java.net/11/> build.
>   * This build is intended to allow application developers and OpenJFX
>     contributors to test their applications with an unbundled,
>     standalone JavaFX library.
>
> Regards,
> Rory
>
> [1]
> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001844.html
> <http://openjdk.java.net/projects/jdk/11/#Schedule>
> [2] http://jdk.java.net/12/release-notes
>
>
> --
> 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 gbadner at redhat.com  Fri Aug 24 23:54:34 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 24 Aug 2018 20:54:34 -0700
Subject: [hibernate-dev] How to enable Javassist when running a WildFly unit
	test?
Message-ID: <CAFDzhiSCxZQ=pPh__Pz_BxAcBv+HMJsVPp96WKXpL9ux6kSDaA@mail.gmail.com>

I tried running:

mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
-Dhibernate.bytecode.provider=javassist -Dsecurity.manager=true

The result is a permissions failure, and ByteBuddy is in the stacktrace.

I also tried adding the property to the StandardServiceRegistryBuilder
built by SFSBHibernateSFNaturalId, and that didn't work either.

Is there some other way to enable javassist?

Thanks,
Gail

From gbadner at redhat.com  Sat Aug 25 15:02:20 2018
From: gbadner at redhat.com (Gail Badner)
Date: Sat, 25 Aug 2018 12:02:20 -0700
Subject: [hibernate-dev] How to enable Javassist when running a WildFly
	unit test?
In-Reply-To: <CAFDzhiSCxZQ=pPh__Pz_BxAcBv+HMJsVPp96WKXpL9ux6kSDaA@mail.gmail.com>
References: <CAFDzhiSCxZQ=pPh__Pz_BxAcBv+HMJsVPp96WKXpL9ux6kSDaA@mail.gmail.com>
Message-ID: <CAFDzhiQV5v=SwBH5C2KzoWH+1UQSRAPVDmubb1cDJizWRx7d3g@mail.gmail.com>

To clarify, I'm trying to enable javassist on WildFly 14.

On Fri, Aug 24, 2018 at 8:54 PM, Gail Badner <gbadner at redhat.com> wrote:

> I tried running:
>
> mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
> -Dhibernate.bytecode.provider=javassist -Dsecurity.manager=true
>
> The result is a permissions failure, and ByteBuddy is in the stacktrace.
>
> I also tried adding the property to the StandardServiceRegistryBuilder
> built by SFSBHibernateSFNaturalId, and that didn't work either.
>
> Is there some other way to enable javassist?
>
> Thanks,
> Gail
>

From postmaster at lists.jboss.org  Mon Aug 27 03:37:37 2018
From: postmaster at lists.jboss.org (Bounced mail)
Date: Mon, 27 Aug 2018 15:37:37 +0800
Subject: [hibernate-dev] Returned mail: Data format error
Message-ID: <201808270739.w7R7dUu5006392@lists01.dmz-a.mwc.hst.phx2.redhat.com>

The original message was received at Mon, 27 Aug 2018 15:37:37 +0800
from lists.jboss.org [15.9.202.182]

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




From yoann at hibernate.org  Mon Aug 27 04:15:02 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Mon, 27 Aug 2018 10:15:02 +0200
Subject: [hibernate-dev] Re-enabling the BlueOcean interface in Jenkins
In-Reply-To: <CAFm4XO3eOvmtSWNtWEEdqA3mvr0m_ZGE6XAHEqNVLPsZTboFjQ@mail.gmail.com>
References: <CAEqagpqUyXdNrL8_70whGaxEa29-VkAgeD-LsC6zC7-S6-PhfA@mail.gmail.com>
	<CAFm4XO3eOvmtSWNtWEEdqA3mvr0m_ZGE6XAHEqNVLPsZTboFjQ@mail.gmail.com>
Message-ID: <CAEqagpqY9YTmKc71jsrJN+vW+w1gtTFhsCgQmNWc0kNNfdqMPg@mail.gmail.com>

Since there was no objections, I re-enabled BlueOcean.

See an example here:
http://ci.hibernate.org/blue/organizations/jenkins/hibernate-search-6-poc/detail/HSEARCH-3239/142/pipeline

When in the BlueOcean interface, you can go back to the classic interface
using the button circled in red in this screen capture:
https://i.imgur.com/lAck9GM.png

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


On Thu, 2 Aug 2018 at 18:59, Sanne Grinovero <sanne at hibernate.org> wrote:

> +1
>
> I think we can live with minor inconveniences, especially as I hope
> we'll be moving more projects to take advantage of the pipelines.
>
> On Thu, 2 Aug 2018 at 17:56, Yoann Rodiere <yoann at hibernate.org> wrote:
> >
> > Hi,
> >
> > We're about to make use of Jenkins pipelines in Hibernate Search, and for
> > that purpose, the BlueOcean is much easier to read. So I'd like to
> > re-enable it.
> >
> > This should not affect other projects much, as the default interface when
> > you go to ci.hibernate.org will still be the "old" one. However, this
> will
> > unfortunately change the URL in emails sent by Jenkins so that the URL
> > points to the BlueOcean interface; and unfortunately, there doesn't seem
> to
> > be a way around that. You do have a button on the top right of the
> > BlueOcean interface to go back to the "old" interface, though.
> >
> > For anyone wondering, this
> > <https://plugins.jenkins.io/blueocean-display-url> is the plugin
> > responsible for this behavior, and we can't uninstall it as long as
> > BlueOcean is installed.
> >
> > Given the inconvenience is minor, and pipeline logs are pretty much
> > unreadable without the interface (seriously, good luck spotting the
> problem
> > in this
> > <
> http://ci.hibernate.org/view/Search/job/hibernate-search-6-poc/job/HSEARCH-3239/142/flowGraphTable/
> >),
> > is it alright for everyone if I re-enable the BlueOcean interface?
> >
> > Yoann Rodi?re
> > Hibernate NoORM Team
> > yoann at hibernate.org
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From msimka at redhat.com  Mon Aug 27 07:20:27 2018
From: msimka at redhat.com (Martin Simka)
Date: Mon, 27 Aug 2018 13:20:27 +0200
Subject: [hibernate-dev] How to enable Javassist when running a WildFly
 unit test?
In-Reply-To: <CAFDzhiQV5v=SwBH5C2KzoWH+1UQSRAPVDmubb1cDJizWRx7d3g@mail.gmail.com>
References: <CAFDzhiSCxZQ=pPh__Pz_BxAcBv+HMJsVPp96WKXpL9ux6kSDaA@mail.gmail.com>
	<CAFDzhiQV5v=SwBH5C2KzoWH+1UQSRAPVDmubb1cDJizWRx7d3g@mail.gmail.com>
Message-ID: <CAEFmnWrt9TmfaG7gvh0Ha=BKtZS9PBqXJVdisda3OqEezV_EYw@mail.gmail.com>

Hi Gail,

mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
-Dextra.server.jvm.args="-Dhibernate.bytecode.provider=javassist"
-Dsecurity.manager=true

should do it. But I still see ByteBuddy in the stacktrace. I also tried to
add property directly to WildFly configuration file or to hibernate.cfg.xml
with the same result.

Martin

On Sat, Aug 25, 2018 at 11:28 PM Gail Badner <gbadner at redhat.com> wrote:

> To clarify, I'm trying to enable javassist on WildFly 14.
>
> On Fri, Aug 24, 2018 at 8:54 PM, Gail Badner <gbadner at redhat.com> wrote:
>
> > I tried running:
> >
> > mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
> > -Dhibernate.bytecode.provider=javassist -Dsecurity.manager=true
> >
> > The result is a permissions failure, and ByteBuddy is in the stacktrace.
> >
> > I also tried adding the property to the StandardServiceRegistryBuilder
> > built by SFSBHibernateSFNaturalId, and that didn't work either.
> >
> > Is there some other way to enable javassist?
> >
> > Thanks,
> > Gail
> >
> _______________________________________________
> 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 Aug 27 08:25:59 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 27 Aug 2018 14:25:59 +0200
Subject: [hibernate-dev] How to enable Javassist when running a WildFly
 unit test?
In-Reply-To: <CAEFmnWrt9TmfaG7gvh0Ha=BKtZS9PBqXJVdisda3OqEezV_EYw@mail.gmail.com>
References: <CAFDzhiSCxZQ=pPh__Pz_BxAcBv+HMJsVPp96WKXpL9ux6kSDaA@mail.gmail.com>
	<CAFDzhiQV5v=SwBH5C2KzoWH+1UQSRAPVDmubb1cDJizWRx7d3g@mail.gmail.com>
	<CAEFmnWrt9TmfaG7gvh0Ha=BKtZS9PBqXJVdisda3OqEezV_EYw@mail.gmail.com>
Message-ID: <CALt0+o-NVxEjFggF3vbB_3hRO5EzmnQsCEEhBrbpjkEXL6ZW4Q@mail.gmail.com>

Let me check what is happening here.

There are 2 issues: the test should work with ByteBuddy. At least, it did
work a few weeks ago when I worked on this. And we should be able to
override the bytecode provider. It also worked a few weeks ago as I tested
Javassist and ByteBuddy.

And IIRC, I used the exact command line you are using Martin.

On Mon, Aug 27, 2018 at 1:31 PM Martin Simka <msimka at redhat.com> wrote:

> Hi Gail,
>
> mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
> -Dextra.server.jvm.args="-Dhibernate.bytecode.provider=javassist"
> -Dsecurity.manager=true
>
> should do it. But I still see ByteBuddy in the stacktrace. I also tried to
> add property directly to WildFly configuration file or to hibernate.cfg.xml
> with the same result.
>
> Martin
>
> On Sat, Aug 25, 2018 at 11:28 PM Gail Badner <gbadner at redhat.com> wrote:
>
> > To clarify, I'm trying to enable javassist on WildFly 14.
> >
> > On Fri, Aug 24, 2018 at 8:54 PM, Gail Badner <gbadner at redhat.com> wrote:
> >
> > > I tried running:
> > >
> > > mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
> > > -Dhibernate.bytecode.provider=javassist -Dsecurity.manager=true
> > >
> > > The result is a permissions failure, and ByteBuddy is in the
> stacktrace.
> > >
> > > I also tried adding the property to the StandardServiceRegistryBuilder
> > > built by SFSBHibernateSFNaturalId, and that didn't work either.
> > >
> > > Is there some other way to enable javassist?
> > >
> > > 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 chris at hibernate.org  Mon Aug 27 08:57:28 2018
From: chris at hibernate.org (Chris Cranford)
Date: Mon, 27 Aug 2018 08:57:28 -0400
Subject: [hibernate-dev] How to enable Javassist when running a WildFly
 unit test?
In-Reply-To: <CAFDzhiSCxZQ=pPh__Pz_BxAcBv+HMJsVPp96WKXpL9ux6kSDaA@mail.gmail.com>
References: <CAFDzhiSCxZQ=pPh__Pz_BxAcBv+HMJsVPp96WKXpL9ux6kSDaA@mail.gmail.com>
Message-ID: <a76346b8-9d70-8ca7-69dc-74826846d6bb@hibernate.org>

Technically the -D parameter should work; however I know a
hibernate.properties file works.

On 08/24/2018 11:54 PM, Gail Badner wrote:
> I tried running:
>
> mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
> -Dhibernate.bytecode.provider=javassist -Dsecurity.manager=true
>
> The result is a permissions failure, and ByteBuddy is in the stacktrace.
>
> I also tried adding the property to the StandardServiceRegistryBuilder
> built by SFSBHibernateSFNaturalId, and that didn't work either.
>
> Is there some other way to enable javassist?
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From smarlow at redhat.com  Mon Aug 27 09:02:07 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 27 Aug 2018 09:02:07 -0400
Subject: [hibernate-dev] How to enable Javassist when running a WildFly
 unit test?
In-Reply-To: <CAEFmnWrt9TmfaG7gvh0Ha=BKtZS9PBqXJVdisda3OqEezV_EYw@mail.gmail.com>
References: <CAFDzhiSCxZQ=pPh__Pz_BxAcBv+HMJsVPp96WKXpL9ux6kSDaA@mail.gmail.com>
	<CAFDzhiQV5v=SwBH5C2KzoWH+1UQSRAPVDmubb1cDJizWRx7d3g@mail.gmail.com>
	<CAEFmnWrt9TmfaG7gvh0Ha=BKtZS9PBqXJVdisda3OqEezV_EYw@mail.gmail.com>
Message-ID: <a32ccfd5-3a82-f9b7-b6c0-0baf9714c7a2@redhat.com>

Better to use WildFly -secmgr option, instead of -Dsecurity.manager. 
 From what I recall, this helps avoid a boot time issue with 
-Dsecurity.manager.

For enabling javassist for a one off test run, simply prestart your 
WildFly app server with the desired options and then launch.

For more than a one off, find the arquillian.xml being used, for example 
wildfly/testsuite/integration/basic/src/test/config/arq/arquillian.xml 
and see if you can update the:

   <property name="javaVmArguments">${server.jvm.args}</property>

Perhaps you could try presetting setting server.jvm.args to 
-Dhibernate.bytecode.provider=javassist

Scott

On 08/27/2018 07:20 AM, Martin Simka wrote:
> Hi Gail,
> 
> mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
> -Dextra.server.jvm.args="-Dhibernate.bytecode.provider=javassist"
> -Dsecurity.manager=true
> 
> should do it. But I still see ByteBuddy in the stacktrace. I also tried to
> add property directly to WildFly configuration file or to hibernate.cfg.xml
> with the same result.
> 
> Martin
> 
> On Sat, Aug 25, 2018 at 11:28 PM Gail Badner <gbadner at redhat.com> wrote:
> 
>> To clarify, I'm trying to enable javassist on WildFly 14.
>>
>> On Fri, Aug 24, 2018 at 8:54 PM, Gail Badner <gbadner at redhat.com> wrote:
>>
>>> I tried running:
>>>
>>> mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
>>> -Dhibernate.bytecode.provider=javassist -Dsecurity.manager=true
>>>
>>> The result is a permissions failure, and ByteBuddy is in the stacktrace.
>>>
>>> I also tried adding the property to the StandardServiceRegistryBuilder
>>> built by SFSBHibernateSFNaturalId, and that didn't work either.
>>>
>>> Is there some other way to enable javassist?
>>>
>>> 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 guillaume.smet at gmail.com  Mon Aug 27 09:52:55 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 27 Aug 2018 15:52:55 +0200
Subject: [hibernate-dev] How to enable Javassist when running a WildFly
 unit test?
In-Reply-To: <a32ccfd5-3a82-f9b7-b6c0-0baf9714c7a2@redhat.com>
References: <CAFDzhiSCxZQ=pPh__Pz_BxAcBv+HMJsVPp96WKXpL9ux6kSDaA@mail.gmail.com>
	<CAFDzhiQV5v=SwBH5C2KzoWH+1UQSRAPVDmubb1cDJizWRx7d3g@mail.gmail.com>
	<CAEFmnWrt9TmfaG7gvh0Ha=BKtZS9PBqXJVdisda3OqEezV_EYw@mail.gmail.com>
	<a32ccfd5-3a82-f9b7-b6c0-0baf9714c7a2@redhat.com>
Message-ID: <CALt0+o-o-BXd=yztHaQZH=jrtXsxHhrA8d7R=RT=kedNSKiDnA@mail.gmail.com>

So, the system properties are not considered when running with the security
manager.

Log says:
Could not copy system properties, system properties will be ignored

And the code is the following:
try {
    Properties systemProperties = System.getProperties();
    // Must be thread-safe in case an application changes System properties
during Hibernate initialization.
    // See HHH-8383.
    synchronized ( systemProperties ) {
        GLOBAL_PROPERTIES.putAll( systemProperties );
    }
}
catch (SecurityException se) {
    LOG.unableToCopySystemProperties();
}

As the System.getProperties() call is not in a privileged block, it fails.

Not sure if it's a bug or a feature.

-- 
Guillaume

On Mon, Aug 27, 2018 at 3:18 PM Scott Marlow <smarlow at redhat.com> wrote:

> Better to use WildFly -secmgr option, instead of -Dsecurity.manager.
>  From what I recall, this helps avoid a boot time issue with
> -Dsecurity.manager.
>
> For enabling javassist for a one off test run, simply prestart your
> WildFly app server with the desired options and then launch.
>
> For more than a one off, find the arquillian.xml being used, for example
> wildfly/testsuite/integration/basic/src/test/config/arq/arquillian.xml
> and see if you can update the:
>
>    <property name="javaVmArguments">${server.jvm.args}</property>
>
> Perhaps you could try presetting setting server.jvm.args to
> -Dhibernate.bytecode.provider=javassist
>
> Scott
>
> On 08/27/2018 07:20 AM, Martin Simka wrote:
> > Hi Gail,
> >
> > mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
> > -Dextra.server.jvm.args="-Dhibernate.bytecode.provider=javassist"
> > -Dsecurity.manager=true
> >
> > should do it. But I still see ByteBuddy in the stacktrace. I also tried
> to
> > add property directly to WildFly configuration file or to
> hibernate.cfg.xml
> > with the same result.
> >
> > Martin
> >
> > On Sat, Aug 25, 2018 at 11:28 PM Gail Badner <gbadner at redhat.com> wrote:
> >
> >> To clarify, I'm trying to enable javassist on WildFly 14.
> >>
> >> On Fri, Aug 24, 2018 at 8:54 PM, Gail Badner <gbadner at redhat.com>
> wrote:
> >>
> >>> I tried running:
> >>>
> >>> mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
> >>> -Dhibernate.bytecode.provider=javassist -Dsecurity.manager=true
> >>>
> >>> The result is a permissions failure, and ByteBuddy is in the
> stacktrace.
> >>>
> >>> I also tried adding the property to the StandardServiceRegistryBuilder
> >>> built by SFSBHibernateSFNaturalId, and that didn't work either.
> >>>
> >>> Is there some other way to enable javassist?
> >>>
> >>> 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  Mon Aug 27 10:17:34 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 27 Aug 2018 09:17:34 -0500
Subject: [hibernate-dev] How to enable Javassist when running a WildFly
 unit test?
In-Reply-To: <a76346b8-9d70-8ca7-69dc-74826846d6bb@hibernate.org>
References: <CAFDzhiSCxZQ=pPh__Pz_BxAcBv+HMJsVPp96WKXpL9ux6kSDaA@mail.gmail.com>
	<a76346b8-9d70-8ca7-69dc-74826846d6bb@hibernate.org>
Message-ID: <CAFdSV9t-s5ohZa+wr=o1xsmi7RPDOL=NSFehYYMHAgzN4khBOQ@mail.gmail.com>

To clarify, `/hibernate.properties` (at root of class path) will work.
That one (if exists) is always read during boot.

On Mon, Aug 27, 2018 at 9:14 AM Chris Cranford <chris at hibernate.org> wrote:

> Technically the -D parameter should work; however I know a
> hibernate.properties file works.
>
> On 08/24/2018 11:54 PM, Gail Badner wrote:
> > I tried running:
> >
> > mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
> > -Dhibernate.bytecode.provider=javassist -Dsecurity.manager=true
> >
> > The result is a permissions failure, and ByteBuddy is in the stacktrace.
> >
> > I also tried adding the property to the StandardServiceRegistryBuilder
> > built by SFSBHibernateSFNaturalId, and that didn't work either.
> >
> > Is there some other way to enable javassist?
> >
> > 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 guillaume.smet at gmail.com  Mon Aug 27 11:46:27 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 27 Aug 2018 17:46:27 +0200
Subject: [hibernate-dev] How to enable Javassist when running a WildFly
 unit test?
In-Reply-To: <CALt0+o-o-BXd=yztHaQZH=jrtXsxHhrA8d7R=RT=kedNSKiDnA@mail.gmail.com>
References: <CAFDzhiSCxZQ=pPh__Pz_BxAcBv+HMJsVPp96WKXpL9ux6kSDaA@mail.gmail.com>
	<CAFDzhiQV5v=SwBH5C2KzoWH+1UQSRAPVDmubb1cDJizWRx7d3g@mail.gmail.com>
	<CAEFmnWrt9TmfaG7gvh0Ha=BKtZS9PBqXJVdisda3OqEezV_EYw@mail.gmail.com>
	<a32ccfd5-3a82-f9b7-b6c0-0baf9714c7a2@redhat.com>
	<CALt0+o-o-BXd=yztHaQZH=jrtXsxHhrA8d7R=RT=kedNSKiDnA@mail.gmail.com>
Message-ID: <CALt0+o8upob4ZktipCnVN-W6sjuXK16JwW8Lnzy8u4zcmm3a8Q@mail.gmail.com>

Gail,

About the issue you had with ByteBuddy + the SM, I opened
https://hibernate.atlassian.net/browse/HHH-12932 . I have a (simple) fix
for it ready.

-- 
Guillaume

On Mon, Aug 27, 2018 at 3:52 PM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> So, the system properties are not considered when running with the
> security manager.
>
> Log says:
> Could not copy system properties, system properties will be ignored
>
> And the code is the following:
> try {
>     Properties systemProperties = System.getProperties();
>     // Must be thread-safe in case an application changes System
> properties during Hibernate initialization.
>     // See HHH-8383.
>     synchronized ( systemProperties ) {
>         GLOBAL_PROPERTIES.putAll( systemProperties );
>     }
> }
> catch (SecurityException se) {
>     LOG.unableToCopySystemProperties();
> }
>
> As the System.getProperties() call is not in a privileged block, it fails.
>
> Not sure if it's a bug or a feature.
>
> --
> Guillaume
>
> On Mon, Aug 27, 2018 at 3:18 PM Scott Marlow <smarlow at redhat.com> wrote:
>
>> Better to use WildFly -secmgr option, instead of -Dsecurity.manager.
>>  From what I recall, this helps avoid a boot time issue with
>> -Dsecurity.manager.
>>
>> For enabling javassist for a one off test run, simply prestart your
>> WildFly app server with the desired options and then launch.
>>
>> For more than a one off, find the arquillian.xml being used, for example
>> wildfly/testsuite/integration/basic/src/test/config/arq/arquillian.xml
>> and see if you can update the:
>>
>>    <property name="javaVmArguments">${server.jvm.args}</property>
>>
>> Perhaps you could try presetting setting server.jvm.args to
>> -Dhibernate.bytecode.provider=javassist
>>
>> Scott
>>
>> On 08/27/2018 07:20 AM, Martin Simka wrote:
>> > Hi Gail,
>> >
>> > mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
>> > -Dextra.server.jvm.args="-Dhibernate.bytecode.provider=javassist"
>> > -Dsecurity.manager=true
>> >
>> > should do it. But I still see ByteBuddy in the stacktrace. I also tried
>> to
>> > add property directly to WildFly configuration file or to
>> hibernate.cfg.xml
>> > with the same result.
>> >
>> > Martin
>> >
>> > On Sat, Aug 25, 2018 at 11:28 PM Gail Badner <gbadner at redhat.com>
>> wrote:
>> >
>> >> To clarify, I'm trying to enable javassist on WildFly 14.
>> >>
>> >> On Fri, Aug 24, 2018 at 8:54 PM, Gail Badner <gbadner at redhat.com>
>> wrote:
>> >>
>> >>> I tried running:
>> >>>
>> >>> mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
>> >>> -Dhibernate.bytecode.provider=javassist -Dsecurity.manager=true
>> >>>
>> >>> The result is a permissions failure, and ByteBuddy is in the
>> stacktrace.
>> >>>
>> >>> I also tried adding the property to the StandardServiceRegistryBuilder
>> >>> built by SFSBHibernateSFNaturalId, and that didn't work either.
>> >>>
>> >>> Is there some other way to enable javassist?
>> >>>
>> >>> 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  Tue Aug 28 09:16:54 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 28 Aug 2018 15:16:54 +0200
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o-ek8aV5SD2h=c3JiR_3c6zDeEfx-3CTgi6fn+c3QoE8A@mail.gmail.com>

Hi,

Here are the minutes of this week's meeting.

Bot is on PTO so I copy/paste everything below:

15:01 < gsmet> #topic Progress Fabio
15:01 < fax4ever> Hi all
15:01 < fax4ever> I've come back yesterday from holidays,
15:01 < fax4ever> so I was most of the time on holiday in the last two
weeks.
15:01 < fax4ever> I resumed to work on the issue that I left pending.
15:01 < fax4ever> The one to make no longer mandatory the persistence
provider.
15:01 < fax4ever> We had a good meeting on this topic just before my
vacations with Davide and Sanne,
15:02 < fax4ever> where Sanne pointed out a possible *nice* solution.
15:02 < fax4ever> The solution would require to change some code in
Hibernate ORM too, in order to solve the issue.
15:02 < fax4ever> The good news is that the ORM provider class
`HibernatePersistenceProvider`:
15:02 < fax4ever> is currently capable to handle perfectly the OGM's cases
too.
15:02 < fax4ever> I made some test and I discovered that if the property
`hibernate.ogm.enabled` is set to `true`,
15:02 < fax4ever> this class might active OGM's cases without any need of
the OGM provider class:
15:02 < fax4ever> `HibernateOgmPersistence`.
15:02 < fax4ever> Then I think that most part of the job has been already
done.
15:03 < fax4ever> That's all about my progress. Thank you!
15:03 < gsmet> thanks
15:03 < gsmet> #topic Next 2 weeks Fabio
15:03 < fax4ever> Firstly, I'm implementing the `persistence provider`
issue.
15:03 < fax4ever> For the reasons that I've explained before,
15:03 < fax4ever> I think that we'll need a very limited change of code on
both OGM and ORM projects.
15:03 < fax4ever> Secondly, I believe that the priority will be the
OGM/Infinispan presentation on September,
15:03 < fax4ever> arranged by Paolo Menon.
15:04 < fax4ever> Therefore I'm going to spend some time on Hibernate demo
project.
15:04 < fax4ever> Thirdly, I might spent some time on minor issues,
15:04 < fax4ever> such as adding more tests on Java time mapping and so on.
15:04 < fax4ever> Fourthly, I would like to spend other time to review some
PRs.
15:04 < fax4ever> Fifthly, I don't know if a new release is scheduled, in
case it is, I could help to handle it.
15:04 < fax4ever> Finally, after next two weeks I will be on PTOs again,
just for one week.
15:04 < fax4ever> That's all about my next two weeks. Thank you!
15:05 < gsmet> thanks Fabio
15:05 < gsmet> #topic Progress Guillaume
15:05 < gsmet> so a good part of my last 2 weeks was the Search F2F
15:05 < gsmet> we made some good progress there but I'll let Yoann give
more details if he sees fit
15:06 < gsmet> I also released a new HV for inclusion in WF 14 due to a few
issues
15:06 < gsmet> and continued to coordinates the ORM 5.3 work
15:06 < gsmet> we are discussing some patches related to the security
manager right now
15:06 < gsmet> discussing means me sending emails and not getting answers :)
15:07 < gsmet> other than that I made some progress on the projection DSL
for Search 6
15:07 < gsmet> but we decided some big changes in it so I'll get back to it
to stick to what we decided
15:07 < gsmet> #topic Next 2 weeks Guillaume
15:08 < gsmet> so hopefully mostly Search 6 with some ORM coordination
15:08 < gsmet> I say that every 2 weeks so we'll see
15:08 < gsmet> FYI, PTO for me starting Sept 14th
15:09 < gsmet> for a week
15:09 < gsmet> #topic Progress Yoann
15:09 < yrodiere> So, I was on PTO the first week
15:09 < yrodiere> Good progress on the babysitting side
15:09 < yrodiere> then it was the F2F
15:09 < yrodiere> No, I won't say it was babysitting too :)
15:10 < yrodiere> Joke aside, we actually made good progress, took lots of
decisions on pending topics
15:10 < fax4ever> :)
15:10 < yrodiere> and actually managed to cover the whole agenda
15:10 < yrodiere> so... It means there's a lot more to work on now than
before. Which I guess is good news :)
15:11 < yrodiere> I won't cover the specifics, but I'm currently organizing
everything as JIRA tickets
15:11 < yrodiere> see
https://hibernate.atlassian.net/login?dest-url=%2Fprojects%2FHSEARCH%3FselectedItem%3Dcom.atlassian.jira.jira-projects-plugin%3Arelease-page
15:12 < yrodiere> so, next two weeks
15:12 < gsmet> #topic Next 2 weeks Yoann
15:12 < yrodiere> there are still a few tickets, mainly refactoring, to
address, and then we should be able to merge the Search 6 prototype into
the main Search repository
15:13 < yrodiere> that should be the big news of the next two weeks...
hopefully.
15:13 < yrodiere> after that there is still a bit of polishing to do, and
we should be able to release an Alpha1 in one or two months at most
15:14 < yrodiere> then I hope we'll be able to follow a more...
"high-paced" rhythm, to provide sneak peaks into the current work to our
users
15:14 < yrodiere> that's all from me

From yoann at hibernate.org  Wed Aug 29 08:12:51 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Wed, 29 Aug 2018 14:12:51 +0200
Subject: [hibernate-dev] Re-enabling the BlueOcean interface in Jenkins
In-Reply-To: <CAEqagpqY9YTmKc71jsrJN+vW+w1gtTFhsCgQmNWc0kNNfdqMPg@mail.gmail.com>
References: <CAEqagpqUyXdNrL8_70whGaxEa29-VkAgeD-LsC6zC7-S6-PhfA@mail.gmail.com>
	<CAFm4XO3eOvmtSWNtWEEdqA3mvr0m_ZGE6XAHEqNVLPsZTboFjQ@mail.gmail.com>
	<CAEqagpqY9YTmKc71jsrJN+vW+w1gtTFhsCgQmNWc0kNNfdqMPg@mail.gmail.com>
Message-ID: <CAEqagppw8r8j87reSNk3HgyMufKFDr2Zqs-hTYTBbDyxBV=2iQ@mail.gmail.com>

Just in case someone is annoyed by the notification URL now pointing to the
BlueOcean interface: there is a setting in your account preferences in
Jenkins allowing you to choose between the BlueOcean URL or the classic URL.

See http://ci.hibernate.org/user/<your ID>/configure => "Notification URL"

I didn't try it, but it's worth a shot.

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


On Mon, 27 Aug 2018 at 10:15, Yoann Rodiere <yoann at hibernate.org> wrote:

> Since there was no objections, I re-enabled BlueOcean.
>
> See an example here:
> http://ci.hibernate.org/blue/organizations/jenkins/hibernate-search-6-poc/detail/HSEARCH-3239/142/pipeline
>
> When in the BlueOcean interface, you can go back to the classic interface
> using the button circled in red in this screen capture:
> https://i.imgur.com/lAck9GM.png
>
> Yoann Rodi?re
> Hibernate NoORM Team
> yoann at hibernate.org
>
>
> On Thu, 2 Aug 2018 at 18:59, Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> +1
>>
>> I think we can live with minor inconveniences, especially as I hope
>> we'll be moving more projects to take advantage of the pipelines.
>>
>> On Thu, 2 Aug 2018 at 17:56, Yoann Rodiere <yoann at hibernate.org> wrote:
>> >
>> > Hi,
>> >
>> > We're about to make use of Jenkins pipelines in Hibernate Search, and
>> for
>> > that purpose, the BlueOcean is much easier to read. So I'd like to
>> > re-enable it.
>> >
>> > This should not affect other projects much, as the default interface
>> when
>> > you go to ci.hibernate.org will still be the "old" one. However, this
>> will
>> > unfortunately change the URL in emails sent by Jenkins so that the URL
>> > points to the BlueOcean interface; and unfortunately, there doesn't
>> seem to
>> > be a way around that. You do have a button on the top right of the
>> > BlueOcean interface to go back to the "old" interface, though.
>> >
>> > For anyone wondering, this
>> > <https://plugins.jenkins.io/blueocean-display-url> is the plugin
>> > responsible for this behavior, and we can't uninstall it as long as
>> > BlueOcean is installed.
>> >
>> > Given the inconvenience is minor, and pipeline logs are pretty much
>> > unreadable without the interface (seriously, good luck spotting the
>> problem
>> > in this
>> > <
>> http://ci.hibernate.org/view/Search/job/hibernate-search-6-poc/job/HSEARCH-3239/142/flowGraphTable/
>> >),
>> > is it alright for everyone if I re-enable the BlueOcean interface?
>> >
>> > Yoann Rodi?re
>> > Hibernate NoORM Team
>> > yoann at hibernate.org
>> > _______________________________________________
>> > 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 Aug 29 08:53:21 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 29 Aug 2018 14:53:21 +0200
Subject: [hibernate-dev] Re-enabling the BlueOcean interface in Jenkins
In-Reply-To: <CAEqagppw8r8j87reSNk3HgyMufKFDr2Zqs-hTYTBbDyxBV=2iQ@mail.gmail.com>
References: <CAEqagpqUyXdNrL8_70whGaxEa29-VkAgeD-LsC6zC7-S6-PhfA@mail.gmail.com>
	<CAFm4XO3eOvmtSWNtWEEdqA3mvr0m_ZGE6XAHEqNVLPsZTboFjQ@mail.gmail.com>
	<CAEqagpqY9YTmKc71jsrJN+vW+w1gtTFhsCgQmNWc0kNNfdqMPg@mail.gmail.com>
	<CAEqagppw8r8j87reSNk3HgyMufKFDr2Zqs-hTYTBbDyxBV=2iQ@mail.gmail.com>
Message-ID: <CALt0+o9G56acUPixFsRwTNe_npYvkAx-V_mC5yNAowzS74awqw@mail.gmail.com>

On Wed, Aug 29, 2018 at 2:32 PM Yoann Rodiere <yoann at hibernate.org> wrote:

> Just in case someone is annoyed by the notification URL now pointing to the
> BlueOcean interface: there is a setting in your account preferences in
> Jenkins allowing you to choose between the BlueOcean URL or the classic
> URL.
>

Very helpful, thanks!

From gbadner at redhat.com  Thu Aug 30 18:47:30 2018
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 30 Aug 2018 15:47:30 -0700
Subject: [hibernate-dev] Hibernate ORM 5.1.16.Final released
Message-ID: <CAFDzhiSX5MUJib-WHwbWq8A_fZ6p+0mMO7fWSe6D7NCXubdmFg@mail.gmail.com>

http://in.relation.to/2018/08/30/hibernate-orm-5116-final-release/

From gbadner at redhat.com  Fri Aug 31 16:29:37 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 31 Aug 2018 13:29:37 -0700
Subject: [hibernate-dev] @OneToOne with @PrimaryKeyJoinColumn(s) vs @MapsId
	without value element
Message-ID: <CAFDzhiR8B+VoPoWxRZb18H7cYveMtAd8ubDuiQ+SPEQ6ubKTEg@mail.gmail.com>

The fix for HHH-12436 involves correcting the foreign key direction for
"real" one-to-one associations. I've been looking into the ramifications of
this change because I'm concerned that applications can rely on the old
(incorrect) foreign key direction.

In the process I've found that Hibernate treats:

@OneToOne
@PrimaryKeyJoinColumn
private Employee employee;

differently from:

@OneToOne
@MapsId
private Employee employee;

I believe they should be treated consistently. You can see my reasoning
below. [1]

Before going into details about how they are treated differently, I'd like
to  get confirmation, in case I am missing some subtlety.

Could someone please confirm this?

Regards,
Gail

---------------------------------------------------------------------------------------------
[1]

In 2.4.1.3 Examples of Derived Identities, Example 4(b) uses MapsId without
the value element as follows:

@MapsId
@JoinColumn(name="FK")
@OneToOne Person patient;

This example has the following footnote:
"[15] Note that the use of PrimaryKeyJoinColumn instead of MapsId would
result in the same mapping in this example. Use of MapsId
is preferred for the mapping of derived identities."

The description has a footnote that says that using PrimaryKeyJoinColumn
instead of MapsId would result in the same mapping.

In 11.1.45 PrimaryKeyJoinColumns Annotation, Example 2 uses
@PrimaryKeyJoinColumns as follows:

@OneToOne
@PrimaryKeyJoinColumns({
        @PrimaryKeyJoinColumn(name="ID",
                              referencedColumnName="EMP_ID"),
        @PrimaryKeyJoinColumn(name="NAME",
                              referencedColumnName="EMP_NAME")})
EmployeeInfo info;

This example has the following footnote:
"[123]Note that the derived identity mechanisms decribed in section 2.4.1.1
is now preferred to the use of PrimaryKeyJoinColumn for
this case."