[hibernate-dev] JDK 11 is now in Rampdown Phase one

[Rory O'Donnell]

Hi Sanne,

*JDK 11 is now in Rampdown Phase one***
The overall feature set is frozen. No further JEPs will be targeted to 
this release.We’ve forked the main-line source repository, jdk/jdk, to 
the jdk/jdk11 stabilization repository. Any changes pushed to jdk/jdk or 
jdk/client are now bound for JDK 12.

  * For more details , see Mark Reinhold's email to jdk-dev mailing list
[1]
  * The Rampdown Phase one process  [2].

*Note: -* Early-Access build archive format on Windows has changed to zip.

Since our last email the following JEPs have been targeted to JDK 11 :

  * 181: Nest-Based Access Control
  * 315: Improve Aarch64 Intrinsics
  * 330: Launch Single-File Source-Code Programs
  * 331: Low-Overhead Heap Profiling
  * 332: Transport Layer Security (TLS) 1.3
  * 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
  * 335: *Deprecate the Nashorn JavaScript Engine*
  * 336: *Deprecate the Pack200 Tools and API*

Other important changes since last email:

Build 19:
JDK-8205043  : G1
enables adaptive parallel reference processing by default
Build 18:
JDK-8196141  : Add
GoDaddy root certificates
JDK-8204243  :
*remove Thread.destroy() and Thread.stop(Throwable)*
JDK-8202088  :
Japanese New Era Implementation
Build 17:
JDK-8189949  :
Remove Baltimore Cybertrust Code Signing CA
JDK-8191031  :
Remove several Symantec Root CAs
JDK-8072996  :
Deprecate stream-based GSSContext methods
Build 16:
JDK-8191844  :
Remove SECOM root

Rgds, Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001509.html
[2] http://openjdk.java.net/projects/jdk/11/#Schedule
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] 5.3 cache issues [Requires Steve]

[Guillaume Smet]

Hi all,

So following our off-list discussions , I wanted to share a document we
wrote with Yoann with some details about the usability/compatibility of the
new cache implementation in 5.3:
https://docs.google.com/document/d/19xmsWlYOkXeAnZlEjcxFy6SUitxmT1JywoDyX22TrvE/edit?usp=sharing

(The document should be public and everyone should be able to comment)

We tried to be as detailed as possible. What we need to decide is in
bold/red as Actions.

The idea is to act on it for 5.3.2 so before Thursday. The PR for the first
issue is mostly ready but will require some tuning depending on our
decisions, we still need to work on the second one depending on the outcome.

Everyone interested/concerned, please step in so that we can reach a
consensus quickly and merge what is appropriate.

Thanks!

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 5.3 cache issues [Requires Steve]

[Steve Ebersole]

Changing the name of the default query results cache I can see being a
problem in retrospect.  That is something the user might want to
configure.

I am much less convinced about the update-timestamps cache.  I guess it
would depend on what they are configuring.

Overall what I would suggest is a hybrid approach where we move to a "short
name" solution much like we have for most other config values.  So, e.g.,
the name of the default query result region would be
`default-query-result-region`.  We could then have the providers understand
that "magic value" and have them look for configs under either names they
wish (temporarily which Emmanuel suggested, if that's what we want) - we'd
change our OOTB providers to look for all three names.

On Mon, Jul 2, 2018 at 10:12 AM Guillaume Smet 
wrote:

> Hi all,
>
> So following our off-list discussions , I wanted to share a document we
> wrote with Yoann with some details about the usability/compatibility of the
> new cache implementation in 5.3:
>
> https://docs.google.com/document/d/19xmsWlYOkXeAnZlEjcxFy6SUitxmT1JywoDyX22TrvE/edit?usp=sharing
>
> (The document should be public and everyone should be able to comment)
>
> We tried to be as detailed as possible. What we need to decide is in
> bold/red as Actions.
>
> The idea is to act on it for 5.3.2 so before Thursday. The PR for the first
> issue is mostly ready but will require some tuning depending on our
> decisions, we still need to work on the second one depending on the
> outcome.
>
> Everyone interested/concerned, please step in so that we can reach a
> consensus quickly and merge what is appropriate.
>
> Thanks!
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] ORM progress: tricky branch state

