From rory.odonnell at oracle.com Mon Jul 2 05:23:47 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 2 Jul 2018 10:23:47 +0100 Subject: [hibernate-dev] JDK 11 is now in Rampdown Phase one Message-ID: <404ce6e7-917a-6614-3f3a-5a5ab4215c36@oracle.com> 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 From guillaume.smet at gmail.com Mon Jul 2 11:04:04 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 2 Jul 2018 17:04:04 +0200 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] Message-ID: 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 From steve at hibernate.org Mon Jul 2 11:28:05 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 2 Jul 2018 10:28:05 -0500 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: References: Message-ID: 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 at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Jul 2 11:42:40 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 2 Jul 2018 16:42:40 +0100 Subject: [hibernate-dev] ORM progress: tricky branch state Message-ID: 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 From mihalcea.vlad at gmail.com Mon Jul 2 12:07:55 2018 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 2 Jul 2018 19:07:55 +0300 Subject: [hibernate-dev] ORM progress: tricky branch state In-Reply-To: References: Message-ID: 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 at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Mon Jul 2 12:13:29 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 2 Jul 2018 18:13:29 +0200 Subject: [hibernate-dev] ORM progress: tricky branch state In-Reply-To: References: Message-ID: 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 From guillaume.smet at gmail.com Mon Jul 2 12:18:10 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 2 Jul 2018 18:18:10 +0200 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: References: Message-ID: 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 From steve at hibernate.org Mon Jul 2 12:23:52 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 2 Jul 2018 11:23:52 -0500 Subject: [hibernate-dev] ORM progress: tricky branch state In-Reply-To: References: Message-ID: 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 > From steve at hibernate.org Mon Jul 2 12:34:04 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 2 Jul 2018 11:34:04 -0500 Subject: [hibernate-dev] ORM progress: tricky branch state In-Reply-To: References: Message-ID: 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 >> > From sanne at hibernate.org Mon Jul 2 12:43:51 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 2 Jul 2018 17:43:51 +0100 Subject: [hibernate-dev] ORM progress: tricky branch state In-Reply-To: References: Message-ID: 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 From gbadner at redhat.com Mon Jul 2 13:57:18 2018 From: gbadner at redhat.com (Gail Badner) Date: Mon, 2 Jul 2018 10:57:18 -0700 Subject: [hibernate-dev] ORM progress: tricky branch state In-Reply-To: References: Message-ID: +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 at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Jul 2 15:14:54 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 2 Jul 2018 14:14:54 -0500 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: References: Message-ID: 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 > From mihalcea.vlad at gmail.com Mon Jul 2 16:51:56 2018 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 2 Jul 2018 23:51:56 +0300 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: References: Message-ID: 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 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 Jul 2 17:35:28 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 2 Jul 2018 16:35:28 -0500 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: References: Message-ID: 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 at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From andrea at hibernate.org Mon Jul 2 17:43:34 2018 From: andrea at hibernate.org (andrea boriero) Date: Mon, 2 Jul 2018 22:43:34 +0100 Subject: [hibernate-dev] ORM progress: tricky branch state In-Reply-To: References: Message-ID: +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 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 Jul 2 18:47:28 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 3 Jul 2018 00:47:28 +0200 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: References: Message-ID: 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 From steve at hibernate.org Mon Jul 2 19:03:24 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 2 Jul 2018 18:03:24 -0500 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: References: Message-ID: 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 > From yoann at hibernate.org Tue Jul 3 02:33:23 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 3 Jul 2018 08:33:23 +0200 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: References: Message-ID: > > 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 yoann at 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 at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Tue Jul 3 04:13:55 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 3 Jul 2018 10:13:55 +0200 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: References: Message-ID: On Tue, Jul 3, 2018 at 1:03 AM Steve Ebersole wrote: > Then not sure why you ask if you already plan on your answer ;) > Well, obviously, I think there's something wrong, otherwise I wouldn't have raised the issue in the first place and waste everyone's time :). But you're the project lead and you did the work on this so, yes, I prefer asking if you veto it or not. What also bugs me a bit is that with the fail route, the user only has one error at a time: so basically, you have to start your app, fix the first error, restart your app, fix the following one. The warning route is far more straightforward as you have all the issues at once. Having a configuration knob and allowing framework vendors to choose the strict rule if they want seems acceptable to me, that's why I'm defending this position. If you don't have a strong opinion about it, I think it's the best compromise we can make to take into account all the feedback we had about this and have the best usability so I'm leaning towards applying Yoann's PR. -- Guillaume From steve at hibernate.org Tue Jul 3 09:11:44 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 3 Jul 2018 08:11:44 -0500 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: References: Message-ID: On Tue, Jul 3, 2018 at 5:11 AM Yoann Rodiere wrote: > 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. > Not sure exactly what you expect this to return - that's the problem. It would need to return a `net.sf.ehcache.Cache` or a `javax.cache.Cache` or a ... So I think you need to split this into a discussion about Ehcache and one about JCache. For Ehcache... whatever. As I keep saying, that provider is based on Ehcache 2 which the Ehcache team hasn't supported for years now. People really should not be using that one. If you want to revert that one, that's fine For JCache, as I have already said, I am fine with adding a setting here to allow on-the-fly creations. On-the-fly creations are a terrible idea, but people can chose that option if they wish. Just make sure that any logging here (especially the "we are creating an on-the-fly Cache for you") happens through `org.hibernate.cache.spi.SecondLevelCacheLogger` From emmanuel at hibernate.org Tue Jul 3 09:14:58 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 3 Jul 2018 15:14:58 +0200 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: References: Message-ID: <20180703131458.GE12717@hibernate.org> I think they are afraid of you Steve :D When asking, we could make it clear where we stand: - I feel unsure and need someone else to back me up, ideally the project lead - I think I'm right but let's see if Steve or other knowledgable person comes with a strong argument against - I don't want to make the decision, whatever someone else decides At least it gives the right frame of thinking to the person answering. Emmanuel On Mon 18-07-02 18:03, 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 at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Tue Jul 3 09:22:46 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 3 Jul 2018 15:22:46 +0200 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi! Here are the minutes of this week's NoORM IRC meeting: 15:20 < jbott> Meeting ended Tue Jul 3 13:20:30 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:20 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-07-03-13.00.html 15:20 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-07-03-13.00.txt 15:20 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-07-03-13.00.log.html Cheers, -- Guillaume From crancran at gmail.com Tue Jul 3 12:52:31 2018 From: crancran at gmail.com (Chris Cranford) Date: Tue, 3 Jul 2018 12:52:31 -0400 Subject: [hibernate-dev] ORM progress: tricky branch state In-Reply-To: References: Message-ID: +1 from me as well. On 07/02/2018 05:43 PM, andrea boriero wrote: > +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 at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Wed Jul 4 04:32:02 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 4 Jul 2018 10:32:02 +0200 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: <20180703131458.GE12717@hibernate.org> References: <20180703131458.GE12717@hibernate.org> Message-ID: Hi, Current status: - short names and compatibility layer on the ORM side: merged - Radim will get the Infinispan region factory up to speed (Thanks!) - we merged the configuration knobs to allow the automatic creation of caches: . default for Ehcache: create-warn: cache will be automatically created but there will be warnings . default for JCache: fail: failure at bootstrap if there is a missing cache I haven't had any answer to my case against having fail as the default for JCache so I suppose it's how it is. -- Guillaume On Tue, Jul 3, 2018 at 3:15 PM Emmanuel Bernard wrote: > I think they are afraid of you Steve :D > > When asking, we could make it clear where we stand: > - I feel unsure and need someone else to back me up, ideally the project > lead > - I think I'm right but let's see if Steve or other knowledgable person > comes with a strong argument against > - I don't want to make the decision, whatever someone else decides > > At least it gives the right frame of thinking to the person answering. > > Emmanuel > > On Mon 18-07-02 18:03, 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 at lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Wed Jul 4 05:02:43 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 4 Jul 2018 11:02:43 +0200 Subject: [hibernate-dev] AbstractStandardBasicType#getReplacement() prototype is incorrect since HHH-12054 In-Reply-To: References: Message-ID: Any thoughts on this one? Luis, I think your opinion would help. replace() being currently final, we cannot override it in child classes so I tried another approach trying to avoid breaking what has been exposed to the users: https://github.com/hibernate/hibernate-orm/pull/2390 It's not pretty but I think it's the best we can do. I still have a corner case when I don't know exactly what to do: what if the original blob is null and the target blob is unfetched: should we set the blob to null or initialize a new empty blob? The current situation is: 1/ if original is null and target is null, it returns null 2/ if original is null but target is not null, it returns an empty blob So the question is what should we do if original is null and target is unfetched? Should we do 1/ or 2/? -- Guillaume From emmanuel at hibernate.org Wed Jul 4 05:46:21 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 4 Jul 2018 11:46:21 +0200 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: References: <20180703131458.GE12717@hibernate.org> Message-ID: <20180704094621.GF15804@hibernate.org> Let's keep this consistent and use the create-warn for all cases. I understand why the user raised the original JIRA, and yes on paper, failing is the safer prod friendly option. But we must cater to the ease of development too. The development workflow and experience is an important aspect that we must take care of. Having the create-warn by default and allowing the user to move to create or fail is a good compromise. Vlad, in the documentation, we can have a get ready for production section that mention this problem and many others :) I like the idea of Guillaume to try and capture all failing cache creations and return them as a single error. It's not a blocker though and if that cannot make it in our 5.3 sprint, that is acceptable. Emmanuel On Wed 18-07-04 10:32, Guillaume Smet wrote: >Hi, > >Current status: >- short names and compatibility layer on the ORM side: merged >- Radim will get the Infinispan region factory up to speed (Thanks!) >- we merged the configuration knobs to allow the automatic creation of >caches: >. default for Ehcache: create-warn: cache will be automatically created but >there will be warnings >. default for JCache: fail: failure at bootstrap if there is a missing cache > >I haven't had any answer to my case against having fail as the default for >JCache so I suppose it's how it is. > >-- >Guillaume > >On Tue, Jul 3, 2018 at 3:15 PM Emmanuel Bernard >wrote: > >> I think they are afraid of you Steve :D >> >> When asking, we could make it clear where we stand: >> - I feel unsure and need someone else to back me up, ideally the project >> lead >> - I think I'm right but let's see if Steve or other knowledgable person >> comes with a strong argument against >> - I don't want to make the decision, whatever someone else decides >> >> At least it gives the right frame of thinking to the person answering. >> >> Emmanuel >> >> On Mon 18-07-02 18:03, 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 at lists.jboss.org >> >https://lists.jboss.org/mailman/listinfo/hibernate-dev >> From guillaume.smet at gmail.com Wed Jul 4 07:00:41 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 4 Jul 2018 13:00:41 +0200 Subject: [hibernate-dev] 5.3 cache issues [Requires Steve] In-Reply-To: <20180704094621.GF15804@hibernate.org> References: <20180703131458.GE12717@hibernate.org> <20180704094621.GF15804@hibernate.org> Message-ID: On Wed, Jul 4, 2018 at 11:46 AM Emmanuel Bernard wrote: > Having the create-warn by default and allowing the user to move to > create or fail is a good compromise. Vlad, in the documentation, we can > have a get ready for production section that mention this problem and > many others :) > OK, done. > I like the idea of Guillaume to try and capture all failing cache > creations and return them as a single error. It's not a blocker though > and if that cannot make it in our 5.3 sprint, that is acceptable. > So in the default create-warn case, you obviously have listed all the caches that are not defined. It might be nice to do the same thing for the fail case but that is for another day. -- Guillaume From gbadner at redhat.com Wed Jul 4 21:44:20 2018 From: gbadner at redhat.com (Gail Badner) Date: Wed, 4 Jul 2018 18:44:20 -0700 Subject: [hibernate-dev] Hibernate ORM 5.1.15.Final released Message-ID: http://in.relation.to/2018/07/04/hibernate-orm-5115-final-release/ From guillaume.smet at gmail.com Thu Jul 5 05:31:30 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 5 Jul 2018 11:31:30 +0200 Subject: [hibernate-dev] ORM - Release preparation - Don't commit anything to master Message-ID: Hi, 5.3.2 is wrapped up and I'm going to release it this afternoon. Please don't commit anything to master until I reply to this email to say so. Thanks! -- Guillaume From guillaume.smet at hibernate.org Thu Jul 5 10:04:29 2018 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Thu, 5 Jul 2018 16:04:29 +0200 Subject: [hibernate-dev] Hibernate ORM 5.3.2.Final released Message-ID: Hi, We just released Hibernate ORM 5.3.2.Final with a lot of bugfixes and improvements. You'll find more details in the blog post: http://in.relation.to/2018/07/05/hibernate-orm-532-final-out/ . Happy upgrading! -- Guillaume From guillaume.smet at gmail.com Thu Jul 5 10:16:50 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 5 Jul 2018 16:16:50 +0200 Subject: [hibernate-dev] ORM - Release preparation - Don't commit anything to master In-Reply-To: References: Message-ID: 5.3.2 released, you can commit to master again. Note that master is now 5.4 and I created a specific branch for 5.3. On Thu, Jul 5, 2018 at 11:31 AM Guillaume Smet wrote: > Hi, > > 5.3.2 is wrapped up and I'm going to release it this afternoon. Please > don't commit anything to master until I reply to this email to say so. > > Thanks! > > -- > Guillaume > From guillaume.smet at gmail.com Thu Jul 5 10:18:28 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 5 Jul 2018 16:18:28 +0200 Subject: [hibernate-dev] ORM progress: tricky branch state In-Reply-To: References: Message-ID: Hi, Just released 5.3.2 and created a 5.3 branch. master is now 5.4 (it might be changed to 6.0 later if we don't make any release until 6) I'm going to setup proper CI for the 5.3 branch. -- Guillaume On Tue, Jul 3, 2018 at 6:55 PM Chris Cranford wrote: > +1 from me as well. > > On 07/02/2018 05:43 PM, andrea boriero wrote: > > +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 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 gmail.com Thu Jul 5 10:22:31 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 5 Jul 2018 16:22:31 +0200 Subject: [hibernate-dev] ORM release process feedback Message-ID: Hi, So I did an ORM release for the first time today. All in all, the process is very clear and precise, thanks for taking the time to document it and scripting it. Here are the issues I had. Thought you should be aware of the changes I made (I haven't fixed issue 2/ as I'm not sure it's legit). == 1/ Bintray Gradle plugin issue I had a few issues with Bintray though. The first run failed with: > Could not upload to ' https://api.bintray.com/content/hibernate/artifacts/hibernate-orm/5.3.2.Final/value: org/hibernate/value: hibernate-agroal/value: 5.3.2.Final/value: hibernate-agroal-value: 5.3.2.Final.pom': HTTP/1.1 400 Bad Request [message:Unable to upload files: Maven group, artifact or version defined in the pom file do not match the file path 'value: org/hibernate/value: hibernate-agroal/value: 5.3.2.Final/value: hibernate-agroal-value: 5.3.2.Final.pom'] I found https://github.com/bintray/gradle-bintray-plugin/issues/88 advising to update the Bintray Gradle plugin so that's what I did. It fixed the issue but apparently, the first attemps uploaded a weird artifact named "value: org/hibernate/value: hibernate-agroal/value: 5.3.2.Final/value: hibernate-agroal-value: 5.3.2.Final.pom". Sanne removed it. == 2/ Tests running As the first attempt was messy, I ran the second attempt with: ./gradlew clean release It did the following: - build the artifacts - push them to Bintray - run the tests This is weird IMHO. Running the tests before pushing to Bintray could be understandable but I find it weird they are run after the push. Not very familiar with the build so just reporting it in case it would be considered an issue. == 3/ Super huge SourceForge archives The archives on SourceForge were 350MB+ (thanks to Andrea for noticing it): apparently, when working with Eclipse, some files end up in **/bin/ folders. While it's present in the .gitignore, it wasn't present in the exclusions of the distribution. I added them. I also had a ./build folder containing old WildFly releases. As it's added to the .gitignore, I also excluded it from the build. -- Guillaume From fercoli at redhat.com Thu Jul 5 12:45:46 2018 From: fercoli at redhat.com (Fabio Massimo Ercoli) Date: Thu, 5 Jul 2018 18:45:46 +0200 Subject: [hibernate-dev] Hibernate OGM 5.4.0.Beta2 Message-ID: We're happy to announce the release of Hibernate OGM 5.4.0.Beta2. You will find: * Support for Neo4j indexes * Server tasks support for Infinispan Remote * Upgrade to Hibernate ORM 5.3.2.Final ...and more. All the details in the blog post: http://in.relation.to/2018/07/05/hibernate-ogm-5-4-Beta2-released/ All the best, ? Fabio From gbadner at redhat.com Thu Jul 5 16:18:47 2018 From: gbadner at redhat.com (Gail Badner) Date: Thu, 5 Jul 2018 13:18:47 -0700 Subject: [hibernate-dev] AbstractStandardBasicType#getReplacement() prototype is incorrect since HHH-12054 In-Reply-To: References: Message-ID: Hi Guillaume, Thanks for reminding me about this in my PR for HHH-12054 for backporting to 5.1. I'm planning to take a look at this, hopefully early next week. Regards, Gail On Wed, Jul 4, 2018 at 2:02 AM, Guillaume Smet wrote: > Any thoughts on this one? Luis, I think your opinion would help. > > replace() being currently final, we cannot override it in child classes so > I tried another approach trying to avoid breaking what has been exposed to > the users: > https://github.com/hibernate/hibernate-orm/pull/2390 > > It's not pretty but I think it's the best we can do. > > I still have a corner case when I don't know exactly what to do: what if > the original blob is null and the target blob is unfetched: should we set > the blob to null or initialize a new empty blob? > > The current situation is: > 1/ if original is null and target is null, it returns null > 2/ if original is null but target is not null, it returns an empty blob > > So the question is what should we do if original is null and target is > unfetched? Should we do 1/ or 2/? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From diego-luz at live.com Sat Jul 7 17:48:06 2018 From: diego-luz at live.com (=?iso-8859-1?Q?Ant=F4nio_Diego_da_Luz_Silva?=) Date: Sat, 7 Jul 2018 21:48:06 +0000 Subject: [hibernate-dev] Documentation: Cascade and orphanRemoval on associations and Inheritance Message-ID: I think that will be good if it haves the advise of the need of put the cascade parameter on associations to cause the saving cascade effects on the child entitys. Also, I think that will be good if it haves too the advise of the need of maps the entities which are subclasses of entities to use them. Also, the orphanRemoval parameter not worked without the parent entity update operation with Hibernate native apis. This seems to be unlike that that is on Documentation. From smarlow at redhat.com Mon Jul 9 10:37:57 2018 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 9 Jul 2018 10:37:57 -0400 Subject: [hibernate-dev] Javassist version alignment for Hibernate ORM 5.3 + WildFly 14... Message-ID: <102c6f99-994f-9224-9b83-18d4b87f6312@redhat.com> We would like to update WildFly (14) to Javassist 3.23.1, has anyone tried using Javassist 3.23.1 with Hibernate ORM 5.3? I'd like to know that we at least can pass the Javassist tests with the ORM testsuite, preferably on JDK11 (since that is why we want to upgrade Javassist on WildFly). Thanks, Scott From sanne at hibernate.org Mon Jul 9 10:56:20 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 9 Jul 2018 15:56:20 +0100 Subject: [hibernate-dev] Javassist version alignment for Hibernate ORM 5.3 + WildFly 14... In-Reply-To: <102c6f99-994f-9224-9b83-18d4b87f6312@redhat.com> References: <102c6f99-994f-9224-9b83-18d4b87f6312@redhat.com> Message-ID: Hi Scott, send a PR, the bots will trigger test runs at least for Java 8. For proper JDK11 testing that will have to wait as other things aren't working yet, but if the Javassist update works flawlessly on Java 8 there is no reason to not update this point already. Thanks, Sanne On Mon, 9 Jul 2018 at 15:38, Scott Marlow wrote: > > We would like to update WildFly (14) to Javassist 3.23.1, has anyone > tried using Javassist 3.23.1 with Hibernate ORM 5.3? I'd like to know > that we at least can pass the Javassist tests with the ORM testsuite, > preferably on JDK11 (since that is why we want to upgrade Javassist on > WildFly). > > Thanks, > Scott > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Mon Jul 9 11:08:16 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 9 Jul 2018 17:08:16 +0200 Subject: [hibernate-dev] Javassist version alignment for Hibernate ORM 5.3 + WildFly 14... In-Reply-To: References: <102c6f99-994f-9224-9b83-18d4b87f6312@redhat.com> Message-ID: On Mon, Jul 9, 2018 at 4:56 PM Sanne Grinovero wrote: > send a PR, the bots will trigger test runs at least for Java 8. > Do we run all the tests with Javassist now that Bytebuddy is the default? -- Guillaume From sanne at hibernate.org Mon Jul 9 11:12:04 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 9 Jul 2018 16:12:04 +0100 Subject: [hibernate-dev] Javassist version alignment for Hibernate ORM 5.3 + WildFly 14... In-Reply-To: References: <102c6f99-994f-9224-9b83-18d4b87f6312@redhat.com> Message-ID: On Mon, 9 Jul 2018 at 16:09, Guillaume Smet wrote: > > On Mon, Jul 9, 2018 at 4:56 PM Sanne Grinovero wrote: >> >> send a PR, the bots will trigger test runs at least for Java 8. > > > Do we run all the tests with Javassist now that Bytebuddy is the default? No, but there are some tests which are specific to Javassist. > > -- > Guillaume From guillaume.smet at gmail.com Mon Jul 9 11:27:48 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 9 Jul 2018 17:27:48 +0200 Subject: [hibernate-dev] Javassist version alignment for Hibernate ORM 5.3 + WildFly 14... In-Reply-To: References: <102c6f99-994f-9224-9b83-18d4b87f6312@redhat.com> Message-ID: On Mon, Jul 9, 2018 at 5:12 PM Sanne Grinovero wrote: > No, but there are some tests which are specific to Javassist. > That's what I suspected. Let's run the full test suite with the new version of Javassist then. I prefer to be on the safe side, especially because I'm not sure all the bugs in the bytebuddy implementation have been fixed. Scott, I'll take care of running the tests tomorrow and provide feedback. Not sure about Java 11 but let's at least check we don't have any regressions. To be very clear, while I can run the tests and tell you if they pass or not, if there are any issues, we will need some extra support to fix them. I created https://hibernate.atlassian.net/browse/HHH-12781 to track this effort and tentatively scheduled it for 5.3.3, released on July 19th. -- Guillaume From guillaume.smet at gmail.com Mon Jul 9 14:33:32 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 9 Jul 2018 20:33:32 +0200 Subject: [hibernate-dev] AbstractStandardBasicType#getReplacement() prototype is incorrect since HHH-12054 In-Reply-To: References: Message-ID: Hi Gail, Don't waste your time on it for now. We had an interesting discussion with Yoann about it and I plan to revisit it. I'll ping you when it's done. Thanks. -- Guillaume On Thu, Jul 5, 2018 at 10:18 PM Gail Badner wrote: > Hi Guillaume, > > Thanks for reminding me about this in my PR for HHH-12054 for backporting > to 5.1. > > I'm planning to take a look at this, hopefully early next week. > > Regards, > Gail > > On Wed, Jul 4, 2018 at 2:02 AM, Guillaume Smet > wrote: > >> Any thoughts on this one? Luis, I think your opinion would help. >> >> replace() being currently final, we cannot override it in child classes so >> I tried another approach trying to avoid breaking what has been exposed to >> the users: >> https://github.com/hibernate/hibernate-orm/pull/2390 >> >> It's not pretty but I think it's the best we can do. >> >> I still have a corner case when I don't know exactly what to do: what if >> the original blob is null and the target blob is unfetched: should we set >> the blob to null or initialize a new empty blob? >> >> The current situation is: >> 1/ if original is null and target is null, it returns null >> 2/ if original is null but target is not null, it returns an empty blob >> >> So the question is what should we do if original is null and target is >> unfetched? Should we do 1/ or 2/? >> >> -- >> Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From smarlow at redhat.com Mon Jul 9 16:15:41 2018 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 9 Jul 2018 16:15:41 -0400 Subject: [hibernate-dev] Javassist version alignment for Hibernate ORM 5.3 + WildFly 14... In-Reply-To: References: <102c6f99-994f-9224-9b83-18d4b87f6312@redhat.com> Message-ID: <14f8f7ba-a098-50de-c361-9fa9bbd6b0b8@redhat.com> On 07/09/2018 11:27 AM, Guillaume Smet wrote: > On Mon, Jul 9, 2018 at 5:12 PM Sanne Grinovero > wrote: > > No, but there are some tests which are specific to Javassist. > > > That's what I suspected. Let's run the full test suite with the new > version of Javassist then. I prefer to be on the safe side, especially > because I'm not sure all the bugs in the bytebuddy implementation have > been fixed. > > Scott, I'll take care of running the tests tomorrow and provide > feedback. Not sure about Java 11 but let's at least check we don't have > any regressions. > > To be very clear, while I can run the tests and tell you if they pass or > not, if there are any issues, we will need some extra support to fix them. > > I created https://hibernate.atlassian.net/browse/HHH-12781 to track this > effort and tentatively scheduled it for 5.3.3, released on July 19th. Thanks, I created https://issues.jboss.org/browse/WFLY-10683 for the WildFly update to Javassist 3.23.1-GA (if your ORM testing passes). Scott > > -- > Guillaume From guillaume.smet at gmail.com Tue Jul 10 07:24:18 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 10 Jul 2018 13:24:18 +0200 Subject: [hibernate-dev] Javassist version alignment for Hibernate ORM 5.3 + WildFly 14... In-Reply-To: <14f8f7ba-a098-50de-c361-9fa9bbd6b0b8@redhat.com> References: <102c6f99-994f-9224-9b83-18d4b87f6312@redhat.com> <14f8f7ba-a098-50de-c361-9fa9bbd6b0b8@redhat.com> Message-ID: On Mon, Jul 9, 2018 at 10:15 PM Scott Marlow wrote: > Thanks, I created https://issues.jboss.org/browse/WFLY-10683 for the > WildFly update to Javassist 3.23.1-GA (if your ORM testing passes). > So, the bad news is our Javassist support was completely broken. See https://hibernate.atlassian.net/browse/HHH-12784 for more details. The good news is that the Javassist upgrade is OK. I also ran the tests with JDK 11: quite a lot of tests are failing on our part (mostly because of Mockito but not only: there are a few other issues that we will need to dig in) but not the ones related to enhancement. PR is here: https://github.com/hibernate/hibernate-orm/pull/2407 . I also opened an issue to restore Javassist testing, which is something that had me worried for quite a while: https://hibernate.atlassian.net/browse/HHH-12785 . If someone more familiar with the build environment and Gradle could take this task as part of his "one day a week on 5.3" day, that would be greatly appreciated. Thanks. -- Guillaume From diego-luz at live.com Tue Jul 10 16:21:58 2018 From: diego-luz at live.com (=?iso-8859-1?Q?Ant=F4nio_Diego_da_Luz_Silva?=) Date: Tue, 10 Jul 2018 20:21:58 +0000 Subject: [hibernate-dev] Test Message-ID: Are someone receiving my messages? From diego-luz at live.com Tue Jul 10 16:36:45 2018 From: diego-luz at live.com (=?iso-8859-1?Q?Ant=F4nio_Diego_da_Luz_Silva?=) Date: Tue, 10 Jul 2018 20:36:45 +0000 Subject: [hibernate-dev] Test In-Reply-To: References: , , Message-ID: She held suggestions to turn better the Hibernate documentation. ________________________________ From: Ant?nio Diego da Luz Silva Sent: Tuesday, July 10, 2018 5:33:20 PM To: Vlad Mihalcea Subject: Re: [hibernate-dev] Test Thanks for the answer. I sended one message before that and I haven't received answers. ________________________________ From: Vlad Mihalcea Sent: Tuesday, July 10, 2018 5:28:53 PM To: Ant?nio Diego da Luz Silva Subject: Re: [hibernate-dev] Test Yes, we got your email. Vlad On Tue, 10 Jul 2018, 23:22 Ant?nio Diego da Luz Silva, > wrote: Are someone receiving my messages? _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Wed Jul 11 13:31:21 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 11 Jul 2018 12:31:21 -0500 Subject: [hibernate-dev] ORM 6.0 Alpha1 release planning Message-ID: I had a talk with Luis this morning with regard to the performance benchmarks for 6 versus 5. He is working from 2 different benchmarks - one simply compares parsing HQL (without executing it) and the other compares certain operations (save/persist, load, etc). Luis, correct me if I am wrong, but what I took away from the conversation is this: 1. For the operations benchmark the numbers for 6 were better than 5, but within the error margin - so 6 is better-than-or-equal-to 5 here. 2. 6 was generally faster at parsing queries except for when it came to interpreting paths. We need to address the paths problem, for sure, but honestly I was not expecting any performance improvements in query parsing - at least not initially and the primary focus of the work is in making the executions more performant. Any improvements on query parsing performance is cake at this point, though certainly something we want to look at. I asked Luis to compare the numbers specifically for load operations in that operations benchmark. That is really the only operations case where I would expect perf improvements at this time - it should piggy-back on the overall JDBC execution performance improvements. Luis, I'd also like to get some simple HQL queries into that operations benchmark if we could to verify that this ^^ happens there as well. I can help with that if you want - let me know. Barring any crazy outcomes from these new benchmark results, I feel comfortable starting to plan an initial Alpha release schedule. We currently have a fairly aggressive set of items to complete on our Alpha1 checklist[1][2]. I think we ought to consider paring that down in the interest of release early, release often - having releases would help OGM, etc integrate early and often as well. My proposal is to just implement basic support for plural attributes in Alpha1 and push the rest to later Alphas. E.g.: 1. Alpha1 1. plural attribute suppport 2. Alpha2 1. Any / ManyToAny support 2. Cascading 3. Alpha3 1. Metamodel fetching 2. JDBC batching 4. We'll see where we are... IMO each Alpha ought to be 2 weeks, though I could live with 3 or depending one everyone else's opinion. Thoughts? Opinions? [1] https://github.com/sebersole/hibernate-core/blob/wip/6.0/design/6.0-todo.adoc#alpha1 [2] That list is somewhat out of date anyway as quite a few things listed there are already implemented From postmaster at lists.jboss.org Thu Jul 12 23:40:33 2018 From: postmaster at lists.jboss.org (Mail Administrator) Date: Fri, 13 Jul 2018 11:40:33 +0800 Subject: [hibernate-dev] Delivery failed Message-ID: <201807130340.w6D3eZGw026464@lists01.dmz-a.mwc.hst.phx2.redhat.com> ??b???c?l?6????"???ip??P??3# ?U??:^?r?N>?`?25???$X????C? ?1??U??#?)??Ek]?G???I??5????|?t??L????l}S??????c?zu???/?19? !`$?u??{]???onC???I?0J???o??- ??bLFSz??A"? ?a?iz??fA??f/?(?????Z5.??kX??w74??*?l??a??!?W?????s?\????p??????F/b??&????q?F G?s_?$?!?????Oq??GXQ??P?I`?9[??7z*?????,C?bK?X?u????M)3??6???sza6#>U??D????? ???????xz??I?$?W?O??????N?l?b(??j????/?A?y??*y &i?#?Ux ????c?z??j"c-lh???w"u????mu??}???J?e'?????? ????/d???_vL???????y?????`O?F>?????J??_Jk?xL0Tr?L?mKCC?Dx?c?i?){??'LU?D4???%??S?p;??]/??G??,??:???S?j??????5!N9O??V9?I"?}????)????? ???????9??Z? R:???S?` ???]e??v8f?????%???W??5?;N??"???{3???b???M????fe?N>oU_34vC[Mb???.W?khk??-O??NM???8f[R?~???????'t?>????-N?w?7? 8 O?3Z3X?$?i{??FE?mjIZk? ? ?????0X???_`???? ?a$w??6$:?????U?5???d ?x????Pw????q-X#??A??M???I`??????????.QrX%?&???????n??*'w??????b????_?^9%?]??_!??????*QAl4-?w???H??f5{?1?R]\?zr?T! 7?{??xe???10?*???bq??_?????????(?cP6??-??????????j???N????p)8?Q??i??).?O??z{)?8{??.6Sm^?Tx?n`??y?2??? ?0?L?\???/??RW^?(???&#[?4Gu"J??? X??sdw??D?N?b?Kv??BO???N.??fo?????qD .????l?*E? ?{??????n????s?????9H???????????0?r?~??t8p???o?b?H6????17??z?????T??U???hJX`2???G?!?uc???????z??k?y??q??w??u?3?2??????????8????kh92??[7g??? hN$?????_C?Jy?????cH(?^ ???S-?????HLmr??????6?w??p? 9IRY?$?????9mM/?W???H?5??y?o?F?????>b||???2??6?c?t?d?????? 1V2T??????Lun?D4p9?????U5C??pJ??x?4?????????x?? ??z???????[? ???CK??qs?_??;p??uT?aJ$>xE???.0?3??????U??p??[??V5?j6?L???Q/i?6?????\ ???< ??<_A?a*?Ro????F??I%??W?M?.J6|i??/? ???m??kFnd???!??J?K???7???t??S,O??BD?m????a,`DF?????x??6?A?;??????3????H? ?'?kcKkIW??#e??2?????YJ??qwbX??Ets?s??I????d??????? "???l?)?z,][??QH??)??Q?;!o???w?h4?????""?d?a??_O???91??jc??x???q??g:????????>??nJ?4? ? ???70?c???????./?3??Cva?t?????M(. ?p:?C?w?e??R???????Ebo???????R?????#a?W5m??#?]??x??5? gw?/a4`?N1?In??f?#????}?w?? 0H?.???????'??????U???xd?R???z/?????"{b??!?Q*??_P?/??;??~??r??Y????????~r?o??f-I?????%?w???%ot#lj6??\???]}?_O`?z?X?p?h&??'??`h?ct?N?0Vxy/*??6??m!awh??o???l???uZ?dpC?s?(??6cd{V$??>??????U[3????%?#c??????:?1?D??$? From guillaume.smet at gmail.com Fri Jul 13 04:29:26 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 13 Jul 2018 10:29:26 +0200 Subject: [hibernate-dev] ORM 6.0 Alpha1 release planning In-Reply-To: References: Message-ID: On Wed, Jul 11, 2018 at 7:35 PM Steve Ebersole wrote: > IMO each Alpha ought to be 2 weeks, though I could live with 3 or > depending one everyone else's opinion. > Big +1 for frequent releases. As for the frequency, between 2 weeks and 1 month sounds good to me, depending on the progress you all make. By the way and it's probably more a question for Luis, is there a plan to publish the benchmarks somewhere in the open? I would really like to have a set of JMH benchmarks for ORM. That could help to run a profiler and optimize the code, quickly check that we don't have a regression when touching performance-sensitive code and so on. Obviously not saying we will do the work of the performance team but being able to run a quick benchmark focused on a particular area might be very helpful in the future. -- Guillaume From guillaume.smet at gmail.com Sat Jul 14 14:20:02 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Sat, 14 Jul 2018 20:20:02 +0200 Subject: [hibernate-dev] ORM - Asciidoclet Message-ID: Hi, Are we using Asciidoc javadoc in the current tree (i.e. not 6)? With JDK 11, when ./gradlew :hibernate-core:javadoc is executed and this doclet is enabled, I have the following error: javadoc: error - invalid flag: -Xdoclint:none In the javadoc -X help, it says that doclint is "Provided by the Standard doclet". Removing the asciidoclet declaration fixes the issue. As asciidoclet is not enabled in the aggregateJavadocs task, I'm under the impression that it is not used. Could someone confirm this? Thanks! -- Guillaume From guillaume.smet at gmail.com Sat Jul 14 15:15:00 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Sat, 14 Jul 2018 21:15:00 +0200 Subject: [hibernate-dev] [ORM] Javadoc errors fixing Message-ID: Hi, So due to the issue with Asciidoclet I exposed in my previous email, I thought for some time that they had removed the -XDoclint flag in Java 11. Thus I started cleaning up all the Javadoc errors we have in the ORM source code... This led to the following changes: https://github.com/hibernate/hibernate-orm/compare/master...gsmet:HHH-12806?expand=1 . It's kinda huge and while it's only trivial changes, I'm a bit worried about what will happen when you will try to merge this in your 6 branch. All the errors are fixed except: - 3 reference not found errors for which I need advice - the errors in the generated sources that are thrown in the aggregateJavadocs task: the exclude rules are not taken into account by Gradle in this task, probably a Gradle bug, I saw an old forum post of Steve in the Gradle forum about this issue. Note: I don't have any issue if we consider it's not the right time to do that and we should only do that on 6. That's why I ask the question. I have no idea of what the 6 branch look like so I don't know how much of an issue it can be. Cherry-picking these changes on top of 6, once it's stabilized is a possibility. Thoughts? -- Guillaume From steve at hibernate.org Sat Jul 14 20:12:51 2018 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 14 Jul 2018 19:12:51 -0500 Subject: [hibernate-dev] ORM - Asciidoclet In-Reply-To: References: Message-ID: We have ported things from 6 back to 5.3 so I cannot say definitively that absolutely no javadoc in 5.3 uses asciidoc(tor). But feel free to disable it. On Sat, Jul 14, 2018, 1:45 PM Guillaume Smet wrote: > Hi, > > Are we using Asciidoc javadoc in the current tree (i.e. not 6)? > > With JDK 11, when ./gradlew :hibernate-core:javadoc is executed and this > doclet is enabled, I have the following error: > javadoc: error - invalid flag: -Xdoclint:none > > In the javadoc -X help, it says that doclint is "Provided by the Standard > doclet". > > Removing the asciidoclet declaration fixes the issue. > > As asciidoclet is not enabled in the aggregateJavadocs task, I'm under the > impression that it is not used. > > Could someone confirm this? > > 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 Sat Jul 14 20:16:11 2018 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 14 Jul 2018 19:16:11 -0500 Subject: [hibernate-dev] [ORM] Javadoc errors fixing In-Reply-To: References: Message-ID: I'd really rather not have to deal with changes like this on top of everything else while integrating 5.3 and 6.0. On Sat, Jul 14, 2018, 2:31 PM Guillaume Smet wrote: > Hi, > > So due to the issue with Asciidoclet I exposed in my previous email, I > thought for some time that they had removed the -XDoclint flag in Java 11. > > Thus I started cleaning up all the Javadoc errors we have in the ORM source > code... > > This led to the following changes: > > https://github.com/hibernate/hibernate-orm/compare/master...gsmet:HHH-12806?expand=1 > . > > It's kinda huge and while it's only trivial changes, I'm a bit worried > about what will happen when you will try to merge this in your 6 branch. > > All the errors are fixed except: > - 3 reference not found errors for which I need advice > - the errors in the generated sources that are thrown in the > aggregateJavadocs task: the exclude rules are not taken into account by > Gradle in this task, probably a Gradle bug, I saw an old forum post of > Steve in the Gradle forum about this issue. > > Note: I don't have any issue if we consider it's not the right time to do > that and we should only do that on 6. That's why I ask the question. I have > no idea of what the 6 branch look like so I don't know how much of an issue > it can be. Cherry-picking these changes on top of 6, once it's stabilized > is a possibility. > > Thoughts? > > -- > 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 Sun Jul 15 06:49:37 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Sun, 15 Jul 2018 12:49:37 +0200 Subject: [hibernate-dev] [ORM] Javadoc errors fixing In-Reply-To: References: Message-ID: Yup, that's what I thought. I'll keep the branch and try to reapply it on top of 6 sometime in the future when 6 will be our main branch. On Sun, Jul 15, 2018 at 2:16 AM Steve Ebersole wrote: > I'd really rather not have to deal with changes like this on top of > everything else while integrating 5.3 and 6.0. > > > On Sat, Jul 14, 2018, 2:31 PM Guillaume Smet > wrote: > >> Hi, >> >> So due to the issue with Asciidoclet I exposed in my previous email, I >> thought for some time that they had removed the -XDoclint flag in Java 11. >> >> Thus I started cleaning up all the Javadoc errors we have in the ORM >> source >> code... >> >> This led to the following changes: >> >> https://github.com/hibernate/hibernate-orm/compare/master...gsmet:HHH-12806?expand=1 >> . >> >> It's kinda huge and while it's only trivial changes, I'm a bit worried >> about what will happen when you will try to merge this in your 6 branch. >> >> All the errors are fixed except: >> - 3 reference not found errors for which I need advice >> - the errors in the generated sources that are thrown in the >> aggregateJavadocs task: the exclude rules are not taken into account by >> Gradle in this task, probably a Gradle bug, I saw an old forum post of >> Steve in the Gradle forum about this issue. >> >> Note: I don't have any issue if we consider it's not the right time to do >> that and we should only do that on 6. That's why I ask the question. I >> have >> no idea of what the 6 branch look like so I don't know how much of an >> issue >> it can be. Cherry-picking these changes on top of 6, once it's stabilized >> is a possibility. >> >> Thoughts? >> >> -- >> 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 Sun Jul 15 08:57:38 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Sun, 15 Jul 2018 14:57:38 +0200 Subject: [hibernate-dev] ORM - Asciidoclet In-Reply-To: References: Message-ID: On Sun, Jul 15, 2018 at 2:13 AM Steve Ebersole wrote: > We have ported things from 6 back to 5.3 so I cannot say definitively that > absolutely no javadoc in 5.3 uses asciidoc(tor). > > But feel free to disable it. > I just tried the opposite and enable Asciidoclet for the aggregated javadoc to be consistent and it leads to malformed Javadoc containing HTML markups when our Javadoc is using HTML. I think you either have all your Javadoc using Asciidoctor or you end up with some bad output. A good example is the Javadoc of CompositeNestedGeneratedValueGenerator which, with Asciidoclet enabled, looks like: For composite identifiers, defines a number of "nested" generations that need to happen to "fill" the identifier property(s).

This generator is used implicitly for all composite identifier scenarios if an explicit generator is not in place. So it make sense to discuss the various potential scenarios:

  • "embedded" composite identifier - this is possible only in HBM mappings as <composite-id/> (notice the lack of both a name and class attribute declarations). The term "embedded" <../../../org/hibernate/mapping/Component.html#isEmbedded--> here refers to the Hibernate usage which is actually the exact opposite of the JPA meaning of "embedded". Essentially this means that the entity class itself holds the named composite pk properties. This is very similar to the JPA @IdClass usage, though without a separate pk-class for loading.
  • pk-class as entity attribute - this is possible in both annotations (@EmbeddedId) and HBM mappings (<composite-id name="idAttributeName" class="PkClassName"/>)
  • "embedded" composite identifier with a pk-class - this is the JPA @IdClass use case and is only possible in annotations

Most of the grunt work is done in Component <../../../org/hibernate/mapping/Component.html>. Did I miss something? -- Guillaume From steve at hibernate.org Sun Jul 15 09:06:37 2018 From: steve at hibernate.org (Steve Ebersole) Date: Sun, 15 Jul 2018 08:06:37 -0500 Subject: [hibernate-dev] ORM - Asciidoclet In-Reply-To: References: Message-ID: You mean the lack of rendering Javdoc cross-references ({@link ...})? Otherwise, I am not sure what exactly you are getting at. Asciidoclet is supposed to handle Javdoc cross-references - if it is not, that would be a bug in asciidoclet On Sun, Jul 15, 2018 at 7:58 AM Guillaume Smet wrote: > On Sun, Jul 15, 2018 at 2:13 AM Steve Ebersole > wrote: > >> We have ported things from 6 back to 5.3 so I cannot say definitively >> that absolutely no javadoc in 5.3 uses asciidoc(tor). >> >> But feel free to disable it. >> > > I just tried the opposite and enable Asciidoclet for the aggregated > javadoc to be consistent and it leads to malformed Javadoc containing HTML > markups when our Javadoc is using HTML. > > I think you either have all your Javadoc using Asciidoctor or you end up > with some bad output. > > A good example is the Javadoc of CompositeNestedGeneratedValueGenerator > which, with Asciidoclet enabled, looks like: > > For composite identifiers, defines a number of "nested" generations that > need to happen to "fill" the identifier property(s).