[Sanne Grinovero]

On Hibernate ORM we're currently having "master" branch essentially
being a maintenance branch, aka master today is what's planned to be
version 5.3.2.Final in some days, 5.3.3 later, etc..

This is quite unusual, and it begs some extra attention: normally we'd
start a new minor in master, so that PRs of any kind could be welcome
in master, while specific, cherry-picked fixes are backported to the
last maintained minors.

This is not the case now and until we move on to a new minor or major
we'll need to be particularly careful about what is allowed to be
merged.
I'm not pointing fingers to any specific commit, my concern is just
raised by the high volume of changes being merged. They all look great
individually but changes are not good at this point :)

Not sure what to suggest to people wanting to contribute new features
today; maybe hold as we assume the 6.0 work will be merged in master
soon? Will be hard to say no to many reasonable requests though.

Steve, do you think that the 6.0 merge could happen soon enough to not
need any process changes in how  we deal with master?

Thanks,
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM progress: tricky branch state

[Vlad Mihalcea]

If 5.3 cannot take new features, it's better to branch it and have a 5.4
branch for the master until 6.0 is ready.

There are lots of interesting improvements that are provided via PRs or as
suggestions on  the forum, so it would be detrimental to our users to delay
those until 6.0 can be used in production.

Vlad

On Mon, 2 Jul 2018, 18:48 Sanne Grinovero,  wrote:

> On Hibernate ORM we're currently having "master" branch essentially
> being a maintenance branch, aka master today is what's planned to be
> version 5.3.2.Final in some days, 5.3.3 later, etc..
>
> This is quite unusual, and it begs some extra attention: normally we'd
> start a new minor in master, so that PRs of any kind could be welcome
> in master, while specific, cherry-picked fixes are backported to the
> last maintained minors.
>
> This is not the case now and until we move on to a new minor or major
> we'll need to be particularly careful about what is allowed to be
> merged.
> I'm not pointing fingers to any specific commit, my concern is just
> raised by the high volume of changes being merged. They all look great
> individually but changes are not good at this point :)
>
> Not sure what to suggest to people wanting to contribute new features
> today; maybe hold as we assume the 6.0 work will be merged in master
> soon? Will be hard to say no to many reasonable requests though.
>
> Steve, do you think that the 6.0 merge could happen soon enough to not
> need any process changes in how  we deal with master?
>
> Thanks,
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM progress: tricky branch state

[Guillaume Smet]

Hi Sanne,

On Mon, Jul 2, 2018 at 5:48 PM Sanne Grinovero  wrote:

> Not sure what to suggest to people wanting to contribute new features
> today; maybe hold as we assume the 6.0 work will be merged in master
> soon? Will be hard to say no to many reasonable requests though.
>

IMHO, there are 2 types of contributions:
1/ real new features that people want for the future: this could go in 6,
once it's in the appropriate state: we had a few cleanup contributions
lately or explorations in new areas;
2/ things that are questionably bad ORM behaviors (not really bugs but
still) that people would like to have integrated in the very near future as
it's a real problem for them.

As for 1/, I don't know how the merge to 6 is done: e.g. if we could have a
"5.4" on master we would never release but where we could merge new
features that would be integrated in 6 in the final merge or if we'd better
wait and avoid changes as much as possible. In any case, we should probably
decide something and communicate clearly about it.

It's not easy to draw the line for 2/. I have a few PRs in mind that enters
this category and that I would prefer to merge sooner rather than later
(this to have some feedback from the field before the WildFly 14 release).
Yes, https://github.com/hibernate/hibernate-orm/pull/2383 , I'm looking at
you: we do a very bad job currently and with the OpenBravo model (the
contributor is from OpenBravo), any criteria query is terribly slow. It's
not exactly a bug as the query in the end will succeed and gives the
correct result but it's definitely something that is not working as
expected. Personally, I consider it as something I would want in 5.3.2 but
YMMV.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM progress: tricky branch state

[Steve Ebersole]

I think I have pointed out before that such a schedule is already posted :
https://github.com/sebersole/hibernate-core/blob/wip/6.0/design/6.0-todo.adoc#alpha1

The important part remaining is really collection support.

There are a few listed there that we'd be willing to push to the next Alpha

On Mon, Jul 2, 2018 at 10:42 AM Sanne Grinovero  wrote:

> On Hibernate ORM we're currently having "master" branch essentially
> being a maintenance branch, aka master today is what's planned to be
> version 5.3.2.Final in some days, 5.3.3 later, etc..
>
> This is quite unusual, and it begs some extra attention: normally we'd
> start a new minor in master, so that PRs of any kind could be welcome
> in master, while specific, cherry-picked fixes are backported to the
> last maintained minors.
>
> This is not the case now and until we move on to a new minor or major
> we'll need to be particularly careful about what is allowed to be
> merged.
> I'm not pointing fingers to any specific commit, my concern is just
> raised by the high volume of changes being merged. They all look great
> individually but changes are not good at this point :)
>
> Not sure what to suggest to people wanting to contribute new features
> today; maybe hold as we assume the 6.0 work will be merged in master
> soon? Will be hard to say no to many reasonable requests though.
>
> Steve, do you think that the 6.0 merge could happen soon enough to not
> need any process changes in how  we deal with master?
>
> Thanks,
> Sanne
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 5.3 cache issues [Requires Steve]

[Guillaume Smet]

Hi Steve,

Glad to have you back! Hope yo got some rest.

On Mon, Jul 2, 2018 at 5:28 PM Steve Ebersole  wrote:

> Overall what I would suggest is a hybrid approach where we move to a
> "short name" solution much like we have for most other config values.  So,
> e.g., the name of the default query result region would be
> `default-query-result-region`.  We could then have the providers understand
> that "magic value" and have them look for configs under either names they
> wish (temporarily which Emmanuel suggested, if that's what we want) - we'd
> change our OOTB providers to look for all three names.
>

Sounds like something we could do, given we implement the compatibility
layer. We would need a new release of the Infinispan region factory to
provide the compatibility layer there.

Any comment on the first issue (the new requirement to declare all the
caches)?

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM progress: tricky branch state

[Steve Ebersole]

I don't mind creating a 5.3 branch, and having master for "after 5.3"
development with 6.0 hopefully merged in there soon.

On Mon, Jul 2, 2018 at 11:23 AM Steve Ebersole  wrote:

> I think I have pointed out before that such a schedule is already posted :
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/design/6.0-todo.adoc#alpha1
>
> The important part remaining is really collection support.
>
> There are a few listed there that we'd be willing to push to the next
> Alpha
>
> On Mon, Jul 2, 2018 at 10:42 AM Sanne Grinovero 
> wrote:
>
>> On Hibernate ORM we're currently having "master" branch essentially
>> being a maintenance branch, aka master today is what's planned to be
>> version 5.3.2.Final in some days, 5.3.3 later, etc..
>>
>> This is quite unusual, and it begs some extra attention: normally we'd
>> start a new minor in master, so that PRs of any kind could be welcome
>> in master, while specific, cherry-picked fixes are backported to the
>> last maintained minors.
>>
>> This is not the case now and until we move on to a new minor or major
>> we'll need to be particularly careful about what is allowed to be
>> merged.
>> I'm not pointing fingers to any specific commit, my concern is just
>> raised by the high volume of changes being merged. They all look great
>> individually but changes are not good at this point :)
>>
>> Not sure what to suggest to people wanting to contribute new features
>> today; maybe hold as we assume the 6.0 work will be merged in master
>> soon? Will be hard to say no to many reasonable requests though.
>>
>> Steve, do you think that the 6.0 merge could happen soon enough to not
>> need any process changes in how  we deal with master?
>>
>> Thanks,
>> Sanne
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM progress: tricky branch state

[Sanne Grinovero]

On Mon, 2 Jul 2018 at 17:34, Steve Ebersole  wrote:
>
> I don't mind creating a 5.3 branch, and having master for "after 5.3" 
> development with 6.0 hopefully merged in there soon.

+1 that sounds like the best option we have. It's not extremely
urgent, we can do this after 5.3.2 ?