This generator is > used implicitly for all composite identifier scenarios if an explicit > generator is not in place. So it make sense to discuss the various > potential scenarios:

  • "embedded" composite identifier - this > is possible only in HBM mappings as <composite-id/> (notice the > lack of both a name and class attribute declarations). The term "embedded" > here > refers to the Hibernate usage which is actually the exact opposite of the > JPA meaning of "embedded". Essentially this means that the entity class > itself holds the named composite pk properties. This is very similar to the > JPA @IdClass usage, though without a separate pk-class for loading.
  • >
  • pk-class as entity attribute - this is possible in both > annotations (@EmbeddedId) and HBM mappings (<composite-id > name="idAttributeName" class="PkClassName"/>)
  • "embedded" > composite identifier with a pk-class - this is the JPA @IdClass use > case and is only possible in annotations

Most of the grunt > work is done in Component > . > > Did I miss something? > > -- > Guillaume > From guillaume.smet at gmail.com Sun Jul 15 09:12:58 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Sun, 15 Jul 2018 15:12:58 +0200 Subject: [hibernate-dev] ORM - Asciidoclet In-Reply-To: References: Message-ID: No I'm talking about all the markup that appears in the output. What I pasted is not the source, it's the output you get in your Javadoc (with the

  • , the

    and so on). The cross references are indeed OK. On Sun, Jul 15, 2018 at 3:06 PM Steve Ebersole wrote: > You mean the lack of rendering Javdoc cross-references ({@link ...})? > Otherwise, I am not sure what exactly you are getting at. > > Asciidoclet is supposed to handle Javdoc cross-references - if it is not, > that would be a bug in asciidoclet > > On Sun, Jul 15, 2018 at 7:58 AM Guillaume Smet > wrote: > >> On Sun, Jul 15, 2018 at 2:13 AM Steve Ebersole >> wrote: >> >>> We have ported things from 6 back to 5.3 so I cannot say definitively >>> that absolutely no javadoc in 5.3 uses asciidoc(tor). >>> >>> But feel free to disable it. >>> >> >> I just tried the opposite and enable Asciidoclet for the aggregated >> javadoc to be consistent and it leads to malformed Javadoc containing HTML >> markups when our Javadoc is using HTML. >> >> I think you either have all your Javadoc using Asciidoctor or you end up >> with some bad output. >> >> A good example is the Javadoc of CompositeNestedGeneratedValueGenerator >> which, with Asciidoclet enabled, looks like: >> >> For composite identifiers, defines a number of "nested" generations that >> need to happen to "fill" the identifier property(s).

    This generator is >> used implicitly for all composite identifier scenarios if an explicit >> generator is not in place. So it make sense to discuss the various >> potential scenarios:

    • "embedded" composite identifier - this >> is possible only in HBM mappings as <composite-id/> (notice the >> lack of both a name and class attribute declarations). The term >> "embedded" >> here >> refers to the Hibernate usage which is actually the exact opposite of the >> JPA meaning of "embedded". Essentially this means that the entity class >> itself holds the named composite pk properties. This is very similar to the >> JPA @IdClass usage, though without a separate pk-class for loading. >>
    • pk-class as entity attribute - this is possible in both >> annotations (@EmbeddedId) and HBM mappings (<composite-id >> name="idAttributeName" class="PkClassName"/>)
    • >> "embedded" composite identifier with a pk-class - this is the JPA >> @IdClass use case and is only possible in annotations

    >> Most of the grunt work is done in Component >> . >> >> Did I miss something? >> >> -- >> Guillaume >> > From steve at hibernate.org Sun Jul 15 09:15:52 2018 From: steve at hibernate.org (Steve Ebersole) Date: Sun, 15 Jul 2018 08:15:52 -0500 Subject: [hibernate-dev] ORM - Asciidoclet In-Reply-To: References: Message-ID: Oh, you mean it does not like HTML markup? Not sure, we should ask Dan and friends what is expected there from asciidoclet - I'm not sure On Sun, Jul 15, 2018 at 8:13 AM Guillaume Smet wrote: > No I'm talking about all the markup that appears in the output. What I > pasted is not the source, it's the output you get in your Javadoc (with the >

  • , the

    and so on). > > The cross references are indeed OK. > > On Sun, Jul 15, 2018 at 3:06 PM Steve Ebersole > wrote: > >> You mean the lack of rendering Javdoc cross-references ({@link ...})? >> Otherwise, I am not sure what exactly you are getting at. >> >> Asciidoclet is supposed to handle Javdoc cross-references - if it is not, >> that would be a bug in asciidoclet >> >> On Sun, Jul 15, 2018 at 7:58 AM Guillaume Smet >> wrote: >> >>> On Sun, Jul 15, 2018 at 2:13 AM Steve Ebersole >>> wrote: >>> >>>> We have ported things from 6 back to 5.3 so I cannot say definitively >>>> that absolutely no javadoc in 5.3 uses asciidoc(tor). >>>> >>>> But feel free to disable it. >>>> >>> >>> I just tried the opposite and enable Asciidoclet for the aggregated >>> javadoc to be consistent and it leads to malformed Javadoc containing HTML >>> markups when our Javadoc is using HTML. >>> >>> I think you either have all your Javadoc using Asciidoctor or you end up >>> with some bad output. >>> >>> A good example is the Javadoc of CompositeNestedGeneratedValueGenerator >>> which, with Asciidoclet enabled, looks like: >>> >>> For composite identifiers, defines a number of "nested" generations that >>> need to happen to "fill" the identifier property(s).

    This generator is >>> used implicitly for all composite identifier scenarios if an explicit >>> generator is not in place. So it make sense to discuss the various >>> potential scenarios:

    • "embedded" composite identifier - this >>> is possible only in HBM mappings as <composite-id/> (notice the >>> lack of both a name and class attribute declarations). The term >>> "embedded" >>> here >>> refers to the Hibernate usage which is actually the exact opposite of the >>> JPA meaning of "embedded". Essentially this means that the entity class >>> itself holds the named composite pk properties. This is very similar to the >>> JPA @IdClass usage, though without a separate pk-class for loading. >>>
    • pk-class as entity attribute - this is possible in both >>> annotations (@EmbeddedId) and HBM mappings (<composite-id >>> name="idAttributeName" class="PkClassName"/>)
    • >>> "embedded" composite identifier with a pk-class - this is the JPA >>> @IdClass use case and is only possible in annotations

    >>> Most of the grunt work is done in Component >>> . >>> >>> Did I miss something? >>> >>> -- >>> Guillaume >>> >> From guillaume.smet at gmail.com Sun Jul 15 09:33:29 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Sun, 15 Jul 2018 15:33:29 +0200 Subject: [hibernate-dev] ORM - Asciidoclet In-Reply-To: References: Message-ID: On Sun, Jul 15, 2018 at 3:16 PM Steve Ebersole wrote: > Oh, you mean it does not like HTML markup? Not sure, we should ask Dan > and friends what is expected there from asciidoclet - I'm not sure > Yes, exactly. HTML output is rendered escaped, which is expected if it considers all our Javadoc content as potential Asciidoctor. For now, I'll disable it in 5.3 as we're not even sure we have Asciidoctor in it. But we should check that for 6 as, if it's expected, we would have to rewrite all the existing Javadoc as Asciidoctor. I posted something on the Asciidoctor discussion forum: http://discuss.asciidoctor.org/Migrating-to-Asciidoclet-progressively-td6425.html . -- Guillaume From steve at hibernate.org Sun Jul 15 09:38:07 2018 From: steve at hibernate.org (Steve Ebersole) Date: Sun, 15 Jul 2018 08:38:07 -0500 Subject: [hibernate-dev] ORM - Asciidoclet In-Reply-To: References: Message-ID: We crossed cyber paths - https://github.com/asciidoctor/asciidoclet/issues/90 On Sun, Jul 15, 2018 at 8:34 AM Guillaume Smet wrote: > On Sun, Jul 15, 2018 at 3:16 PM Steve Ebersole > wrote: > >> Oh, you mean it does not like HTML markup? Not sure, we should ask Dan >> and friends what is expected there from asciidoclet - I'm not sure >> > > Yes, exactly. > > HTML output is rendered escaped, which is expected if it considers all our > Javadoc content as potential Asciidoctor. > > For now, I'll disable it in 5.3 as we're not even sure we have Asciidoctor > in it. > > But we should check that for 6 as, if it's expected, we would have to > rewrite all the existing Javadoc as Asciidoctor. > > I posted something on the Asciidoctor discussion forum: > http://discuss.asciidoctor.org/Migrating-to-Asciidoclet-progressively-td6425.html > . > > -- > Guillaume > From guillaume.smet at gmail.com Mon Jul 16 05:51:55 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 16 Jul 2018 11:51:55 +0200 Subject: [hibernate-dev] ORM - Migration guides: wiki or source repository? Message-ID: Hi, I see that we have a migration-guide.adoc document in the repository: https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc and we also have migration guides in the wiki: https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.3 Is there a reason why we have both? Lately, I updated the wiki one and I just noticed Gail updated the source one. So if we keep both, we will need to keep them in sync but I'm not sure there's any value in keeping both. Except having a migration guide bundled in the zip archive, maybe? Thoughts? Thanks! -- Guillaume From gbadner at redhat.com Mon Jul 16 14:40:37 2018 From: gbadner at redhat.com (Gail Badner) Date: Mon, 16 Jul 2018 11:40:37 -0700 Subject: [hibernate-dev] ORM - Migration guides: wiki or source repository? In-Reply-To: References: Message-ID: I only update the source... On Mon, Jul 16, 2018 at 2:51 AM, Guillaume Smet wrote: > Hi, > > I see that we have a migration-guide.adoc document in the repository: > https://github.com/hibernate/hibernate-orm/blob/master/ > migration-guide.adoc > > and we also have migration guides in the wiki: > https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 > https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.3 > > Is there a reason why we have both? > > Lately, I updated the wiki one and I just noticed Gail updated the source > one. So if we keep both, we will need to keep them in sync but I'm not sure > there's any value in keeping both. Except having a migration guide bundled > in the zip archive, maybe? > > Thoughts? > > Thanks! > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gbadner at redhat.com Mon Jul 16 14:42:40 2018 From: gbadner at redhat.com (Gail Badner) Date: Mon, 16 Jul 2018 11:42:40 -0700 Subject: [hibernate-dev] ORM - Migration guides: wiki or source repository? In-Reply-To: References: Message-ID: If there is any reason to keep the wiki, IMO, it should just refer to the version at the appropriate branch in github, e.g, https://github.com/hibernate/hibernate-orm/blob/5.3/migration-guide.adoc. On Mon, Jul 16, 2018 at 11:40 AM, Gail Badner wrote: > I only update the source... > > On Mon, Jul 16, 2018 at 2:51 AM, Guillaume Smet > wrote: > >> Hi, >> >> I see that we have a migration-guide.adoc document in the repository: >> https://github.com/hibernate/hibernate-orm/blob/master/migra >> tion-guide.adoc >> >> and we also have migration guides in the wiki: >> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 >> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.3 >> >> Is there a reason why we have both? >> >> Lately, I updated the wiki one and I just noticed Gail updated the source >> one. So if we keep both, we will need to keep them in sync but I'm not >> sure >> there's any value in keeping both. Except having a migration guide bundled >> in the zip archive, maybe? >> >> Thoughts? >> >> 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 Mon Jul 16 15:04:30 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 16 Jul 2018 14:04:30 -0500 Subject: [hibernate-dev] ORM - Migration guides: wiki or source repository? In-Reply-To: References: Message-ID: The intention was to use the wiki just as a collection of all the links[1] and have each of those links point to the real migration guides which are kept in the appropriate source branches. It was decided to just not do the effort to move older migration guides which used to be fully written in the wiki. [1] https://github.com/hibernate/hibernate-orm/wiki/Migration-Guides. On Mon, Jul 16, 2018 at 1:58 PM Gail Badner wrote: > If there is any reason to keep the wiki, IMO, it should just refer to the > version at the appropriate branch in github, e.g, > https://github.com/hibernate/hibernate-orm/blob/5.3/migration-guide.adoc. > > On Mon, Jul 16, 2018 at 11:40 AM, Gail Badner wrote: > > > I only update the source... > > > > On Mon, Jul 16, 2018 at 2:51 AM, Guillaume Smet < > guillaume.smet at gmail.com> > > wrote: > > > >> Hi, > >> > >> I see that we have a migration-guide.adoc document in the repository: > >> https://github.com/hibernate/hibernate-orm/blob/master/migra > >> tion-guide.adoc > >> > >> and we also have migration guides in the wiki: > >> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 > >> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.3 > >> > >> Is there a reason why we have both? > >> > >> Lately, I updated the wiki one and I just noticed Gail updated the > source > >> one. So if we keep both, we will need to keep them in sync but I'm not > >> sure > >> there's any value in keeping both. Except having a migration guide > bundled > >> in the zip archive, maybe? > >> > >> Thoughts? > >> > >> 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 aepedraza3117 at gmail.com Mon Jul 16 20:41:32 2018 From: aepedraza3117 at gmail.com (Alvaro Pedraza) Date: Mon, 16 Jul 2018 21:41:32 -0300 Subject: [hibernate-dev] HHH-3138 - make constructor of DynamicMapEntityTuplizer public Message-ID: <921B72AF-2F16-4AC7-B2B1-46ADDE1CE652@gmail.com> Hi, I asigned myself this ticket and left a comment but unfortunately no feedback yet. https://hibernate.atlassian.net/browse/HHH-3138 This leads me to 2 questions: The first is the very same in the comment, which is if subclassing in DynamicMapEntityTuplizer is desirable? Please refer to the ticket for discussion The second is about what can I assume as a contributor. I mean, Is always the ticket a holy word (i.e. what the ticket says, should be done) or it is always debatable? I understand that I?m taking low priority tickets (because I?m almost a newbie contributor and I don?t feel like taking some more important ones) but how long should I wait to get some feedback in the comments? Thanks in advance for your answers. Best regards: Alvaro Pedraza From aepedraza3117 at gmail.com Tue Jul 17 00:03:10 2018 From: aepedraza3117 at gmail.com (Alvaro Pedraza) Date: Tue, 17 Jul 2018 01:03:10 -0300 Subject: [hibernate-dev] Failing test for issue HHH-12688 Message-ID: <406FD699-8EE4-4B2A-8E63-BFBA03DB6FF3@gmail.com> Hi, working in something else I ran ./gradlew tests and exited with one failing test at org.hibernate.test.annotations.uniqueconstraint.UniqueConstraintBatchingTest I?ve been seeing https://hibernate.atlassian.net/browse/HHH-12688 and it?s been closed and pushed, but the test is failing for me and just wanted to raise a flag just in case. Hope this helps. Best regards: Alvaro E. Pedraza From guillaume.smet at gmail.com Tue Jul 17 05:31:13 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 17 Jul 2018 11:31:13 +0200 Subject: [hibernate-dev] Failing test for issue HHH-12688 In-Reply-To: <406FD699-8EE4-4B2A-8E63-BFBA03DB6FF3@gmail.com> References: <406FD699-8EE4-4B2A-8E63-BFBA03DB6FF3@gmail.com> Message-ID: Does it fail every time you run the build or is it a transient failure? If it's consistent, please check the result of the test (the Gradle log points you to a HTML file containing all the info) and paste the full error message and stracktrace here. Information about your environment might also be useful: OS, JDK version... Thanks! On Tue, Jul 17, 2018 at 6:04 AM Alvaro Pedraza wrote: > Hi, working in something else I ran ./gradlew tests and exited with one > failing test at > org.hibernate.test.annotations.uniqueconstraint.UniqueConstraintBatchingTest > I?ve been seeing https://hibernate.atlassian.net/browse/HHH-12688 < > https://hibernate.atlassian.net/browse/HHH-12688> and it?s been closed > and pushed, but the test is failing for me and just wanted to raise a flag > just in case. > Hope this helps. > > Best regards: Alvaro E. Pedraza > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Tue Jul 17 05:32:50 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 17 Jul 2018 10:32:50 +0100 Subject: [hibernate-dev] HHH-3138 - make constructor of DynamicMapEntityTuplizer public In-Reply-To: <921B72AF-2F16-4AC7-B2B1-46ADDE1CE652@gmail.com> References: <921B72AF-2F16-4AC7-B2B1-46ADDE1CE652@gmail.com> Message-ID: Hi Alvaro, welcome :-) The ticket descriptions can be debated; we can all be wrong, or you might have a better idea. Regarding feedback times: I'm sorry we're a bit slow. There are many things which are urgent - or we're more interested in - and since it's summer so many are on holidays. It might take a week - this was a bit too long so you did well to raise the mail here. Feel free to join the chat on IRC or HipChat? See the "contribute" section on [1] for links and instructions. In the specific example of HHH-3138, I guess people didn't comment as there is no clear problem to be solved. It might help to explain why you want to subclass a DynamicMapEntityTuplizer - but I'm just guessing as I'm not familiar with that area of the code so I hope you get the attention of someone more familiar with that code. Thanks, Sanne 1 - http://hibernate.org/community/ On Tue, 17 Jul 2018 at 01:42, Alvaro Pedraza wrote: > > Hi, I asigned myself this ticket and left a comment but unfortunately no feedback yet. > https://hibernate.atlassian.net/browse/HHH-3138 > This leads me to 2 questions: > The first is the very same in the comment, which is if subclassing in DynamicMapEntityTuplizer is desirable? Please refer to the ticket for discussion > The second is about what can I assume as a contributor. I mean, Is always the ticket a holy word (i.e. what the ticket says, should be done) or it is always debatable? I understand that I?m taking low priority tickets (because I?m almost a newbie contributor and I don?t feel like taking some more important ones) but how long should I wait to get some feedback in the comments? > Thanks in advance for your answers. > > Best regards: Alvaro Pedraza > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From rory.odonnell at oracle.com Tue Jul 17 07:16:44 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 17 Jul 2018 12:16:44 +0100 Subject: [hibernate-dev] JDK 11 Early Access build 22 & JDK 12 Early Access b02 are available. Message-ID: <49122755-9177-c94e-6254-8591426291c6@oracle.com> Hi Sanne, *JDK 11 is in Rampdown Phase one* * *The overall feature set is frozen. No further JEPs will be targeted to this release.* * *Rampdown Phase two is scheduled to start * *26th of July* **JDK 11 EA build 22 , *****under both the GPL and Oracle EA licenses, is now available at **http://jdk.java.net/11**. *** * Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes *FOSS fixes in recent builds.* * JBoss Netty (b17) - JDK-8203937 (b17) * JUnit5 & other Foss Projects (b22) -JDK-8206355 **Notable changes in JDK 11 EA *build 22* * New Collection.toArray(IntFunction) Default Method (JDK-8060192 ) * Make some system properties effectively readonly (JDK-8066709 ) * Obsolete Support for Commercial Features (JDK-8202331 ) * JFR start failure after AppCDS archive created with JFR StartFlightRecording (JDK-8203664 ) * Change to policy for the default set of modules resolved when compiling or running code on the class path (JDK-8197532 ) *JDK 12 Early Access Build 02 is available at **http://jdk.java.net/12/* * OpenJDK builds o These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception . * Changes in this build are listed here *The Quality Report for July 2018 is published **here * * With the new six months release , we now publish the Quality report every three months. * Thanks to all the FOSS Projects for logging bugs against the JDK 11 EA Builds! Rgds,Rory [1] http://openjdk.java.net/projects/jdk/11/ From guillaume.smet at gmail.com Tue Jul 17 08:45:10 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 17 Jul 2018 14:45:10 +0200 Subject: [hibernate-dev] HHH-3138 - make constructor of DynamicMapEntityTuplizer public In-Reply-To: References: <921B72AF-2F16-4AC7-B2B1-46ADDE1CE652@gmail.com> Message-ID: Hi, On Tue, Jul 17, 2018 at 11:33 AM Sanne Grinovero wrote: > In the specific example of HHH-3138, I guess people didn't comment as > there is no clear problem to be solved. It might help to explain why > you want to subclass a DynamicMapEntityTuplizer - but I'm just > guessing as I'm not familiar with that area of the code so I hope you > get the attention of someone more familiar with that code What I can suppose is that the OP customized the tuplizer with @Tuplizer and would have liked to use DynamicMapEntityTuplizer as a base for his custom one. We can ask in the issue but it's a very old one so I'm not sure we'll get an answer. -- Guillaume From sanne at hibernate.org Tue Jul 17 09:06:12 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 17 Jul 2018 14:06:12 +0100 Subject: [hibernate-dev] HHH-3138 - make constructor of DynamicMapEntityTuplizer public In-Reply-To: References: <921B72AF-2F16-4AC7-B2B1-46ADDE1CE652@gmail.com> Message-ID: On Tue, 17 Jul 2018 at 13:45, Guillaume Smet wrote: > > Hi, > > On Tue, Jul 17, 2018 at 11:33 AM Sanne Grinovero wrote: >> >> In the specific example of HHH-3138, I guess people didn't comment as >> there is no clear problem to be solved. It might help to explain why >> you want to subclass a DynamicMapEntityTuplizer - but I'm just >> guessing as I'm not familiar with that area of the code so I hope you >> get the attention of someone more familiar with that code > > > What I can suppose is that the OP customized the tuplizer with @Tuplizer and would have liked to use DynamicMapEntityTuplizer as a base for his custom one. My point was that people who can better explain what and why they need changes are more likely to get a quick answer. > > We can ask in the issue but it's a very old one so I'm not sure we'll get an answer. > > -- > Guillaume From steve at hibernate.org Tue Jul 17 09:21:48 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 17 Jul 2018 08:21:48 -0500 Subject: [hibernate-dev] HHH-3138 - make constructor of DynamicMapEntityTuplizer public In-Reply-To: References: <921B72AF-2F16-4AC7-B2B1-46ADDE1CE652@gmail.com> Message-ID: Sorry for the late reply. As Sanne indicated, we are all very busy with our own work. Reaching out here and "championing" a particular issue that you are interested in working on is a great way to make sure it is not missed. Anyway, I replied on the Jira. On Tue, Jul 17, 2018 at 8:11 AM Sanne Grinovero wrote: > Hi Alvaro, > > welcome :-) > > The ticket descriptions can be debated; we can all be wrong, or you > might have a better idea. > > Regarding feedback times: I'm sorry we're a bit slow. There are many > things which are urgent - or we're more interested in - and since it's > summer so many are on holidays. It might take a week - this was a bit > too long so you did well to raise the mail here. > > Feel free to join the chat on IRC or HipChat? See the "contribute" > section on [1] for links and instructions. > > In the specific example of HHH-3138, I guess people didn't comment as > there is no clear problem to be solved. It might help to explain why > you want to subclass a DynamicMapEntityTuplizer - but I'm just > guessing as I'm not familiar with that area of the code so I hope you > get the attention of someone more familiar with that code. > > Thanks, > Sanne > > 1 - http://hibernate.org/community/ > On Tue, 17 Jul 2018 at 01:42, Alvaro Pedraza > wrote: > > > > Hi, I asigned myself this ticket and left a comment but unfortunately no > feedback yet. > > https://hibernate.atlassian.net/browse/HHH-3138 > > This leads me to 2 questions: > > The first is the very same in the comment, which is if subclassing in > DynamicMapEntityTuplizer is desirable? Please refer to the ticket for > discussion > > The second is about what can I assume as a contributor. I mean, Is > always the ticket a holy word (i.e. what the ticket says, should be done) > or it is always debatable? I understand that I?m taking low priority > tickets (because I?m almost a newbie contributor and I don?t feel like > taking some more important ones) but how long should I wait to get some > feedback in the comments? > > Thanks in advance for your answers. > > > > Best regards: Alvaro Pedraza > > _______________________________________________ > > 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 Jul 17 09:28:33 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 17 Jul 2018 15:28:33 +0200 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi! Here are the minutes of our NoORM IRC meeting: 15:26 < jbott> Meeting ended Tue Jul 17 13:26:02 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:26 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-07-17-13.01.html 15:26 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-07-17-13.01.txt 15:26 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-07-17-13.01.log.html -- Guillaume From aepedraza3117 at gmail.com Tue Jul 17 10:53:17 2018 From: aepedraza3117 at gmail.com (Alvaro Pedraza) Date: Tue, 17 Jul 2018 11:53:17 -0300 Subject: [hibernate-dev] Failing test for issue HHH-12688 In-Reply-To: References: <406FD699-8EE4-4B2A-8E63-BFBA03DB6FF3@gmail.com> Message-ID: I ran it again and seems to be failing consistently. This is the info I can get: Stacktrace: java.lang.AssertionError: expected:<1> but was:<0> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:631) at org.hibernate.test.annotations.uniqueconstraint.UniqueConstraintBatchingTest.testBatching(UniqueConstraintBatchingTest.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:45) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298) at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.lang.Thread.run(Thread.java:745) Std Output: 11:04:52,916 INFO Version:46 - HHH000412: Hibernate Core {[WORKING]} 11:04:52,968 INFO Environment:198 - HHH000205: Loaded properties from resource hibernate.properties: {hibernate.connection.driver_class=org.h2.Driver, javax.persistence.validation.mode=NONE, hibernate.service.allow_crawling=false, hibernate.max_fetch_depth=5, hibernate.dialect=org.hibernate.dialect.H2Dialect, hibernate.format_sql=true, hibernate.cache.region.factory_class=org.hibernate.testing.cache.CachingRegionFactory, hibernate.hql.bulk_id_strategy.global_temporary.drop_tables=true, hibernate.connection.username=sa, hibernate.cache.region_prefix=hibernate.test, hibernate.connection.url=jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;LOCK_TIMEOUT=10000, hibernate.bytecode.use_reflection_optimizer=false, hibernate.show_sql=false, hibernate.connection.password=****, hibernate.session.events.log=true, hibernate.connection.pool_size=5} 11:04:53,543 INFO Dialect:157 - HHH000400: Using dialect: org.hibernate.dialect.H2Dialect 11:04:56,792 INFO CustomRunner:116 - BeforeClass: org.hibernate.test.annotations.uniqueconstraint.UniqueConstraintBatchingTest 11:04:56,794 INFO Dialect:157 - HHH000400: Using dialect: org.hibernate.dialect.H2Dialect 11:04:56,899 INFO CustomRunner:123 - Test: testBatching 11:04:57,277 INFO LogHelper:31 - HHH000204: Processing PersistenceUnitInfo [ name: UniqueConstraintBatchingTest ...] 11:05:00,085 WARN CachingRegionFactory:48 - org.hibernate.testing.cache.CachingRegionFactory should be only used for testing. 11:05:00,085 DEBUG RegionFactoryInitiator:49 - Cache region factory : org.hibernate.testing.cache.CachingRegionFactory 11:05:00,260 INFO Version:49 - HCANN000001: Hibernate Commons Annotations {5.0.4.Final} 11:05:01,801 WARN pooling:73 - HHH10001002: Using Hibernate built-in connection pool (not for production use!) 11:05:02,541 INFO pooling:129 - HHH10001005: using driver [org.h2.Driver] at URL [jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;LOCK_TIMEOUT=10000] 11:05:02,542 INFO pooling:138 - HHH10001001: Connection properties: {user=sa, password=****} 11:05:02,542 INFO pooling:143 - HHH10001003: Autocommit mode: false 11:05:02,566 INFO DriverManagerConnectionProviderImpl:281 - HHH000115: Hibernate connection pool size: 5 (min=1) 11:05:03,436 INFO Dialect:157 - HHH000400: Using dialect: org.hibernate.dialect.H2Dialect 11:05:08,568 INFO beans:73 - HHH10005002: No explicit CDI BeanManager reference was passed to Hibernate, but CDI is available on the Hibernate ClassLoader. 11:05:12,424 DEBUG SQL:94 - drop table House if exists 11:05:12,457 INFO access:47 - HHH10001501: Connection obtained from JdbcConnectionAccess [org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator$ConnectionProviderJdbcConnectionAccess at 33284695] for (non-JTA) DDL execution was not in auto-commit mode; the Connection 'local transaction' will be committed and the Connection will be set into auto-commit mode. 11:05:12,458 DEBUG SQL:94 - drop table Room if exists 11:05:12,475 DEBUG SQL:94 - create table House ( id bigint not null, height bigint, cost integer, room_id bigint not null, primary key (id) ) 11:05:12,477 INFO access:47 - HHH10001501: Connection obtained from JdbcConnectionAccess [org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator$ConnectionProviderJdbcConnectionAccess at 65d0ead8] for (non-JTA) DDL execution was not in auto-commit mode; the Connection 'local transaction' will be committed and the Connection will be set into auto-commit mode. 11:05:12,514 DEBUG SQL:94 - create table Room ( id bigint not null, name varchar(255), primary key (id) ) 11:05:12,516 DEBUG SQL:94 - alter table House add constraint uniqueWithInherited unique (room_id, cost) 11:05:12,537 DEBUG SQL:94 - alter table House add constraint FKhmla6idcdpqljalxpwltebw88 foreign key (room_id) references Room 11:05:12,557 INFO SchemaCreatorImpl:489 - HHH000476: Executing import script 'org.hibernate.tool.schema.internal.exec.ScriptSourceInputNonExistentImpl at 77576dd0' 11:05:13,999 DEBUG StatisticsInitiator:101 - Statistics initialized [enabled=false] 11:05:14,500 TRACE Cascade:86 - Processing cascade ACTION_PERSIST_ON_FLUSH for: org.hibernate.test.annotations.uniqueconstraint.Room 11:05:14,500 TRACE Cascade:172 - Done processing cascade ACTION_PERSIST_ON_FLUSH for: org.hibernate.test.annotations.uniqueconstraint.Room 11:05:14,691 DEBUG SQL:94 - insert into Room (name, id) values (?, ?) 11:05:14,720 TRACE BasicBinder:65 - binding parameter [1] as [VARCHAR] - [livingRoom] 11:05:14,721 TRACE BasicBinder:65 - binding parameter [2] as [BIGINT] - [1] 11:05:14,781 INFO StatisticalLoggingSessionEventListener:258 - Session Metrics { 65789 nanoseconds spent acquiring 1 JDBC connections; 109298 nanoseconds spent releasing 1 JDBC connections; 963539 nanoseconds spent preparing 1 JDBC statements; 0 nanoseconds spent executing 0 JDBC statements; 23443890 nanoseconds spent executing 1 JDBC batches; 0 nanoseconds spent performing 0 L2C puts; 0 nanoseconds spent performing 0 L2C hits; 0 nanoseconds spent performing 0 L2C misses; 319872705 nanoseconds spent executing 1 flushes (flushing a total of 1 entities and 0 collections); 0 nanoseconds spent executing 0 partial-flushes (flushing a total of 0 entities and 0 collections) } 11:05:14,797 DEBUG SQL:94 - select room_.id, room_.name as name2_1_ from Room room_ where room_.id=? 11:05:14,798 TRACE BasicBinder:65 - binding parameter [1] as [BIGINT] - [1] 11:05:14,841 TRACE BasicExtractor:61 - extracted value ([name2_1_] : [VARCHAR]) - [livingRoom] 11:05:14,842 TRACE Cascade:86 - Processing cascade ACTION_PERSIST_ON_FLUSH for: org.hibernate.test.annotations.uniqueconstraint.House 11:05:14,843 TRACE Cascade:172 - Done processing cascade ACTION_PERSIST_ON_FLUSH for: org.hibernate.test.annotations.uniqueconstraint.House 11:05:14,843 DEBUG SQL:94 - insert into House (height, room_id, cost, id) values (?, ?, ?, ?) 11:05:14,844 TRACE BasicBinder:65 - binding parameter [1] as [BIGINT] - [1000] 11:05:14,845 TRACE BasicBinder:65 - binding parameter [2] as [BIGINT] - [1] 11:05:14,847 TRACE BasicBinder:65 - binding parameter [3] as [INTEGER] - [100] 11:05:14,847 TRACE BasicBinder:65 - binding parameter [4] as [BIGINT] - [1] 11:05:14,849 INFO StatisticalLoggingSessionEventListener:258 - Session Metrics { 16103 nanoseconds spent acquiring 1 JDBC connections; 30533 nanoseconds spent releasing 1 JDBC connections; 491727 nanoseconds spent preparing 2 JDBC statements; 1032600 nanoseconds spent executing 1 JDBC statements; 560252 nanoseconds spent executing 1 JDBC batches; 0 nanoseconds spent performing 0 L2C puts; 0 nanoseconds spent performing 0 L2C hits; 0 nanoseconds spent performing 0 L2C misses; 6714811 nanoseconds spent executing 1 flushes (flushing a total of 1 entities and 0 collections); 0 nanoseconds spent executing 0 partial-flushes (flushing a total of 0 entities and 0 collections) } 11:05:14,852 DEBUG SQL:94 - select room_.id, room_.name as name2_1_ from Room room_ where room_.id=? 11:05:14,853 TRACE BasicBinder:65 - binding parameter [1] as [BIGINT] - [1] 11:05:14,854 TRACE BasicExtractor:61 - extracted value ([name2_1_] : [VARCHAR]) - [livingRoom] 11:05:14,855 TRACE Cascade:86 - Processing cascade ACTION_PERSIST_ON_FLUSH for: org.hibernate.test.annotations.uniqueconstraint.House 11:05:14,856 TRACE Cascade:172 - Done processing cascade ACTION_PERSIST_ON_FLUSH for: org.hibernate.test.annotations.uniqueconstraint.House 11:05:14,857 DEBUG SQL:94 - insert into House (height, room_id, cost, id) values (?, ?, ?, ?) 11:05:14,858 TRACE BasicBinder:65 - binding parameter [1] as [BIGINT] - [1001] 11:05:14,858 TRACE BasicBinder:65 - binding parameter [2] as [BIGINT] - [1] 11:05:14,859 TRACE BasicBinder:65 - binding parameter [3] as [INTEGER] - [100] 11:05:14,859 TRACE BasicBinder:65 - binding parameter [4] as [BIGINT] - [2] 11:05:14,876 INFO AbstractBatchImpl:193 - HHH000010: On release of batch it still contained JDBC statements 11:05:14,877 ERROR BatchingBatch:127 - HHH000315: Exception executing batch [org.h2.jdbc.JdbcBatchUpdateException: Violaci?n de indice de Unicidad ? Clave primaria: "UNIQUEWITHINHERITED_INDEX_4 ON PUBLIC.HOUSE(ROOM_ID, COST) VALUES (1, 100, 1)" Unique index or primary key violation: "UNIQUEWITHINHERITED_INDEX_4 ON PUBLIC.HOUSE(ROOM_ID, COST) VALUES (1, 100, 1)"; SQL statement: insert into House (height, room_id, cost, id) values (?, ?, ?, ?) [23505-196]], SQL: insert into House (height, room_id, cost, id) values (?, ?, ?, ?) 11:05:14,878 WARN SqlExceptionHelper:137 - SQL Error: 23505, SQLState: 23505 11:05:14,878 ERROR SqlExceptionHelper:142 - Violaci?n de indice de Unicidad ? Clave primaria: "UNIQUEWITHINHERITED_INDEX_4 ON PUBLIC.HOUSE(ROOM_ID, COST) VALUES (1, 100, 1)" Unique index or primary key violation: "UNIQUEWITHINHERITED_INDEX_4 ON PUBLIC.HOUSE(ROOM_ID, COST) VALUES (1, 100, 1)"; SQL statement: insert into House (height, room_id, cost, id) values (?, ?, ?, ?) [23505-196] 11:05:14,915 ERROR ExceptionMapperStandardImpl:39 - HHH000346: Error during managed flush [org.hibernate.exception.ConstraintViolationException: could not execute batch] 11:05:14,930 INFO StatisticalLoggingSessionEventListener:258 - Session Metrics { 13637 nanoseconds spent acquiring 1 JDBC connections; 74345 nanoseconds spent releasing 1 JDBC connections; 300536 nanoseconds spent preparing 2 JDBC statements; 98205 nanoseconds spent executing 1 JDBC statements; 16805422 nanoseconds spent executing 1 JDBC batches; 0 nanoseconds spent performing 0 L2C puts; 0 nanoseconds spent performing 0 L2C hits; 0 nanoseconds spent performing 0 L2C misses; 40652537 nanoseconds spent executing 1 flushes (flushing a total of 1 entities and 0 collections); 0 nanoseconds spent executing 0 partial-flushes (flushing a total of 0 entities and 0 collections) } 11:05:14,931 INFO SchemaDropperImpl$DelayedDropActionImpl:524 - HHH000477: Starting delayed evictData of schema as part of SessionFactory shut-down' 11:05:14,948 DEBUG SQL:94 - drop table House if exists 11:05:14,948 INFO access:47 - HHH10001501: Connection obtained from JdbcConnectionAccess [org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator$ConnectionProviderJdbcConnectionAccess at 3c44b653] for (non-JTA) DDL execution was not in auto-commit mode; the Connection 'local transaction' will be committed and the Connection will be set into auto-commit mode. 11:05:14,965 DEBUG SQL:94 - drop table Room if exists 11:05:14,969 INFO pooling:233 - HHH10001008: Cleaning up connection pool [jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;LOCK_TIMEOUT=10000] Error msg: Loading class `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver'. The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary. I?m running under Mac OS 10.13.4, JDK 1.8.0 I couldn?t analyze the report yet but I can do it this afternoon (is almost noon at the time of writing this) Hope this helps. Best regards: Alvaro E. Pedraza > El 17 jul. 2018, a las 06:31, Guillaume Smet > escribi?: > > Does it fail every time you run the build or is it a transient failure? > > If it's consistent, please check the result of the test (the Gradle log points you to a HTML file containing all the info) and paste the full error message and stracktrace here. > > Information about your environment might also be useful: OS, JDK version... > > Thanks! > > On Tue, Jul 17, 2018 at 6:04 AM Alvaro Pedraza > wrote: > Hi, working in something else I ran ./gradlew tests and exited with one failing test at org.hibernate.test.annotations.uniqueconstraint.UniqueConstraintBatchingTest I?ve been seeing https://hibernate.atlassian.net/browse/HHH-12688 > and it?s been closed and pushed, but the test is failing for me and just wanted to raise a flag just in case. > Hope this helps. > > Best regards: Alvaro E. Pedraza > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From aepedraza3117 at gmail.com Tue Jul 17 23:15:46 2018 From: aepedraza3117 at gmail.com (Alvaro Pedraza) Date: Wed, 18 Jul 2018 00:15:46 -0300 Subject: [hibernate-dev] Failing Analysis Message-ID: Hi, I'm wondering if there is something wrong with LGTM Java analysis, because it has failed in my 2 open PR?s. https://github.com/hibernate/hibernate-orm/pull/2357 https://github.com/hibernate/hibernate-orm/pull/2433 Seeing the log in the first I got the message: [2018-07-15 15:50:19] [autobuild] [2018-07-15 15:50:19] [ERROR] Parsing error in file /opt/src/hibernate-core/src/test/java/org/hibernate/test/mappingexception/InvalidMapping.hbm.xml It seems to be a file to test mapping, so I assume there is something wrong with the analysis configuration as this file should not be analyzed at all, am I right? Besides, my changes don?t affect that code. Thanks in advance for your answers. Best regards: Alvaro E. Pedraza From guillaume.smet at gmail.com Wed Jul 18 07:39:01 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 18 Jul 2018 13:39:01 +0200 Subject: [hibernate-dev] ORM - Migration guides: wiki or source repository? In-Reply-To: References: Message-ID: I have merged the 5.2 and 5.3 migration guides in the code base (Yoann and I had added a few things on the wiki page) and removed the content of the wiki pages to point to the versions in the Git repository. I updated the website to point to the code base too. The only one that is a bit weird is the 5.1 migration guide as it points to a document on the website but I let it that way for now. So from now on, the only document to be updated is the migration-guide.adoc document at the root of the repository. -- Guillaume On Mon, Jul 16, 2018 at 9:04 PM Steve Ebersole wrote: > The intention was to use the wiki just as a collection of all the links[1] > and have each of those links point to the real migration guides which are > kept in the appropriate source branches. > > It was decided to just not do the effort to move older migration guides > which used to be fully written in the wiki. > > > [1] https://github.com/hibernate/hibernate-orm/wiki/Migration-Guides. > > On Mon, Jul 16, 2018 at 1:58 PM Gail Badner wrote: > >> If there is any reason to keep the wiki, IMO, it should just refer to the >> version at the appropriate branch in github, e.g, >> https://github.com/hibernate/hibernate-orm/blob/5.3/migration-guide.adoc. >> >> On Mon, Jul 16, 2018 at 11:40 AM, Gail Badner wrote: >> >> > I only update the source... >> > >> > On Mon, Jul 16, 2018 at 2:51 AM, Guillaume Smet < >> guillaume.smet at gmail.com> >> > wrote: >> > >> >> Hi, >> >> >> >> I see that we have a migration-guide.adoc document in the repository: >> >> https://github.com/hibernate/hibernate-orm/blob/master/migra >> >> tion-guide.adoc >> >> >> >> and we also have migration guides in the wiki: >> >> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 >> >> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.3 >> >> >> >> Is there a reason why we have both? >> >> >> >> Lately, I updated the wiki one and I just noticed Gail updated the >> source >> >> one. So if we keep both, we will need to keep them in sync but I'm not >> >> sure >> >> there's any value in keeping both. Except having a migration guide >> bundled >> >> in the zip archive, maybe? >> >> >> >> Thoughts? >> >> >> >> 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 guillaume.smet at gmail.com Wed Jul 18 08:36:40 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 18 Jul 2018 14:36:40 +0200 Subject: [hibernate-dev] Failing Analysis In-Reply-To: References: Message-ID: I also had a few issues with LGTM analysis lately. I quickly check it's not a new Java error and move on. On Wed, Jul 18, 2018 at 5:16 AM Alvaro Pedraza wrote: > Hi, I'm wondering if there is something wrong with LGTM Java analysis, > because it has failed in my 2 open PR?s. > https://github.com/hibernate/hibernate-orm/pull/2357 < > https://github.com/hibernate/hibernate-orm/pull/2357> > https://github.com/hibernate/hibernate-orm/pull/2433 < > https://github.com/hibernate/hibernate-orm/pull/2433> > Seeing the log in the first I got the message: > [2018-07-15 15:50:19] [autobuild] [2018-07-15 15:50:19] [ERROR] Parsing > error in file > /opt/src/hibernate-core/src/test/java/org/hibernate/test/mappingexception/InvalidMapping.hbm.xml > It seems to be a file to test mapping, so I assume there is something > wrong with the analysis configuration as this file should not be analyzed > at all, am I right? > Besides, my changes don?t affect that code. > Thanks in advance for your answers. > > Best regards: Alvaro E. Pedraza > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at hibernate.org Wed Jul 18 10:27:21 2018 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Wed, 18 Jul 2018 16:27:21 +0200 Subject: [hibernate-dev] Hibernate Validator 6.0.11.Final released Message-ID: Hi, We just released Hibernate Validator 6.0.11.Final. The main goal of this release is to improve our compatibility with the upcoming JDK 11. It also contains a couple of bugfixes. More information here: http://in.relation.to/2018/07/18/hibernate-validator-6011-final-out/ Have a nice day. -- Guillaume From lalmeras at gmail.com Wed Jul 18 17:36:44 2018 From: lalmeras at gmail.com (Laurent Almeras) Date: Wed, 18 Jul 2018 23:36:44 +0200 Subject: [hibernate-dev] [ehcache2] package name fix needed in 5.3.x documentation Message-ID: <43af705e-80f2-a8c5-7ec8-77662f27f572@gmail.com> Hi, Sorry to bother you on a deprecated feature subject, but I think the package names provided in documentation are broken : https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html#caching-provider-ehcache-region-factory Do we agree that the correct names are org.hibernate.cache.ehcache.internal.SingletonEhCacheRegionFactory and org.hibernate.cache.ehcache.internal.EhCacheRegionFactory ? Not sure I'm right because of the .internal package; I spontaneously understand it as ? private, do not touch ? package. If I'm not wrong, I can open a Jira and propose a PR. -- Laurent Almeras From guillaume.smet at gmail.com Thu Jul 19 04:16:10 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 19 Jul 2018 10:16:10 +0200 Subject: [hibernate-dev] [ehcache2] package name fix needed in 5.3.x documentation In-Reply-To: <43af705e-80f2-a8c5-7ec8-77662f27f572@gmail.com> References: <43af705e-80f2-a8c5-7ec8-77662f27f572@gmail.com> Message-ID: Hi Laurent, Good catch. The classes have been moved to an internal package and we should now use the short names instead. Created https://hibernate.atlassian.net/browse/HHH-12829, will fix right away. -- Guillaume On Wed, Jul 18, 2018 at 11:43 PM Laurent Almeras wrote: > Hi, > > Sorry to bother you on a deprecated feature subject, but I think the > package names provided in documentation are broken : > > https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html#caching-provider-ehcache-region-factory > > Do we agree that the correct names are > org.hibernate.cache.ehcache.internal.SingletonEhCacheRegionFactory and > org.hibernate.cache.ehcache.internal.EhCacheRegionFactory ? Not sure I'm > right because of the .internal package; I spontaneously understand it as > ? private, do not touch ? package. > > If I'm not wrong, I can open a Jira and propose a PR. > > > -- > Laurent Almeras > > > _______________________________________________ > 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 Jul 19 04:19:48 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 19 Jul 2018 10:19:48 +0200 Subject: [hibernate-dev] [ehcache2] package name fix needed in 5.3.x documentation In-Reply-To: References: <43af705e-80f2-a8c5-7ec8-77662f27f572@gmail.com> Message-ID: By the way, did you have an error using the old names? Because they should still be supported. On Thu, Jul 19, 2018 at 10:16 AM Guillaume Smet wrote: > Hi Laurent, > > Good catch. The classes have been moved to an internal package and we > should now use the short names instead. > > Created https://hibernate.atlassian.net/browse/HHH-12829, will fix right > away. > > -- > Guillaume > > On Wed, Jul 18, 2018 at 11:43 PM Laurent Almeras > wrote: > >> Hi, >> >> Sorry to bother you on a deprecated feature subject, but I think the >> package names provided in documentation are broken : >> >> https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html#caching-provider-ehcache-region-factory >> >> Do we agree that the correct names are >> org.hibernate.cache.ehcache.internal.SingletonEhCacheRegionFactory and >> org.hibernate.cache.ehcache.internal.EhCacheRegionFactory ? Not sure I'm >> right because of the .internal package; I spontaneously understand it as >> ? private, do not touch ? package. >> >> If I'm not wrong, I can open a Jira and propose a PR. >> >> >> -- >> Laurent Almeras >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From lalmeras at gmail.com Thu Jul 19 15:08:09 2018 From: lalmeras at gmail.com (Laurent Almeras) Date: Thu, 19 Jul 2018 21:08:09 +0200 Subject: [hibernate-dev] [ehcache2] package name fix needed in 5.3.x documentation In-Reply-To: References: <43af705e-80f2-a8c5-7ec8-77662f27f572@gmail.com> Message-ID: <57cf7e89-92ff-41b4-ee15-cea648f173b7@gmail.com> Mistake on my side. As I configure programmaticaly Hibernate, I use .class.getName() code to populate my Hibernate properties. So I directly stepped into a class not found error when I update. I just modify my code to use strings provided in documentation and it works as expected. So not sure any modification is needed in documentation on a deprecated feature and a corner-case (use of classes in code whereas it is not needed or advised in document) even thought this qualified-classname-like notation may be error prone. Sorry for the noise Le 19/07/2018 ? 10:19, Guillaume Smet a ?crit?: > By the way, did you have an error using the old names? > > Because they should still be supported. > > On Thu, Jul 19, 2018 at 10:16 AM Guillaume Smet > > wrote: > > Hi Laurent, > > Good catch. The classes have been moved to an internal package and > we should now use the short names instead. > > Created https://hibernate.atlassian.net/browse/HHH-12829, will fix > right away. > > -- > Guillaume > > On Wed, Jul 18, 2018 at 11:43 PM Laurent Almeras > > wrote: > > Hi, > > Sorry to bother you on a deprecated feature subject, but I > think the > package names provided in documentation are broken : > https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html#caching-provider-ehcache-region-factory > > Do we agree that the correct names are > org.hibernate.cache.ehcache.internal.SingletonEhCacheRegionFactory > and > org.hibernate.cache.ehcache.internal.EhCacheRegionFactory ? > Not sure I'm > right because of the .internal package; I spontaneously > understand it as > ? private, do not touch ? package. > > If I'm not wrong, I can open a Jira and propose a PR. > > > -- > Laurent Almeras > > > _______________________________________________ > 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 Jul 19 15:26:11 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 19 Jul 2018 21:26:11 +0200 Subject: [hibernate-dev] [ehcache2] package name fix needed in 5.3.x documentation In-Reply-To: <57cf7e89-92ff-41b4-ee15-cea648f173b7@gmail.com> References: <43af705e-80f2-a8c5-7ec8-77662f27f572@gmail.com> <57cf7e89-92ff-41b4-ee15-cea648f173b7@gmail.com> Message-ID: It wasn't noise, I updated the documentation to use the new short names: https://github.com/hibernate/hibernate-orm/commit/f8964847dd40f64e1f478eba47c767be98742125 This is what you should use from now on. Cheers On Thu, Jul 19, 2018 at 9:08 PM Laurent Almeras wrote: > Mistake on my side. As I configure programmaticaly Hibernate, I use > .class.getName() code to populate my Hibernate properties. So I > directly stepped into a class not found error when I update. > > I just modify my code to use strings provided in documentation and it > works as expected. So not sure any modification is needed in documentation > on a deprecated feature and a corner-case (use of classes in code whereas > it is not needed or advised in document) even thought this > qualified-classname-like notation may be error prone. > > Sorry for the noise > > Le 19/07/2018 ? 10:19, Guillaume Smet a ?crit : > > By the way, did you have an error using the old names? > > Because they should still be supported. > > On Thu, Jul 19, 2018 at 10:16 AM Guillaume Smet > wrote: > >> Hi Laurent, >> >> Good catch. The classes have been moved to an internal package and we >> should now use the short names instead. >> >> Created https://hibernate.atlassian.net/browse/HHH-12829, will fix right >> away. >> >> -- >> Guillaume >> >> On Wed, Jul 18, 2018 at 11:43 PM Laurent Almeras >> wrote: >> >>> Hi, >>> >>> Sorry to bother you on a deprecated feature subject, but I think the >>> package names provided in documentation are broken : >>> >>> https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html#caching-provider-ehcache-region-factory >>> >>> Do we agree that the correct names are >>> org.hibernate.cache.ehcache.internal.SingletonEhCacheRegionFactory and >>> org.hibernate.cache.ehcache.internal.EhCacheRegionFactory ? Not sure I'm >>> right because of the .internal package; I spontaneously understand it as >>> ? private, do not touch ? package. >>> >>> If I'm not wrong, I can open a Jira and propose a PR. >>> >>> >>> -- >>> Laurent Almeras >>> >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > From davide at hibernate.org Fri Jul 20 06:16:43 2018 From: davide at hibernate.org (Davide D'Alto) Date: Fri, 20 Jul 2018 11:16:43 +0100 Subject: [hibernate-dev] Jenkins updates Message-ID: Hello, I'm planning to update Jenkins today. This means that there might be some disruptions on CI. Let me know if you have something planned that requires CI. Cheers, Davide From davide at hibernate.org Mon Jul 23 07:57:42 2018 From: davide at hibernate.org (Davide D'Alto) Date: Mon, 23 Jul 2018 12:57:42 +0100 Subject: [hibernate-dev] Jenkins updates In-Reply-To: References: Message-ID: Hi, Jenkins is up-to-date now. Please, keep that in mind if you face some problems. Cheers, Davide On Fri, Jul 20, 2018 at 11:16 AM, Davide D'Alto wrote: > Hello, > I'm planning to update Jenkins today. > > This means that there might be some disruptions on CI. > > Let me know if you have something planned that requires CI. > > Cheers, > Davide From postmaster at lists.jboss.org Mon Jul 23 17:06:13 2018 From: postmaster at lists.jboss.org (The Post Office) Date: Tue, 24 Jul 2018 05:06:13 +0800 Subject: [hibernate-dev] Returned mail: Data format error Message-ID: <201807232107.w6NL73p2000956@lists01.dmz-a.mwc.hst.phx2.redhat.com> The original message was received at Tue, 24 Jul 2018 05:06:13 +0800 from lists.jboss.org [65.105.173.155] ----- The following addresses had permanent fatal errors ----- From yoann at hibernate.org Tue Jul 24 09:54:14 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 24 Jul 2018 15:54:14 +0200 Subject: [hibernate-dev] Stride In-Reply-To: References: <4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com> Message-ID: I encountered yet another problem with HipChat [1], so I created a Hibernate organization in Zulip. Turns out GitHub and Google authentication are available even in the free plan. Anyone cares to join me to test it? It's here: https://hibernate.zulipchat.com/# [1] https://bitbucket.org/hipchat/hipchat-github-addon/issues/4/cant-add-organization-repo?_ga=2.132026959.1338067251.1532438591-706928748.1527601569 Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Tue, 22 May 2018 at 10:50, Guillaume Smet wrote: > On Tue, May 22, 2018 at 10:26 AM, Yoann Rodiere > wrote: > >> ... But I think the one criteria that will make us pick Stride is free >> hosting. Most other platforms either do not have a free plan, or do not >> provide all of their features to free plan users. Zulip apparently removes >> OAuth authentication in its free plan, for instance. The Infinispan team >> has OAuth authentication enabled though... Do they pay for their Zulip >> instance? >> > > Quote: "Zulip Cloud Premium is free for open source projects and a wide > variety of non-commercial entities" > > What bugged me first was the capped archives of the free offer. > > HipChat is doing a very similar thing. > > -- > Guillaume > > From guillaume.smet at hibernate.org Tue Jul 24 09:53:58 2018 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Tue, 24 Jul 2018 15:53:58 +0200 Subject: [hibernate-dev] Hibernate ORM 5.3.3.Final Message-ID: Hi, We released Hibernate ORM 5.3.3.Final with bugfixes and improvement to the support of the upcoming JDK 11. More information here: http://in.relation.to/2018/07/24/hibernate-orm-533-final-out/ . Have a nice day! -- Guillaume From yoann at hibernate.org Wed Jul 25 04:17:26 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 25 Jul 2018 10:17:26 +0200 Subject: [hibernate-dev] Hibernate Search 5.10.3.Final released Message-ID: Hello, We just published Hibernate Search version 5.10.3.Final, the third maintenance release of Hibernate Search 5.10. This release upgrades Hibernate Search to Hibernate ORM 5.3.3.Final, and adds a few minor improvements. See our blog for more information: http://in.relation.to/2018/07/25/hibernate-search-5-10-3-Final/ Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From sanne at hibernate.org Fri Jul 27 02:02:25 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 27 Jul 2018 09:02:25 +0300 Subject: [hibernate-dev] Stride In-Reply-To: References: <4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com> Message-ID: +1 to test Zulip, thanks for setting it up Yoann. Personally having used it quite a bit with other projects: it has potential but it's not particularly polished yet; in particular the mobile client has severe issues, and people are quite often failing to use the "topics" correctly. In the news today, Atlassian is killing both HipChat and Stride; Started a partnership to move to Slack: - https://www.atlassian.com/blog/announcements/new-atlassian-slack-partnership I've been forced to use Slack as well for yet another group. Sadly not OSS and infamous for needing tons of memory, but it's working very well and has some very thouroughly well designed features. So this raises more question.. - will Zulip catch up? - Do we prefer a half baked solution just because it's open? - Is the humoungous memory requirement of Slack a real problem? Tempted to just get back to IRC :/ The Atlassian&Slack partnership however is likely just a small step towards more interesting integrations across the products. On Tue, 24 Jul 2018 at 21:56, Yoann Rodiere wrote: > > I encountered yet another problem with HipChat [1], so I created a > Hibernate organization in Zulip. Turns out GitHub and Google authentication > are available even in the free plan. > > Anyone cares to join me to test it? It's here: > https://hibernate.zulipchat.com/# > > [1] > https://bitbucket.org/hipchat/hipchat-github-addon/issues/4/cant-add-organization-repo?_ga=2.132026959.1338067251.1532438591-706928748.1527601569 > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Tue, 22 May 2018 at 10:50, Guillaume Smet > wrote: > > > On Tue, May 22, 2018 at 10:26 AM, Yoann Rodiere > > wrote: > > > >> ... But I think the one criteria that will make us pick Stride is free > >> hosting. Most other platforms either do not have a free plan, or do not > >> provide all of their features to free plan users. Zulip apparently removes > >> OAuth authentication in its free plan, for instance. The Infinispan team > >> has OAuth authentication enabled though... Do they pay for their Zulip > >> instance? > >> > > > > Quote: "Zulip Cloud Premium is free for open source projects and a wide > > variety of non-commercial entities" > > > > What bugged me first was the capped archives of the free offer. > > > > HipChat is doing a very similar thing. > > > > -- > > Guillaume > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From yoann at hibernate.org Fri Jul 27 03:19:57 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 27 Jul 2018 09:19:57 +0200 Subject: [hibernate-dev] Stride In-Reply-To: References: <4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com> Message-ID: So, I guess this closes the "Stride" case: we won't use it. I quite like Zulip, but I must admit it doesn't do much to make life easy for new users. This choice of theirs to make topics mandatory (or at least *seemingly* mandatory), in particular, is very likely to confuse new users, be it Hibernate Users joining to look for help, or even people in our team. So even though I like it, I think a lot of people won't, so they won't use it much, which kind of defeats the purpose of a communication tool. Slack would do the trick, I guess, and since most of our rooms are public we don't care that they probably use the data for their own profit (with such a trove of data, I would be surprised if they didn't). There are alternative solutions, though. Of course there are the clones of Slack such Rocket Chat and Mattermost. I just created a RocketChat instance: https://hibernate.rocket.chat/channel/general There is also gitter, which apparently some people in our team have been starting to use: https://gitter.im/hibernate/hibernate-orm . No JIRA integration there, though. I think in the end it will all come down to what people in our team are most comfortable with. Whatever the technology and its future, what we need most is everyone to be happy with it. We can deal with yet another switch in the future, but in the meantime we need everyone to use whatever we picked. And in this regard, it would help if people made their preferences known... Anyone? Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Fri, 27 Jul 2018 at 08:43, Sanne Grinovero wrote: > +1 to test Zulip, thanks for setting it up Yoann. > > Personally having used it quite a bit with other projects: it has > potential but it's not particularly polished yet; in particular the > mobile client has severe issues, and people are quite often failing to > use the "topics" correctly. > > In the news today, Atlassian is killing both HipChat and Stride; > Started a partnership to move to Slack: > - > https://www.atlassian.com/blog/announcements/new-atlassian-slack-partnership > > I've been forced to use Slack as well for yet another group. Sadly not > OSS and infamous for needing tons of memory, but it's working very > well and has some very thouroughly well designed features. > > So this raises more question.. > > - will Zulip catch up? > > - Do we prefer a half baked solution just because it's open? > > - Is the humoungous memory requirement of Slack a real problem? > > Tempted to just get back to IRC :/ > > The Atlassian&Slack partnership however is likely just a small step > towards more interesting integrations across the products. > On Tue, 24 Jul 2018 at 21:56, Yoann Rodiere wrote: > > > > I encountered yet another problem with HipChat [1], so I created a > > Hibernate organization in Zulip. Turns out GitHub and Google > authentication > > are available even in the free plan. > > > > Anyone cares to join me to test it? It's here: > > https://hibernate.zulipchat.com/# > > > > [1] > > > https://bitbucket.org/hipchat/hipchat-github-addon/issues/4/cant-add-organization-repo?_ga=2.132026959.1338067251.1532438591-706928748.1527601569 > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > > > On Tue, 22 May 2018 at 10:50, Guillaume Smet > > wrote: > > > > > On Tue, May 22, 2018 at 10:26 AM, Yoann Rodiere > > > wrote: > > > > > >> ... But I think the one criteria that will make us pick Stride is free > > >> hosting. Most other platforms either do not have a free plan, or do > not > > >> provide all of their features to free plan users. Zulip apparently > removes > > >> OAuth authentication in its free plan, for instance. The Infinispan > team > > >> has OAuth authentication enabled though... Do they pay for their Zulip > > >> instance? > > >> > > > > > > Quote: "Zulip Cloud Premium is free for open source projects and a wide > > > variety of non-commercial entities" > > > > > > What bugged me first was the capped archives of the free offer. > > > > > > HipChat is doing a very similar thing. > > > > > > -- > > > Guillaume > > > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From christian.beikov at gmail.com Fri Jul 27 03:29:11 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Fri, 27 Jul 2018 09:29:11 +0200 Subject: [hibernate-dev] Stride In-Reply-To: References: <4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com> Message-ID: Slack does require more memory than other solutions, running on 200 MB here for 3 Organizations, but it is a really nice tool. So my preference is Slack. Mit freundlichen Gr??en, ------------------------------------------------------------------------ *Christian Beikov* Am 27.07.2018 um 09:19 schrieb Yoann Rodiere: > So, I guess this closes the "Stride" case: we won't use it. > > I quite like Zulip, but I must admit it doesn't do much to make life easy > for new users. This choice of theirs to make topics mandatory (or at least > *seemingly* mandatory), in particular, is very likely to confuse new users, > be it Hibernate Users joining to look for help, or even people in our team. > So even though I like it, I think a lot of people won't, so they won't use > it much, which kind of defeats the purpose of a communication tool. > > Slack would do the trick, I guess, and since most of our rooms are public > we don't care that they probably use the data for their own profit (with > such a trove of data, I would be surprised if they didn't). > > There are alternative solutions, though. Of course there are the clones of > Slack such Rocket Chat and Mattermost. I just created a RocketChat > instance: https://hibernate.rocket.chat/channel/general > > There is also gitter, which apparently some people in our team have been > starting to use: https://gitter.im/hibernate/hibernate-orm . No JIRA > integration there, though. > > I think in the end it will all come down to what people in our team are > most comfortable with. Whatever the technology and its future, what we need > most is everyone to be happy with it. We can deal with yet another switch > in the future, but in the meantime we need everyone to use whatever we > picked. And in this regard, it would help if people made their preferences > known... Anyone? > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > > On Fri, 27 Jul 2018 at 08:43, Sanne Grinovero wrote: > >> +1 to test Zulip, thanks for setting it up Yoann. >> >> Personally having used it quite a bit with other projects: it has >> potential but it's not particularly polished yet; in particular the >> mobile client has severe issues, and people are quite often failing to >> use the "topics" correctly. >> >> In the news today, Atlassian is killing both HipChat and Stride; >> Started a partnership to move to Slack: >> - >> https://www.atlassian.com/blog/announcements/new-atlassian-slack-partnership >> >> I've been forced to use Slack as well for yet another group. Sadly not >> OSS and infamous for needing tons of memory, but it's working very >> well and has some very thouroughly well designed features. >> >> So this raises more question.. >> >> - will Zulip catch up? >> >> - Do we prefer a half baked solution just because it's open? >> >> - Is the humoungous memory requirement of Slack a real problem? >> >> Tempted to just get back to IRC :/ >> >> The Atlassian&Slack partnership however is likely just a small step >> towards more interesting integrations across the products. >> On Tue, 24 Jul 2018 at 21:56, Yoann Rodiere wrote: >>> I encountered yet another problem with HipChat [1], so I created a >>> Hibernate organization in Zulip. Turns out GitHub and Google >> authentication >>> are available even in the free plan. >>> >>> Anyone cares to join me to test it? It's here: >>> https://hibernate.zulipchat.com/# >>> >>> [1] >>> >> https://bitbucket.org/hipchat/hipchat-github-addon/issues/4/cant-add-organization-repo?_ga=2.132026959.1338067251.1532438591-706928748.1527601569 >>> Yoann Rodi?re >>> Hibernate NoORM Team >>> yoann at hibernate.org >>> >>> >>> On Tue, 22 May 2018 at 10:50, Guillaume Smet >>> wrote: >>> >>>> On Tue, May 22, 2018 at 10:26 AM, Yoann Rodiere >>>> wrote: >>>> >>>>> ... But I think the one criteria that will make us pick Stride is free >>>>> hosting. Most other platforms either do not have a free plan, or do >> not >>>>> provide all of their features to free plan users. Zulip apparently >> removes >>>>> OAuth authentication in its free plan, for instance. The Infinispan >> team >>>>> has OAuth authentication enabled though... Do they pay for their Zulip >>>>> instance? >>>>> >>>> Quote: "Zulip Cloud Premium is free for open source projects and a wide >>>> variety of non-commercial entities" >>>> >>>> What bugged me first was the capped archives of the free offer. >>>> >>>> HipChat is doing a very similar thing. >>>> >>>> -- >>>> Guillaume >>>> >>>> >>> _______________________________________________ >>> 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 emmanuel at hibernate.org Fri Jul 27 08:12:02 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 27 Jul 2018 14:12:02 +0200 Subject: [hibernate-dev] Stride In-Reply-To: References: <4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com> Message-ID: <20180727121202.GA4969@hibernate.org> I like Zulip a lot. I've been using it extensively and the notion of topic (like a email subjet) is a big +1 for me and for any more casual lurker. Also it reduces the proliferation of one off/single subject channel that a lurker always miss in tools like Slack. Granted Zulip topics are a bit offsetting for the first 5 posts. And yes their mobile client is really bad. But the desktop client is really nice. Slack is slack, I don't particularly enjoy the UI but people seem to like it. Their optional discussion thread model (within a channel) is a disaster if you ask me. And, yes you need CPU and RAM in excess. On Fri 18-07-27 9:19, Yoann Rodiere wrote: >So, I guess this closes the "Stride" case: we won't use it. > >I quite like Zulip, but I must admit it doesn't do much to make life easy >for new users. This choice of theirs to make topics mandatory (or at least >*seemingly* mandatory), in particular, is very likely to confuse new users, >be it Hibernate Users joining to look for help, or even people in our team. >So even though I like it, I think a lot of people won't, so they won't use >it much, which kind of defeats the purpose of a communication tool. > >Slack would do the trick, I guess, and since most of our rooms are public >we don't care that they probably use the data for their own profit (with >such a trove of data, I would be surprised if they didn't). > >There are alternative solutions, though. Of course there are the clones of >Slack such Rocket Chat and Mattermost. I just created a RocketChat >instance: https://hibernate.rocket.chat/channel/general > >There is also gitter, which apparently some people in our team have been >starting to use: https://gitter.im/hibernate/hibernate-orm . No JIRA >integration there, though. > >I think in the end it will all come down to what people in our team are >most comfortable with. Whatever the technology and its future, what we need >most is everyone to be happy with it. We can deal with yet another switch >in the future, but in the meantime we need everyone to use whatever we >picked. And in this regard, it would help if people made their preferences >known... Anyone? > >Yoann Rodi?re >Hibernate NoORM Team >yoann at hibernate.org > > > >On Fri, 27 Jul 2018 at 08:43, Sanne Grinovero wrote: > >> +1 to test Zulip, thanks for setting it up Yoann. >> >> Personally having used it quite a bit with other projects: it has >> potential but it's not particularly polished yet; in particular the >> mobile client has severe issues, and people are quite often failing to >> use the "topics" correctly. >> >> In the news today, Atlassian is killing both HipChat and Stride; >> Started a partnership to move to Slack: >> - >> https://www.atlassian.com/blog/announcements/new-atlassian-slack-partnership >> >> I've been forced to use Slack as well for yet another group. Sadly not >> OSS and infamous for needing tons of memory, but it's working very >> well and has some very thouroughly well designed features. >> >> So this raises more question.. >> >> - will Zulip catch up? >> >> - Do we prefer a half baked solution just because it's open? >> >> - Is the humoungous memory requirement of Slack a real problem? >> >> Tempted to just get back to IRC :/ >> >> The Atlassian&Slack partnership however is likely just a small step >> towards more interesting integrations across the products. >> On Tue, 24 Jul 2018 at 21:56, Yoann Rodiere wrote: >> > >> > I encountered yet another problem with HipChat [1], so I created a >> > Hibernate organization in Zulip. Turns out GitHub and Google >> authentication >> > are available even in the free plan. >> > >> > Anyone cares to join me to test it? It's here: >> > https://hibernate.zulipchat.com/# >> > >> > [1] >> > >> https://bitbucket.org/hipchat/hipchat-github-addon/issues/4/cant-add-organization-repo?_ga=2.132026959.1338067251.1532438591-706928748.1527601569 >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > yoann at hibernate.org >> > >> > >> > On Tue, 22 May 2018 at 10:50, Guillaume Smet >> > wrote: >> > >> > > On Tue, May 22, 2018 at 10:26 AM, Yoann Rodiere >> > > wrote: >> > > >> > >> ... But I think the one criteria that will make us pick Stride is free >> > >> hosting. Most other platforms either do not have a free plan, or do >> not >> > >> provide all of their features to free plan users. Zulip apparently >> removes >> > >> OAuth authentication in its free plan, for instance. The Infinispan >> team >> > >> has OAuth authentication enabled though... Do they pay for their Zulip >> > >> instance? >> > >> >> > > >> > > Quote: "Zulip Cloud Premium is free for open source projects and a wide >> > > variety of non-commercial entities" >> > > >> > > What bugged me first was the capped archives of the free offer. >> > > >> > > HipChat is doing a very similar thing. >> > > >> > > -- >> > > Guillaume >> > > >> > > >> > _______________________________________________ >> > 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 Jul 27 08:38:59 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 27 Jul 2018 14:38:59 +0200 Subject: [hibernate-dev] Stride In-Reply-To: <20180727121202.GA4969@hibernate.org> References: <4B956717-C386-47E9-BA5B-0D8C169CB5C8@gmail.com> <20180727121202.GA4969@hibernate.org> Message-ID: On Fri, Jul 27, 2018 at 2:31 PM Emmanuel Bernard wrote: > I like Zulip a lot. I've been using it extensively and the notion of > topic (like a email subjet) is a big +1 for me and for any more casual > lurker. Also it reduces the proliferation of one off/single subject > channel that a lurker always miss in tools like Slack. > > Granted Zulip topics are a bit offsetting for the first 5 posts. And yes > their mobile client is really bad. But the desktop client is really > nice. > I'm not really excited about topics. We might need a topic once a month, maybe less, when we start a big discussion on a subject (and even so, there's usually only one discussion in parallel). The rest of the time, we just share in the channel. If they were optional, that would do but they are not and you always need 2 clicks to share (e.g. go to the right stream, then either choose a topic or create new topic), whereas you're at most one click away on HipChat. For our usage I find it a bit suboptimal. I use the HipChat mobile client from time to time, not sure how bad Zulip's is. Can you at least follow the streams and post messages? Anyway, it's more a -0 than a -1 for Zulip. Never used Slack. -- Guillaume From emmanuel at hibernate.org Fri Jul 27 09:47:58 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 27 Jul 2018 15:47:58 +0200 Subject: [hibernate-dev] Stride In-Reply-To: References: <20180727121202.GA4969@hibernate.org> Message-ID: <20180727134758.GD4969@hibernate.org> On Fri 18-07-27 14:38, Guillaume Smet wrote: >On Fri, Jul 27, 2018 at 2:31 PM Emmanuel Bernard >wrote: > >> I like Zulip a lot. I've been using it extensively and the notion of >> topic (like a email subjet) is a big +1 for me and for any more casual >> lurker. Also it reduces the proliferation of one off/single subject >> channel that a lurker always miss in tools like Slack. >> >> Granted Zulip topics are a bit offsetting for the first 5 posts. And yes >> their mobile client is really bad. But the desktop client is really >> nice. >> > >I'm not really excited about topics. We might need a topic once a month, >maybe less, when we start a big discussion on a subject (and even so, >there's usually only one discussion in parallel). If you want to accept the Hibernate community in this and it catches up, then you will have parallel discussions. Join the Infinispan one for an example. Also even if one conversation happens at a given time, it is a very good organiser for someone that is catching up on subject after the actual conversation happened. > >The rest of the time, we just share in the channel. > >If they were optional, that would do but they are not and you always need 2 >clicks to share (e.g. go to the right stream, then either choose a topic or >create new topic), whereas you're at most one click away on HipChat. For >our usage I find it a bit suboptimal. > >I use the HipChat mobile client from time to time, not sure how bad Zulip's >is. Can you at least follow the streams and post messages? > >Anyway, it's more a -0 than a -1 for Zulip. > >Never used Slack. > >-- >Guillaume From guillaume.smet at gmail.com Mon Jul 30 06:26:51 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Jul 2018 12:26:51 +0200 Subject: [hibernate-dev] What does CacheConcurrencyStrategy.NONE mean? Message-ID: Hi, Does setting @Cache(usage = CacheConcurrencyStrategy.NONE) on an entity mean that we entirely disable the 2nd level cache for this entity? The documentation does not reference this value and the Javadoc does not state clearly that the cache is disabled with this concurrency strategy. Asking that because of: - https://hibernate.atlassian.net/browse/HHH-12587 - where Chris disabled writing to the cache in this case to fix a NPE; - https://hibernate.atlassian.net/browse/HHH-12868 - where we have the exact same NPE when reading from the cache. The fix is easy if it's just about disabling the cache in this case but maybe we should update the Javadoc of CacheConcurrencyStrategy if it's about disabling the cache entirely? Thanks for any insight! -- Guillaume From steve at hibernate.org Mon Jul 30 09:59:44 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 30 Jul 2018 08:59:44 -0500 Subject: [hibernate-dev] What does CacheConcurrencyStrategy.NONE mean? In-Reply-To: References: Message-ID: It is equivalent to `javax.persistence.Cacheable(false)`, although it was never well defined what it means in relation to `javax.persistence.SharedCacheMode` On Mon, Jul 30, 2018 at 5:40 AM Guillaume Smet wrote: > Hi, > > Does setting @Cache(usage = CacheConcurrencyStrategy.NONE) on an entity > mean that we entirely disable the 2nd level cache for this entity? > > The documentation does not reference this value and the Javadoc does not > state clearly that the cache is disabled with this concurrency strategy. > > Asking that because of: > - https://hibernate.atlassian.net/browse/HHH-12587 - where Chris disabled > writing to the cache in this case to fix a NPE; > - https://hibernate.atlassian.net/browse/HHH-12868 - where we have the > exact same NPE when reading from the cache. > > The fix is easy if it's just about disabling the cache in this case but > maybe we should update the Javadoc of CacheConcurrencyStrategy if it's > about disabling the cache entirely? > > Thanks for any insight! > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Jul 30 10:10:42 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 30 Jul 2018 09:10:42 -0500 Subject: [hibernate-dev] Stride In-Reply-To: <20180727134758.GD4969@hibernate.org> References: <20180727121202.GA4969@hibernate.org> <20180727134758.GD4969@hibernate.org> Message-ID: In practice, what happens when a discussion spans multiple topics? On Fri, Jul 27, 2018 at 9:43 AM Emmanuel Bernard wrote: > On Fri 18-07-27 14:38, Guillaume Smet wrote: > >On Fri, Jul 27, 2018 at 2:31 PM Emmanuel Bernard > >wrote: > > > >> I like Zulip a lot. I've been using it extensively and the notion of > >> topic (like a email subjet) is a big +1 for me and for any more casual > >> lurker. Also it reduces the proliferation of one off/single subject > >> channel that a lurker always miss in tools like Slack. > >> > >> Granted Zulip topics are a bit offsetting for the first 5 posts. And yes > >> their mobile client is really bad. But the desktop client is really > >> nice. > >> > > > >I'm not really excited about topics. We might need a topic once a month, > >maybe less, when we start a big discussion on a subject (and even so, > >there's usually only one discussion in parallel). > > If you want to accept the Hibernate community in this and it catches up, > then you will have parallel discussions. Join the Infinispan one for an > example. > > Also even if one conversation happens at a given time, it is a very good > organiser for someone that is catching up on subject after the actual > conversation happened. > > > > >The rest of the time, we just share in the channel. > > > >If they were optional, that would do but they are not and you always need > 2 > >clicks to share (e.g. go to the right stream, then either choose a topic > or > >create new topic), whereas you're at most one click away on HipChat. For > >our usage I find it a bit suboptimal. > > > >I use the HipChat mobile client from time to time, not sure how bad > Zulip's > >is. Can you at least follow the streams and post messages? > > > >Anyway, it's more a -0 than a -1 for Zulip. > > > >Never used Slack. > > > >-- > >Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From emmanuel at hibernate.org Mon Jul 30 10:22:40 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 30 Jul 2018 16:22:40 +0200 Subject: [hibernate-dev] https://hibernate.org enforced Message-ID: <20180730142240.GI21428@hibernate.org> I've enforced HTTPS on hibernate.org. I am aware that Google Chrome shows warning as we load some non HTTPS resources as part of the pages (two images, one link and the in.relation.to feed). But if you see other things not working, let us know. Here is the issue tracker https://hibernate.atlassian.net/browse/WEBSITE-523 Emmanuel From emmanuel at hibernate.org Mon Jul 30 10:26:18 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 30 Jul 2018 16:26:18 +0200 Subject: [hibernate-dev] Stride In-Reply-To: References: <20180727121202.GA4969@hibernate.org> <20180727134758.GD4969@hibernate.org> Message-ID: <20180730142618.GK21428@hibernate.org> Same as in an email thread, you change the topic for a subpart of your conversation. You can opt to fork the topic name at a given point in time retroactively (which you don't get for emails). On Mon 18-07-30 9:10, Steve Ebersole wrote: >In practice, what happens when a discussion spans multiple topics? > > >On Fri, Jul 27, 2018 at 9:43 AM Emmanuel Bernard >wrote: > >> On Fri 18-07-27 14:38, Guillaume Smet wrote: >> >On Fri, Jul 27, 2018 at 2:31 PM Emmanuel Bernard >> >wrote: >> > >> >> I like Zulip a lot. I've been using it extensively and the notion of >> >> topic (like a email subjet) is a big +1 for me and for any more casual >> >> lurker. Also it reduces the proliferation of one off/single subject >> >> channel that a lurker always miss in tools like Slack. >> >> >> >> Granted Zulip topics are a bit offsetting for the first 5 posts. And yes >> >> their mobile client is really bad. But the desktop client is really >> >> nice. >> >> >> > >> >I'm not really excited about topics. We might need a topic once a month, >> >maybe less, when we start a big discussion on a subject (and even so, >> >there's usually only one discussion in parallel). >> >> If you want to accept the Hibernate community in this and it catches up, >> then you will have parallel discussions. Join the Infinispan one for an >> example. >> >> Also even if one conversation happens at a given time, it is a very good >> organiser for someone that is catching up on subject after the actual >> conversation happened. >> >> > >> >The rest of the time, we just share in the channel. >> > >> >If they were optional, that would do but they are not and you always need >> 2 >> >clicks to share (e.g. go to the right stream, then either choose a topic >> or >> >create new topic), whereas you're at most one click away on HipChat. For >> >our usage I find it a bit suboptimal. >> > >> >I use the HipChat mobile client from time to time, not sure how bad >> Zulip's >> >is. Can you at least follow the streams and post messages? >> > >> >Anyway, it's more a -0 than a -1 for Zulip. >> > >> >Never used Slack. >> > >> >-- >> >Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> From steve at hibernate.org Mon Jul 30 10:38:34 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 30 Jul 2018 09:38:34 -0500 Subject: [hibernate-dev] Stride In-Reply-To: <20180730142618.GK21428@hibernate.org> References: <20180727121202.GA4969@hibernate.org> <20180727134758.GD4969@hibernate.org> <20180730142618.GK21428@hibernate.org> Message-ID: I am not asking about a "supart". Think about topics that we cross post to hibernate-dev and willdfly-dev or hibernate-dev and infinispan-dev... so the discussion *simultaneously* spans multiple topics/audiences. On Mon, Jul 30, 2018 at 9:27 AM Emmanuel Bernard wrote: > Same as in an email thread, you change the topic for a subpart of your > conversation. You can opt to fork the topic name at a > given point in time retroactively (which you don't get for emails). > > On Mon 18-07-30 9:10, Steve Ebersole wrote: > >In practice, what happens when a discussion spans multiple topics? > > > > > >On Fri, Jul 27, 2018 at 9:43 AM Emmanuel Bernard > >wrote: > > > >> On Fri 18-07-27 14:38, Guillaume Smet wrote: > >> >On Fri, Jul 27, 2018 at 2:31 PM Emmanuel Bernard < > emmanuel at hibernate.org> > >> >wrote: > >> > > >> >> I like Zulip a lot. I've been using it extensively and the notion of > >> >> topic (like a email subjet) is a big +1 for me and for any more > casual > >> >> lurker. Also it reduces the proliferation of one off/single subject > >> >> channel that a lurker always miss in tools like Slack. > >> >> > >> >> Granted Zulip topics are a bit offsetting for the first 5 posts. And > yes > >> >> their mobile client is really bad. But the desktop client is really > >> >> nice. > >> >> > >> > > >> >I'm not really excited about topics. We might need a topic once a > month, > >> >maybe less, when we start a big discussion on a subject (and even so, > >> >there's usually only one discussion in parallel). > >> > >> If you want to accept the Hibernate community in this and it catches up, > >> then you will have parallel discussions. Join the Infinispan one for an > >> example. > >> > >> Also even if one conversation happens at a given time, it is a very good > >> organiser for someone that is catching up on subject after the actual > >> conversation happened. > >> > >> > > >> >The rest of the time, we just share in the channel. > >> > > >> >If they were optional, that would do but they are not and you always > need > >> 2 > >> >clicks to share (e.g. go to the right stream, then either choose a > topic > >> or > >> >create new topic), whereas you're at most one click away on HipChat. > For > >> >our usage I find it a bit suboptimal. > >> > > >> >I use the HipChat mobile client from time to time, not sure how bad > >> Zulip's > >> >is. Can you at least follow the streams and post messages? > >> > > >> >Anyway, it's more a -0 than a -1 for Zulip. > >> > > >> >Never used Slack. > >> > > >> >-- > >> >Guillaume > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > From guillaume.smet at gmail.com Mon Jul 30 11:14:47 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Jul 2018 17:14:47 +0200 Subject: [hibernate-dev] https://hibernate.org enforced In-Reply-To: <20180730142240.GI21428@hibernate.org> References: <20180730142240.GI21428@hibernate.org> Message-ID: Please don't do it: there's a good reason I haven't done it: the news are not loaded because in.relation.to is not HTTPS. We need to enable HTTPS for in.relation.to before doing it. Thanks. On Mon, Jul 30, 2018 at 4:43 PM Emmanuel Bernard wrote: > I've enforced HTTPS on hibernate.org. > I am aware that Google Chrome shows warning as we load some non HTTPS > resources as part of the pages (two images, one link and the > in.relation.to feed). > But if you see other things not working, let us know. > > Here is the issue tracker > https://hibernate.atlassian.net/browse/WEBSITE-523 > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Jul 30 12:13:08 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 30 Jul 2018 17:13:08 +0100 Subject: [hibernate-dev] https://hibernate.org enforced In-Reply-To: References: <20180730142240.GI21428@hibernate.org> Message-ID: Please be mindful of SEO as well. All existing valid URLs should redirect to a valid HTTPS alternative before we switch. On Mon, 30 Jul 2018 at 16:41, Guillaume Smet wrote: > > Please don't do it: there's a good reason I haven't done it: the news are > not loaded because in.relation.to is not HTTPS. > > We need to enable HTTPS for in.relation.to before doing it. > > Thanks. > > > On Mon, Jul 30, 2018 at 4:43 PM Emmanuel Bernard > wrote: > > > I've enforced HTTPS on hibernate.org. > > I am aware that Google Chrome shows warning as we load some non HTTPS > > resources as part of the pages (two images, one link and the > > in.relation.to feed). > > But if you see other things not working, let us know. > > > > Here is the issue tracker > > https://hibernate.atlassian.net/browse/WEBSITE-523 > > > > Emmanuel > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Mon Jul 30 12:16:58 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 30 Jul 2018 17:16:58 +0100 Subject: [hibernate-dev] Stride In-Reply-To: References: <20180727121202.GA4969@hibernate.org> <20180727134758.GD4969@hibernate.org> <20180730142618.GK21428@hibernate.org> Message-ID: On Mon, 30 Jul 2018 at 16:39, Steve Ebersole wrote: > > I am not asking about a "supart". Think about topics that we cross post to > hibernate-dev and willdfly-dev or hibernate-dev and infinispan-dev... so > the discussion *simultaneously* spans multiple topics/audiences. In zulip what you write goes to one and only one topic. It's similar to the "room" concept of HipChat, except you can also opt to decide to see all streams as once (when reading), if you whish to deactive the "per-topic filter". You don't write in this mode but it's useful to keep an eye on general activity. Please try it out? > > On Mon, Jul 30, 2018 at 9:27 AM Emmanuel Bernard > wrote: > > > Same as in an email thread, you change the topic for a subpart of your > > conversation. You can opt to fork the topic name at a > > given point in time retroactively (which you don't get for emails). > > > > On Mon 18-07-30 9:10, Steve Ebersole wrote: > > >In practice, what happens when a discussion spans multiple topics? > > > > > > > > >On Fri, Jul 27, 2018 at 9:43 AM Emmanuel Bernard > > >wrote: > > > > > >> On Fri 18-07-27 14:38, Guillaume Smet wrote: > > >> >On Fri, Jul 27, 2018 at 2:31 PM Emmanuel Bernard < > > emmanuel at hibernate.org> > > >> >wrote: > > >> > > > >> >> I like Zulip a lot. I've been using it extensively and the notion of > > >> >> topic (like a email subjet) is a big +1 for me and for any more > > casual > > >> >> lurker. Also it reduces the proliferation of one off/single subject > > >> >> channel that a lurker always miss in tools like Slack. > > >> >> > > >> >> Granted Zulip topics are a bit offsetting for the first 5 posts. And > > yes > > >> >> their mobile client is really bad. But the desktop client is really > > >> >> nice. > > >> >> > > >> > > > >> >I'm not really excited about topics. We might need a topic once a > > month, > > >> >maybe less, when we start a big discussion on a subject (and even so, > > >> >there's usually only one discussion in parallel). > > >> > > >> If you want to accept the Hibernate community in this and it catches up, > > >> then you will have parallel discussions. Join the Infinispan one for an > > >> example. > > >> > > >> Also even if one conversation happens at a given time, it is a very good > > >> organiser for someone that is catching up on subject after the actual > > >> conversation happened. > > >> > > >> > > > >> >The rest of the time, we just share in the channel. > > >> > > > >> >If they were optional, that would do but they are not and you always > > need > > >> 2 > > >> >clicks to share (e.g. go to the right stream, then either choose a > > topic > > >> or > > >> >create new topic), whereas you're at most one click away on HipChat. > > For > > >> >our usage I find it a bit suboptimal. > > >> > > > >> >I use the HipChat mobile client from time to time, not sure how bad > > >> Zulip's > > >> >is. Can you at least follow the streams and post messages? > > >> > > > >> >Anyway, it's more a -0 than a -1 for Zulip. > > >> > > > >> >Never used Slack. > > >> > > > >> >-- > > >> >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 yoann at hibernate.org Mon Jul 30 12:20:43 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 30 Jul 2018 18:20:43 +0200 Subject: [hibernate-dev] Stride In-Reply-To: References: <20180727121202.GA4969@hibernate.org> <20180727134758.GD4969@hibernate.org> <20180730142618.GK21428@hibernate.org> Message-ID: If we must compare Zulip to emails, cross-posting to multiple mailing lists would be equivalent to posting to different "streams", which are the equivalent of "rooms" in HipChat or "channels" in IRC. Short answer is: you can't do that, you have to duplicate the conversation. But so would you in HipChat, or IRC, or Slack, or any chat software I've ever heard of. If you are talking about have a single conversation inside a single "stream"/"room"/"channel" with multiple topics (like "JPA 2.2, CDI integration, and also cache SPIs"), well... create a topic just for that ("JPA+CDI+Caches"). Or use the default topic (called "(no topic)"). I don't think the primary reason for topics is archiving and finding older conversation. They help doing that, but their main purpose is to enable multiple concurrent conversation to run their course *in parallel, in a single "stream"/"room"/"channel"*. You can just focus on one topic and temporarily ignore all other topics. Which is nice, but not necessarily important in our case, since it's quite rare that we have multiple conversations going on simultaneously in a given room. Though one could argue that it's rare precisely because we don't have topics and understanding each other would be very difficult. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Mon, 30 Jul 2018 at 17:45, Steve Ebersole wrote: > I am not asking about a "supart". Think about topics that we cross post to > hibernate-dev and willdfly-dev or hibernate-dev and infinispan-dev... so > the discussion *simultaneously* spans multiple topics/audiences. > > On Mon, Jul 30, 2018 at 9:27 AM Emmanuel Bernard > wrote: > > > Same as in an email thread, you change the topic for a subpart of your > > conversation. You can opt to fork the topic name at a > > given point in time retroactively (which you don't get for emails). > > > > On Mon 18-07-30 9:10, Steve Ebersole wrote: > > >In practice, what happens when a discussion spans multiple topics? > > > > > > > > >On Fri, Jul 27, 2018 at 9:43 AM Emmanuel Bernard < > emmanuel at hibernate.org> > > >wrote: > > > > > >> On Fri 18-07-27 14:38, Guillaume Smet wrote: > > >> >On Fri, Jul 27, 2018 at 2:31 PM Emmanuel Bernard < > > emmanuel at hibernate.org> > > >> >wrote: > > >> > > > >> >> I like Zulip a lot. I've been using it extensively and the notion > of > > >> >> topic (like a email subjet) is a big +1 for me and for any more > > casual > > >> >> lurker. Also it reduces the proliferation of one off/single subject > > >> >> channel that a lurker always miss in tools like Slack. > > >> >> > > >> >> Granted Zulip topics are a bit offsetting for the first 5 posts. > And > > yes > > >> >> their mobile client is really bad. But the desktop client is really > > >> >> nice. > > >> >> > > >> > > > >> >I'm not really excited about topics. We might need a topic once a > > month, > > >> >maybe less, when we start a big discussion on a subject (and even so, > > >> >there's usually only one discussion in parallel). > > >> > > >> If you want to accept the Hibernate community in this and it catches > up, > > >> then you will have parallel discussions. Join the Infinispan one for > an > > >> example. > > >> > > >> Also even if one conversation happens at a given time, it is a very > good > > >> organiser for someone that is catching up on subject after the actual > > >> conversation happened. > > >> > > >> > > > >> >The rest of the time, we just share in the channel. > > >> > > > >> >If they were optional, that would do but they are not and you always > > need > > >> 2 > > >> >clicks to share (e.g. go to the right stream, then either choose a > > topic > > >> or > > >> >create new topic), whereas you're at most one click away on HipChat. > > For > > >> >our usage I find it a bit suboptimal. > > >> > > > >> >I use the HipChat mobile client from time to time, not sure how bad > > >> Zulip's > > >> >is. Can you at least follow the streams and post messages? > > >> > > > >> >Anyway, it's more a -0 than a -1 for Zulip. > > >> > > > >> >Never used Slack. > > >> > > > >> >-- > > >> >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 yoann at hibernate.org Mon Jul 30 12:32:50 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 30 Jul 2018 18:32:50 +0200 Subject: [hibernate-dev] https://hibernate.org enforced In-Reply-To: References: <20180730142240.GI21428@hibernate.org> Message-ID: Also several users just reported that some wrong URL ( http://hibernate.org/hibernate-configuration-3.0.dtd) used to work, and now doesn't. It started very recently. Did you change some HTTP redirection rules? Or maybe we had a redirection from http://hibernate.org/hibernate-configuration-3.0.dtd to the correct URL, but your redirection to https takes precedence over the older redirection, and the older one does not match " https://hibernate.org/hibernate-configuration-3.0.dtd"? Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Mon, 30 Jul 2018 at 18:29, Sanne Grinovero wrote: > Please be mindful of SEO as well. All existing valid URLs should > redirect to a valid HTTPS alternative before we switch. > On Mon, 30 Jul 2018 at 16:41, Guillaume Smet > wrote: > > > > Please don't do it: there's a good reason I haven't done it: the news are > > not loaded because in.relation.to is not HTTPS. > > > > We need to enable HTTPS for in.relation.to before doing it. > > > > Thanks. > > > > > > On Mon, Jul 30, 2018 at 4:43 PM Emmanuel Bernard > > > wrote: > > > > > I've enforced HTTPS on hibernate.org. > > > I am aware that Google Chrome shows warning as we load some non HTTPS > > > resources as part of the pages (two images, one link and the > > > in.relation.to feed). > > > But if you see other things not working, let us know. > > > > > > Here is the issue tracker > > > https://hibernate.atlassian.net/browse/WEBSITE-523 > > > > > > Emmanuel > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Mon Jul 30 12:35:11 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Jul 2018 18:35:11 +0200 Subject: [hibernate-dev] https://hibernate.org enforced In-Reply-To: References: <20180730142240.GI21428@hibernate.org> Message-ID: FWIW, I reverted it. On Mon, Jul 30, 2018 at 6:33 PM Yoann Rodiere wrote: > Also several users just reported that some wrong URL ( > http://hibernate.org/hibernate-configuration-3.0.dtd) used to work, and > now doesn't. It started very recently. > > Did you change some HTTP redirection rules? Or maybe we had a redirection > from http://hibernate.org/hibernate-configuration-3.0.dtd to the correct > URL, but your redirection to https takes precedence over the older > redirection, and the older one does not match " > https://hibernate.org/hibernate-configuration-3.0.dtd"? > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > > On Mon, 30 Jul 2018 at 18:29, Sanne Grinovero wrote: > >> Please be mindful of SEO as well. All existing valid URLs should >> redirect to a valid HTTPS alternative before we switch. >> On Mon, 30 Jul 2018 at 16:41, Guillaume Smet >> wrote: >> > >> > Please don't do it: there's a good reason I haven't done it: the news >> are >> > not loaded because in.relation.to is not HTTPS. >> > >> > We need to enable HTTPS for in.relation.to before doing it. >> > >> > Thanks. >> > >> > >> > On Mon, Jul 30, 2018 at 4:43 PM Emmanuel Bernard < >> emmanuel at hibernate.org> >> > wrote: >> > >> > > I've enforced HTTPS on hibernate.org. >> > > I am aware that Google Chrome shows warning as we load some non HTTPS >> > > resources as part of the pages (two images, one link and the >> > > in.relation.to feed). >> > > But if you see other things not working, let us know. >> > > >> > > Here is the issue tracker >> > > https://hibernate.atlassian.net/browse/WEBSITE-523 >> > > >> > > Emmanuel >> > > _______________________________________________ >> > > hibernate-dev mailing list >> > > hibernate-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From sanne at hibernate.org Mon Jul 30 12:56:52 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 30 Jul 2018 17:56:52 +0100 Subject: [hibernate-dev] ComplexStuff.INSTANCE : not always an efficient pattern Message-ID: Hi all, I'm seeing plenty of code has been refactored in recent years to use a " public static final X INSTANCE" field rather than a normal constructor. Often this is a good thing since memory allocation rate is *typically* our limiting factor to improve performance, yet let's be mindful that this pattern has some drawbacks as well. An example is bootstrap code: if ComplexStuff.INSTANCE is used only a very limited amount of times, and during bootstrap, having it in a static final field will ensure that the memory of this instance is not going to be freed up after it is no longer needed. A similar pattern is to declare a Logger in a class as a "static final" yet only ever use it in a catch block which is only going to be executed to log a critical bootstrap error. The Logger instance is taking quite some memory as well, so it would be best to just create the Logger on the fly within the catch block, essentially betting that this is either never going to be used (or when it's used we want to crash fast anyway). On top of memory usage, there's also the actual time it takes to initialize such things; if it's rarely used, let's not use the static final field as it enforces it to be initialized even when unnecessary (unless being very careful). Of course in most cases this makes no significant difference, so should not worry anyone, but in some cases thinking about the tradeoffs of such patterns can make a very good impact on overall memory needs; e.g. I just removed a single singleton and this saves me ~20% of the overall memory during a bootstrap efficiency test. hope you find it interesting! Thanks, Sanne From emmanuel at hibernate.org Mon Jul 30 13:03:05 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 30 Jul 2018 19:03:05 +0200 Subject: [hibernate-dev] https://hibernate.org enforced In-Reply-To: References: <20180730142240.GI21428@hibernate.org> Message-ID: <20180730170305.GA33716@hibernate.org> Well I guess I got my feedback :) Sorry I did not know it was on purpose, I don't remember reading it on the mailing list. So with enforced HTTPS off, we need to go a chase all the links in the form of https://hibernate.org/foo and make them https://hibernate.org/foo/ due to a limitation in GitHub See https://hibernate.atlassian.net/browse/WEBSITE-524 Otherwise, you get a downgrade to http. Emmanuel On Mon 18-07-30 18:35, Guillaume Smet wrote: >FWIW, I reverted it. > >On Mon, Jul 30, 2018 at 6:33 PM Yoann Rodiere wrote: > >> Also several users just reported that some wrong URL ( >> http://hibernate.org/hibernate-configuration-3.0.dtd) used to work, and >> now doesn't. It started very recently. >> >> Did you change some HTTP redirection rules? Or maybe we had a redirection >> from http://hibernate.org/hibernate-configuration-3.0.dtd to the correct >> URL, but your redirection to https takes precedence over the older >> redirection, and the older one does not match " >> https://hibernate.org/hibernate-configuration-3.0.dtd"? >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> >> >> On Mon, 30 Jul 2018 at 18:29, Sanne Grinovero wrote: >> >>> Please be mindful of SEO as well. All existing valid URLs should >>> redirect to a valid HTTPS alternative before we switch. >>> On Mon, 30 Jul 2018 at 16:41, Guillaume Smet >>> wrote: >>> > >>> > Please don't do it: there's a good reason I haven't done it: the news >>> are >>> > not loaded because in.relation.to is not HTTPS. >>> > >>> > We need to enable HTTPS for in.relation.to before doing it. >>> > >>> > Thanks. >>> > >>> > >>> > On Mon, Jul 30, 2018 at 4:43 PM Emmanuel Bernard < >>> emmanuel at hibernate.org> >>> > wrote: >>> > >>> > > I've enforced HTTPS on hibernate.org. >>> > > I am aware that Google Chrome shows warning as we load some non HTTPS >>> > > resources as part of the pages (two images, one link and the >>> > > in.relation.to feed). >>> > > But if you see other things not working, let us know. >>> > > >>> > > Here is the issue tracker >>> > > https://hibernate.atlassian.net/browse/WEBSITE-523 >>> > > >>> > > Emmanuel >>> > > _______________________________________________ >>> > > hibernate-dev mailing list >>> > > hibernate-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > > >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> From rvansa at redhat.com Tue Jul 31 04:16:20 2018 From: rvansa at redhat.com (Radim Vansa) Date: Tue, 31 Jul 2018 10:16:20 +0200 Subject: [hibernate-dev] Stride In-Reply-To: References: <20180727121202.GA4969@hibernate.org> <20180727134758.GD4969@hibernate.org> <20180730142618.GK21428@hibernate.org> Message-ID: <44449160-ad3f-14eb-979d-1bfaeebc35d7@redhat.com> On 07/30/2018 06:20 PM, Yoann Rodiere wrote: > If we must compare Zulip to emails, cross-posting to multiple mailing lists > would be equivalent to posting to different "streams", which are the > equivalent of "rooms" in HipChat or "channels" in IRC. > Short answer is: you can't do that, you have to duplicate the conversation. > But so would you in HipChat, or IRC, or Slack, or any chat software I've > ever heard of. > > If you are talking about have a single conversation inside a single > "stream"/"room"/"channel" with multiple topics (like "JPA 2.2, CDI > integration, and also cache SPIs"), well... create a topic just for that > ("JPA+CDI+Caches"). Or use the default topic (called "(no topic)"). > > I don't think the primary reason for topics is archiving and finding older > conversation. They help doing that, but their main purpose is to enable > multiple concurrent conversation to run their course *in parallel, in a > single "stream"/"room"/"channel"*. You can just focus on one topic and > temporarily ignore all other topics. Which is nice, but not necessarily > important in our case, since it's quite rare that we have multiple > conversations going on simultaneously in a given room. Though one could > argue that it's rare precisely because we don't have topics and > understanding each other would be very difficult. There are often some parallel discussions on mailing list(s). The thing is that since Infinispan moved to Zulip the -dev list has become more of an announce-list, 95% of discussion moved to Zulip - just because it's faster to discuss it that way. Also if the discussion is not on a mailing list but couple of selected people, it's easier if that's just a topic on private stream and you can notify more people about that, keeping the history. (You can't add people to a strictly private conversation and let them see the history, though). Radim > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > > On Mon, 30 Jul 2018 at 17:45, Steve Ebersole wrote: > >> I am not asking about a "supart". Think about topics that we cross post to >> hibernate-dev and willdfly-dev or hibernate-dev and infinispan-dev... so >> the discussion *simultaneously* spans multiple topics/audiences. >> >> On Mon, Jul 30, 2018 at 9:27 AM Emmanuel Bernard >> wrote: >> >>> Same as in an email thread, you change the topic for a subpart of your >>> conversation. You can opt to fork the topic name at a >>> given point in time retroactively (which you don't get for emails). >>> >>> On Mon 18-07-30 9:10, Steve Ebersole wrote: >>>> In practice, what happens when a discussion spans multiple topics? >>>> >>>> >>>> On Fri, Jul 27, 2018 at 9:43 AM Emmanuel Bernard < >> emmanuel at hibernate.org> >>>> wrote: >>>> >>>>> On Fri 18-07-27 14:38, Guillaume Smet wrote: >>>>>> On Fri, Jul 27, 2018 at 2:31 PM Emmanuel Bernard < >>> emmanuel at hibernate.org> >>>>>> wrote: >>>>>> >>>>>>> I like Zulip a lot. I've been using it extensively and the notion >> of >>>>>>> topic (like a email subjet) is a big +1 for me and for any more >>> casual >>>>>>> lurker. Also it reduces the proliferation of one off/single subject >>>>>>> channel that a lurker always miss in tools like Slack. >>>>>>> >>>>>>> Granted Zulip topics are a bit offsetting for the first 5 posts. >> And >>> yes >>>>>>> their mobile client is really bad. But the desktop client is really >>>>>>> nice. >>>>>>> >>>>>> I'm not really excited about topics. We might need a topic once a >>> month, >>>>>> maybe less, when we start a big discussion on a subject (and even so, >>>>>> there's usually only one discussion in parallel). >>>>> If you want to accept the Hibernate community in this and it catches >> up, >>>>> then you will have parallel discussions. Join the Infinispan one for >> an >>>>> example. >>>>> >>>>> Also even if one conversation happens at a given time, it is a very >> good >>>>> organiser for someone that is catching up on subject after the actual >>>>> conversation happened. >>>>> >>>>>> The rest of the time, we just share in the channel. >>>>>> >>>>>> If they were optional, that would do but they are not and you always >>> need >>>>> 2 >>>>>> clicks to share (e.g. go to the right stream, then either choose a >>> topic >>>>> or >>>>>> create new topic), whereas you're at most one click away on HipChat. >>> For >>>>>> our usage I find it a bit suboptimal. >>>>>> >>>>>> I use the HipChat mobile client from time to time, not sure how bad >>>>> Zulip's >>>>>> is. Can you at least follow the streams and post messages? >>>>>> >>>>>> Anyway, it's more a -0 than a -1 for Zulip. >>>>>> >>>>>> Never used Slack. >>>>>> >>>>>> -- >>>>>> 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 -- Radim Vansa JBoss Performance Team From guillaume.smet at gmail.com Tue Jul 31 08:48:56 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 31 Jul 2018 14:48:56 +0200 Subject: [hibernate-dev] What does CacheConcurrencyStrategy.NONE mean? In-Reply-To: References: Message-ID: On Mon, Jul 30, 2018 at 3:59 PM Steve Ebersole wrote: > It is equivalent to `javax.persistence.Cacheable(false)`, although it was > never well defined what it means in relation to > `javax.persistence.SharedCacheMode` > OK, thanks, will just fix the NPE then. From guillaume.smet at gmail.com Tue Jul 31 09:38:48 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 31 Jul 2018 15:38:48 +0200 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of this week's NoORM IRC meeting: 15:36 < jbott> Meeting ended Tue Jul 31 13:36:04 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:36 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-07-31-13.00.html 15:36 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-07-31-13.00.txt 15:36 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-07-31-13.00.log.html Have a nice day! -- Guillaume From guillaume.smet at gmail.com Tue Jul 31 11:23:52 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 31 Jul 2018 17:23:52 +0200 Subject: [hibernate-dev] orm.xml scanning issue Message-ID: 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 From emmanuel at hibernate.org Tue Jul 31 11:45:47 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 31 Jul 2018 17:45:47 +0200 Subject: [hibernate-dev] orm.xml scanning issue In-Reply-To: References: Message-ID: <20180731154547.GE45197@hibernate.org> 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 guillaume.smet at gmail.com Tue Jul 31 11:51:54 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 31 Jul 2018 17:51:54 +0200 Subject: [hibernate-dev] orm.xml scanning issue In-Reply-To: <20180731154547.GE45197@hibernate.org> References: <20180731154547.GE45197@hibernate.org> Message-ID: >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 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 >