Just making sure we tighten up the process a bit when we start merging
all "compatibility fixes" in WildFly 14, yet not too soon to not waste
too much time backporting everything.

Thanks!
Sanne

>
> On Mon, Jul 2, 2018 at 11:23 AM Steve Ebersole  wrote:
>>
>> I think I have pointed out before that such a schedule is already posted : 
>> https://github.com/sebersole/hibernate-core/blob/wip/6.0/design/6.0-todo.adoc#alpha1
>>
>> The important part remaining is really collection support.
>>
>> There are a few listed there that we'd be willing to push to the next Alpha
>>
>> On Mon, Jul 2, 2018 at 10:42 AM Sanne Grinovero  wrote:
>>>
>>> On Hibernate ORM we're currently having "master" branch essentially
>>> being a maintenance branch, aka master today is what's planned to be
>>> version 5.3.2.Final in some days, 5.3.3 later, etc..
>>>
>>> This is quite unusual, and it begs some extra attention: normally we'd
>>> start a new minor in master, so that PRs of any kind could be welcome
>>> in master, while specific, cherry-picked fixes are backported to the
>>> last maintained minors.
>>>
>>> This is not the case now and until we move on to a new minor or major
>>> we'll need to be particularly careful about what is allowed to be
>>> merged.
>>> I'm not pointing fingers to any specific commit, my concern is just
>>> raised by the high volume of changes being merged. They all look great
>>> individually but changes are not good at this point :)
>>>
>>> Not sure what to suggest to people wanting to contribute new features
>>> today; maybe hold as we assume the 6.0 work will be merged in master
>>> soon? Will be hard to say no to many reasonable requests though.
>>>
>>> Steve, do you think that the 6.0 merge could happen soon enough to not
>>> need any process changes in how  we deal with master?
>>>
>>> Thanks,
>>> Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM progress: tricky branch state

[Gail Badner]

+1 on creating a 5.3 branch, with master being used for 5.4 (or 6.0).

On Mon, Jul 2, 2018 at 9:43 AM, Sanne Grinovero  wrote:

> On Mon, 2 Jul 2018 at 17:34, Steve Ebersole  wrote:
> >
> > I don't mind creating a 5.3 branch, and having master for "after 5.3"
> development with 6.0 hopefully merged in there soon.
>
> +1 that sounds like the best option we have. It's not extremely
> urgent, we can do this after 5.3.2 ?
>
> Just making sure we tighten up the process a bit when we start merging
> all "compatibility fixes" in WildFly 14, yet not too soon to not waste
> too much time backporting everything.
>
> Thanks!
> Sanne
>
> >
> > On Mon, Jul 2, 2018 at 11:23 AM Steve Ebersole 
> wrote:
> >>
> >> I think I have pointed out before that such a schedule is already
> posted : https://github.com/sebersole/hibernate-core/blob/wip/6.0/
> design/6.0-todo.adoc#alpha1
> >>
> >> The important part remaining is really collection support.
> >>
> >> There are a few listed there that we'd be willing to push to the next
> Alpha
> >>
> >> On Mon, Jul 2, 2018 at 10:42 AM Sanne Grinovero 
> wrote:
> >>>
> >>> On Hibernate ORM we're currently having "master" branch essentially
> >>> being a maintenance branch, aka master today is what's planned to be
> >>> version 5.3.2.Final in some days, 5.3.3 later, etc..
> >>>
> >>> This is quite unusual, and it begs some extra attention: normally we'd
> >>> start a new minor in master, so that PRs of any kind could be welcome
> >>> in master, while specific, cherry-picked fixes are backported to the
> >>> last maintained minors.
> >>>
> >>> This is not the case now and until we move on to a new minor or major
> >>> we'll need to be particularly careful about what is allowed to be
> >>> merged.
> >>> I'm not pointing fingers to any specific commit, my concern is just
> >>> raised by the high volume of changes being merged. They all look great
> >>> individually but changes are not good at this point :)
> >>>
> >>> Not sure what to suggest to people wanting to contribute new features
> >>> today; maybe hold as we assume the 6.0 work will be merged in master
> >>> soon? Will be hard to say no to many reasonable requests though.
> >>>
> >>> Steve, do you think that the 6.0 merge could happen soon enough to not
> >>> need any process changes in how  we deal with master?
> >>>
> >>> Thanks,
> >>> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 5.3 cache issues [Requires Steve]

[Steve Ebersole]

1) That was specifically requested
2) This is easily handled by the providers, if they wish.  They would
simply map any undefined regions/caches to a pre-defined one (probably
after warning the user).  Keep in mind that region != cache.  A provider
might map multiple region names to a single cache.  That was always the
case, but every provider mapped region <-> cache as 1-1 - the new API makes
this much more clear.

Personally I think that not allowing on-the-fly creation is a good idea,
though maybe it can be made configurable.

On Mon, Jul 2, 2018 at 11:18 AM Guillaume Smet 
wrote:

> Hi Steve,
>
> Glad to have you back! Hope yo got some rest.
>
> On Mon, Jul 2, 2018 at 5:28 PM Steve Ebersole  wrote:
>
>> Overall what I would suggest is a hybrid approach where we move to a
>> "short name" solution much like we have for most other config values.  So,
>> e.g., the name of the default query result region would be
>> `default-query-result-region`.  We could then have the providers understand
>> that "magic value" and have them look for configs under either names they
>> wish (temporarily which Emmanuel suggested, if that's what we want) - we'd
>> change our OOTB providers to look for all three names.
>>
>
> Sounds like something we could do, given we implement the compatibility
> layer. We would need a new release of the Infinispan region factory to
> provide the compatibility layer there.
>
> Any comment on the first issue (the new requirement to declare all the
> caches)?
>
> --
> Guillaume
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 5.3 cache issues [Requires Steve]

[Vlad Mihalcea]

The short name approach sounds goid and would accommodate any future cache
region implementation changes.

For 5.3, I'd say we allow the old named to be resolved to the new ones,
like symbolic links.

This will allow users to migrate to 5.3 without changing existing
ehcache.xml configs.

We could write a log WARN for 5.3 and stop supporting old region names in
6.x.

Vlad



On Mon, 2 Jul 2018, 23:00 Steve Ebersole,  wrote:

> Changing the name of the default query results cache I can see being a
> problem in retrospect.  That is something the user might want to
> configure.
>
> I am much less convinced about the update-timestamps cache.  I guess it
> would depend on what they are configuring.
>
> Overall what I would suggest is a hybrid approach where we move to a "short
> name" solution much like we have for most other config values.  So, e.g.,
> the name of the default query result region would be
> `default-query-result-region`.  We could then have the providers understand
> that "magic value" and have them look for configs under either names they
> wish (temporarily which Emmanuel suggested, if that's what we want) - we'd
> change our OOTB providers to look for all three names.
>
> On Mon, Jul 2, 2018 at 10:12 AM Guillaume Smet 
> wrote:
>
> > Hi all,
> >
> > So following our off-list discussions , I wanted to share a document we
> > wrote with Yoann with some details about the usability/compatibility of
> the
> > new cache implementation in 5.3:
> >
> >
> https://docs.google.com/document/d/19xmsWlYOkXeAnZlEjcxFy6SUitxmT1JywoDyX22TrvE/edit?usp=sharing
> >
> > (The document should be public and everyone should be able to comment)
> >
> > We tried to be as detailed as possible. What we need to decide is in
> > bold/red as Actions.
> >
> > The idea is to act on it for 5.3.2 so before Thursday. The PR for the
> first
> > issue is mostly ready but will require some tuning depending on our
> > decisions, we still need to work on the second one depending on the
> > outcome.
> >
> > Everyone interested/concerned, please step in so that we can reach a
> > consensus quickly and merge what is appropriate.
> >
> > Thanks!
> >
> > --
> > Guillaume
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 5.3 cache issues [Requires Steve]

[Steve Ebersole]

Yes, what you describe is exactly the hybrid approach I suggested.

On Mon, Jul 2, 2018 at 3:52 PM Vlad Mihalcea 
wrote:

> The short name approach sounds goid and would accommodate any future cache
> region implementation changes.
>
> For 5.3, I'd say we allow the old named to be resolved to the new ones,
> like symbolic links.
>
> This will allow users to migrate to 5.3 without changing existing
> ehcache.xml configs.
>
> We could write a log WARN for 5.3 and stop supporting old region names in
> 6.x.
>
> Vlad
>
>
>
> On Mon, 2 Jul 2018, 23:00 Steve Ebersole,  wrote:
>
>> Changing the name of the default query results cache I can see being a
>> problem in retrospect.  That is something the user might want to
>> configure.
>>
>> I am much less convinced about the update-timestamps cache.  I guess it
>> would depend on what they are configuring.
>>
>> Overall what I would suggest is a hybrid approach where we move to a
>> "short
>> name" solution much like we have for most other config values.  So, e.g.,
>> the name of the default query result region would be
>> `default-query-result-region`.  We could then have the providers
>> understand
>> that "magic value" and have them look for configs under either names they
>> wish (temporarily which Emmanuel suggested, if that's what we want) - we'd
>> change our OOTB providers to look for all three names.
>>
>> On Mon, Jul 2, 2018 at 10:12 AM Guillaume Smet 
>> wrote:
>>
>> > Hi all,
>> >
>> > So following our off-list discussions , I wanted to share a document we
>> > wrote with Yoann with some details about the usability/compatibility of
>> the
>> > new cache implementation in 5.3:
>> >
>> >
>> https://docs.google.com/document/d/19xmsWlYOkXeAnZlEjcxFy6SUitxmT1JywoDyX22TrvE/edit?usp=sharing
>> >
>> > (The document should be public and everyone should be able to comment)
>> >
>> > We tried to be as detailed as possible. What we need to decide is in
>> > bold/red as Actions.
>> >
>> > The idea is to act on it for 5.3.2 so before Thursday. The PR for the
>> first
>> > issue is mostly ready but will require some tuning depending on our
>> > decisions, we still need to work on the second one depending on the
>> > outcome.
>> >
>> > Everyone interested/concerned, please step in so that we can reach a
>> > consensus quickly and merge what is appropriate.
>> >
>> > Thanks!
>> >
>> > --
>> > Guillaume
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM progress: tricky branch state

[andrea boriero]

+1 for 5.3 branch

On Mon, 2 Jul 2018, 19:05 Gail Badner,  wrote:

> +1 on creating a 5.3 branch, with master being used for 5.4 (or 6.0).
>
> On Mon, Jul 2, 2018 at 9:43 AM, Sanne Grinovero 
> wrote:
>
> > On Mon, 2 Jul 2018 at 17:34, Steve Ebersole  wrote:
> > >
> > > I don't mind creating a 5.3 branch, and having master for "after 5.3"
> > development with 6.0 hopefully merged in there soon.
> >
> > +1 that sounds like the best option we have. It's not extremely
> > urgent, we can do this after 5.3.2 ?
> >
> > Just making sure we tighten up the process a bit when we start merging
> > all "compatibility fixes" in WildFly 14, yet not too soon to not waste
> > too much time backporting everything.
> >
> > Thanks!
> > Sanne
> >
> > >
> > > On Mon, Jul 2, 2018 at 11:23 AM Steve Ebersole 
> > wrote:
> > >>
> > >> I think I have pointed out before that such a schedule is already
> > posted : https://github.com/sebersole/hibernate-core/blob/wip/6.0/
> > design/6.0-todo.adoc#alpha1
> > >>
> > >> The important part remaining is really collection support.
> > >>
> > >> There are a few listed there that we'd be willing to push to the next
> > Alpha
> > >>
> > >> On Mon, Jul 2, 2018 at 10:42 AM Sanne Grinovero 
> > wrote:
> > >>>
> > >>> On Hibernate ORM we're currently having "master" branch essentially
> > >>> being a maintenance branch, aka master today is what's planned to be
> > >>> version 5.3.2.Final in some days, 5.3.3 later, etc..
> > >>>
> > >>> This is quite unusual, and it begs some extra attention: normally
> we'd
> > >>> start a new minor in master, so that PRs of any kind could be welcome
> > >>> in master, while specific, cherry-picked fixes are backported to the
> > >>> last maintained minors.
> > >>>
> > >>> This is not the case now and until we move on to a new minor or major
> > >>> we'll need to be particularly careful about what is allowed to be
> > >>> merged.
> > >>> I'm not pointing fingers to any specific commit, my concern is just
> > >>> raised by the high volume of changes being merged. They all look
> great
> > >>> individually but changes are not good at this point :)
> > >>>
> > >>> Not sure what to suggest to people wanting to contribute new features
> > >>> today; maybe hold as we assume the 6.0 work will be merged in master
> > >>> soon? Will be hard to say no to many reasonable requests though.
> > >>>
> > >>> Steve, do you think that the 6.0 merge could happen soon enough to
> not
> > >>> need any process changes in how  we deal with master?
> > >>>
> > >>> Thanks,
> > >>> Sanne
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 5.3 cache issues [Requires Steve]

[Guillaume Smet]

On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole  wrote:

> 1) That was specifically requested
>

Sure. And we also have users who are unhappy with the new setup.

This was also changed for the legacy Ehcache 2 provider which is a pity
IMHO.


> 2) This is easily handled by the providers, if they wish.  They would
> simply map any undefined regions/caches to a pre-defined one (probably
> after warning the user).  Keep in mind that region != cache.  A provider
> might map multiple region names to a single cache.  That was always the
> case, but every provider mapped region <-> cache as 1-1 - the new API makes
> this much more clear.
>
> Personally I think that not allowing on-the-fly creation is a good idea,
> though maybe it can be made configurable.
>

Well, the fact is that it can be a perfectly valid setup if you have
defined a default template for your caches. Typically, as explained here:
https://hibernate.atlassian.net/browse/HHH-11953?focusedCommentId=102080&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-102080
or in the Ehcache documentation for JCache.

If I have 500 entities, using the default default JCache provider, I have
to define the configuration for these 500 caches (+ the ones for the
collections). Whereas I could use a template for most of them. Note that
this is not a rhetorical position: we did that for all our applications
with Yoann at our previous job: sane default cache + fine tuning for
specific entities.

My personal opinion is that we should have a warning explaining the
situation and the frameworks could choose to throw an error if they see fit
but I don't think the default setup should be to throw an error.

Apart from the valid default template case, not being to start your
application until all your caches are configured doesn't seem very helpful
when you are developing your application. You don't start your development
by fine tuning all your caches: it's something you usually do before
pushing your app to production and then adjust with the feedback you have
from the field.

And if you want to be sure, when you push it to production, you can use the
new configuration property Yoann introduced in his PR to make it fail.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 5.3 cache issues [Requires Steve]

[Steve Ebersole]

Then not sure why you ask if you already plan on your answer ;)

On Mon, Jul 2, 2018 at 5:48 PM Guillaume Smet 
wrote:

> On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole  wrote:
>
>> 1) That was specifically requested
>>
>
> Sure. And we also have users who are unhappy with the new setup.
>
> This was also changed for the legacy Ehcache 2 provider which is a pity
> IMHO.
>
>
>> 2) This is easily handled by the providers, if they wish.  They would
>> simply map any undefined regions/caches to a pre-defined one (probably
>> after warning the user).  Keep in mind that region != cache.  A provider
>> might map multiple region names to a single cache.  That was always the
>> case, but every provider mapped region <-> cache as 1-1 - the new API makes
>> this much more clear.
>>
>> Personally I think that not allowing on-the-fly creation is a good idea,
>> though maybe it can be made configurable.
>>
>
> Well, the fact is that it can be a perfectly valid setup if you have
> defined a default template for your caches. Typically, as explained here:
> https://hibernate.atlassian.net/browse/HHH-11953?focusedCommentId=102080&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-102080
> or in the Ehcache documentation for JCache.
>
> If I have 500 entities, using the default default JCache provider, I have
> to define the configuration for these 500 caches (+ the ones for the
> collections). Whereas I could use a template for most of them. Note that
> this is not a rhetorical position: we did that for all our applications
> with Yoann at our previous job: sane default cache + fine tuning for
> specific entities.
>
> My personal opinion is that we should have a warning explaining the
> situation and the frameworks could choose to throw an error if they see fit
> but I don't think the default setup should be to throw an error.
>
> Apart from the valid default template case, not being to start your
> application until all your caches are configured doesn't seem very helpful
> when you are developing your application. You don't start your development
> by fine tuning all your caches: it's something you usually do before
> pushing your app to production and then adjust with the feedback you have
> from the field.
>
> And if you want to be sure, when you push it to production, you can use
> the new configuration property Yoann introduced in his PR to make it fail.
>
> --
> Guillaume
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 5.3 cache issues [Requires Steve]

[Yoann Rodiere]

>
> 2) This is easily handled by the providers, if they wish.  They would
> simply map any undefined regions/caches to a pre-defined one (probably
> after warning the user).  Keep in mind that region != cache.  A provider
> might map multiple region names to a single cache.  That was always the
> case, but every provider mapped region <-> cache as 1-1 - the new API makes
> this much more clear.


Just to clarify: this would require cache implementors to provide their own
region factory, and in that case we all agree they can do whatever they
want, which is nice.

The problem is more with the built-in Ehcache and JCache region factories.
Our built-in region factories call getCache(String), and if it returns
null, they throw an exception. So the cache implementors do not have an
easy way to auto-create a cache using some internal, default configuration:
they would have to do that in the getCache(String) method, and it's
arguably not something you want to do in a method with such a name,
especially considering it's exposed to other clients than just Hibernate
ORM. And I'm not sure the JCache specification even allows that.

Ideally we'd like Ehcache/JCache to expose some getOrCreate(String) method,
and decide for themselves whether to throw an exception or not, but well...
they don't. Which explains the suggestion to handle the "default" logic on
our end.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org



On Tue, 3 Jul 2018 at 01:04, Steve Ebersole  wrote:

> Then not sure why you ask if you already plan on your answer ;)
>
> On Mon, Jul 2, 2018 at 5:48 PM Guillaume Smet 
> wrote:
>
> > On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole 
> wrote:
> >
> >> 1) That was specifically requested
> >>
> >
> > Sure. And we also have users who are unhappy with the new setup.
> >
> > This was also changed for the legacy Ehcache 2 provider which is a pity
> > IMHO.
> >
> >
> >> 2) This is easily handled by the providers, if they wish.  They would
> >> simply map any undefined regions/caches to a pre-defined one (probably
> >> after warning the user).  Keep in mind that region != cache.  A provider
> >> might map multiple region names to a single cache.  That was always the
> >> case, but every provider mapped region <-> cache as 1-1 - the new API
> makes
> >> this much more clear.
> >>
> >> Personally I think that not allowing on-the-fly creation is a good idea,
> >> though maybe it can be made configurable.
> >>
> >
> > Well, the fact is that it can be a perfectly valid setup if you have
> > defined a default template for your caches. Typically, as explained here:
> >
> https://hibernate.atlassian.net/browse/HHH-11953?focusedCommentId=102080&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-102080
> > or in the Ehcache documentation for JCache.
> >
> > If I have 500 entities, using the default default JCache provider, I have
> > to define the configuration for these 500 caches (+ the ones for the
> > collections). Whereas I could use a template for most of them. Note that
> > this is not a rhetorical position: we did that for all our applications
> > with Yoann at our previous job: sane default cache + fine tuning for
> > specific entities.
> >
> > My personal opinion is that we should have a warning explaining the
> > situation and the frameworks could choose to throw an error if they see
> fit
> > but I don't think the default setup should be to throw an error.
> >
> > Apart from the valid default template case, not being to start your
> > application until all your caches are configured doesn't seem very
> helpful
> > when you are developing your application. You don't start your
> development
> > by fine tuning all your caches: it's something you usually do before
> > pushing your app to production and then adjust with the feedback you have
> > from the field.
> >
> > And if you want to be sure, when you push it to production, you can use
> > the new configuration property Yoann introduced in his PR to make it
> fail.
> >
> > --
> > Guillaume
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev