From rafael.wth at gmail.com Sat Oct 1 11:22:44 2016 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Sat, 1 Oct 2016 17:22:44 +0200 Subject: [hibernate-dev] Adding a Byte Buddy byte code provider to Hibernate Message-ID: Hello everybody, I was wondering how big the chances are to get a Byte Buddy bytecode provider into Hibernate? Byte Buddy has matured a lot over the last two years and it aims a lot on performance what is something Hibernate could benefit of. There are comparion charts posted on the Byte Buddy webpage. As a bonus, Byte Buddy is already ready for Java 9 and gives a lot of features for free, for example generic meta data retention and a possibility to retain annotations on subclassed types and overridden methods. I have written a simple proof of concept here: https://github.com/raphw/hibernate-bb without having tested it - I did not implement the fast class providers as I have learned after a lot of benchmarking that those do not improve performance on Java 8+ VMs anymore. Using such fast-classing rather pollutes the code cache than bring any benefit. The only advantage with code generation in this field comes when avoiding boxing what is not the case. But of course, I can implement something in Byte Buddy to apply such a fast-class mechanism. Let me know what you think. I am more then happy to help you with implementing such a provider. Other frameworks such as Mockito already use Byte Buddy on a large scale and made good experiences with it. Best regards, Rafael From mihalcea.vlad at gmail.com Sat Oct 1 11:39:32 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Sat, 1 Oct 2016 18:39:32 +0300 Subject: [hibernate-dev] Adding a Byte Buddy byte code provider to Hibernate In-Reply-To: References: Message-ID: Hi Steve, Since we have issues with Javassist and Java 1.9, maybe it's the right time to consider switching to ByteBuddy. Vlad On Sat, Oct 1, 2016 at 6:22 PM, Rafael Winterhalter wrote: > Hello everybody, > > I was wondering how big the chances are to get a Byte Buddy bytecode > provider into Hibernate? Byte Buddy has matured a lot over the last two > years and it aims a lot on performance what is something Hibernate could > benefit of. There are comparion charts posted on the Byte Buddy webpage. As > a bonus, Byte Buddy is already ready for Java 9 and gives a lot of features > for free, for example generic meta data retention and a possibility to > retain annotations on subclassed types and overridden methods. > > I have written a simple proof of concept here: > https://github.com/raphw/hibernate-bb without having tested it - I did not > implement the fast class providers as I have learned after a lot of > benchmarking that those do not improve performance on Java 8+ VMs anymore. > Using such fast-classing rather pollutes the code cache than bring any > benefit. The only advantage with code generation in this field comes when > avoiding boxing what is not the case. But of course, I can implement > something in Byte Buddy to apply such a fast-class mechanism. > > Let me know what you think. I am more then happy to help you with > implementing such a provider. Other frameworks such as Mockito already use > Byte Buddy on a large scale and made good experiences with it. > > Best regards, Rafael > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Sat Oct 1 12:29:41 2016 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 01 Oct 2016 16:29:41 +0000 Subject: [hibernate-dev] Adding a Byte Buddy byte code provider to Hibernate In-Reply-To: References: Message-ID: As I have said quite often I would love to have a ByteBuddy BytecodeProvider or possibly switch from Javassist to ByteBuddy. The issue is resources. I don't have the time right now. For what it is worth, Chiba does have the changes in place to support Java 9 in Javassist. That is actually not the reason I want to look at ByteBuddy. On Sat, Oct 1, 2016, 10:42 AM Vlad Mihalcea wrote: > Hi Steve, > > Since we have issues with Javassist and Java 1.9, maybe it's the right time > to consider switching to ByteBuddy. > > Vlad > > On Sat, Oct 1, 2016 at 6:22 PM, Rafael Winterhalter > wrote: > > > Hello everybody, > > > > I was wondering how big the chances are to get a Byte Buddy bytecode > > provider into Hibernate? Byte Buddy has matured a lot over the last two > > years and it aims a lot on performance what is something Hibernate could > > benefit of. There are comparion charts posted on the Byte Buddy webpage. > As > > a bonus, Byte Buddy is already ready for Java 9 and gives a lot of > features > > for free, for example generic meta data retention and a possibility to > > retain annotations on subclassed types and overridden methods. > > > > I have written a simple proof of concept here: > > https://github.com/raphw/hibernate-bb without having tested it - I did > not > > implement the fast class providers as I have learned after a lot of > > benchmarking that those do not improve performance on Java 8+ VMs > anymore. > > Using such fast-classing rather pollutes the code cache than bring any > > benefit. The only advantage with code generation in this field comes when > > avoiding boxing what is not the case. But of course, I can implement > > something in Byte Buddy to apply such a fast-class mechanism. > > > > Let me know what you think. I am more then happy to help you with > > implementing such a provider. Other frameworks such as Mockito already > use > > Byte Buddy on a large scale and made good experiences with it. > > > > Best regards, Rafael > > _______________________________________________ > > 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 Oct 3 03:46:02 2016 From: andrea at hibernate.org (andrea boriero) Date: Mon, 3 Oct 2016 09:46:02 +0200 Subject: [hibernate-dev] Hibernate ORM 5.2.3.Final has been released Message-ID: For details: http://in.relation.to/2016/10/03/hibernate-orm-523-final-release/ From sanne at hibernate.org Mon Oct 3 17:15:28 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 3 Oct 2016 22:15:28 +0100 Subject: [hibernate-dev] Multi-tenancy test helpers Message-ID: Hi all, in Hibernate Search we have a test helper to setup Hibernate ORM with multi-tenancy and export the schema's we need for testing. It looks like: - https://raw.githubusercontent.com/hibernate/hibernate-search/d29f560c89e60dd288fa142aa1a6b6a357354ef1/orm/src/test/java/org/hibernate/search/test/util/MultitenancyTestHelper.java The problem is I used Hibernate ORM's internals, and this little helper keeps breaking. Could we have such an utility provided by ORM? Also wondering if "test helpers" such as this one could be useful to end users; it would be nice to publish such helpers and maintain their API as stable as any other API. For example now to have Hibernate Search switch from ORM 5.2.1 to 5.2.2 it requires code changes - luckily just on tests! - but it still bothers me as it means we can't automatically test a version X of Search towards a full-range of micro releases of ORM 5.2.x. Thanks, Sanne From steve at hibernate.org Mon Oct 3 23:31:08 2016 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 04 Oct 2016 03:31:08 +0000 Subject: [hibernate-dev] Multi-tenancy test helpers In-Reply-To: References: Message-ID: I think that's a great idea On Mon, Oct 3, 2016, 4:18 PM Sanne Grinovero wrote: > Hi all, > in Hibernate Search we have a test helper to setup Hibernate ORM with > multi-tenancy and export the schema's we need for testing. > > It looks like: > - > https://raw.githubusercontent.com/hibernate/hibernate-search/d29f560c89e60dd288fa142aa1a6b6a357354ef1/orm/src/test/java/org/hibernate/search/test/util/MultitenancyTestHelper.java > > The problem is I used Hibernate ORM's internals, and this little > helper keeps breaking. > > Could we have such an utility provided by ORM? > > Also wondering if "test helpers" such as this one could be useful to > end users; it would be nice to publish such helpers and maintain their > API as stable as any other API. > > For example now to have Hibernate Search switch from ORM 5.2.1 to > 5.2.2 it requires code changes - luckily just on tests! - but it still > bothers me as it means we can't automatically test a version X of > Search towards a full-range of micro releases of ORM 5.2.x. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Tue Oct 4 14:19:46 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 4 Oct 2016 20:19:46 +0200 Subject: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project} Message-ID: Hi, I just stumbled across HHH-11153 ("Rename published groupId from org.hibernate to org.hibernate.orm"), scheduled for ORM 6.0.0.Alpha1. I think that's a great idea and would suggest we do the same for Hibernate Validator and Search in their respective 6.0 releases: org.hibernate.validator and org.hibernate.search (for OGM we used org.hibernate.ogm from the beginning). Any concerns? --Gunnar From sanne at hibernate.org Tue Oct 4 17:17:55 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 4 Oct 2016 22:17:55 +0100 Subject: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project} In-Reply-To: References: Message-ID: No concerns. When talking about this with Steve I also added it to our next meeting agenda, however it looks like we're all onboard so maybe there isn't much to debate :) On 4 October 2016 at 19:19, Gunnar Morling wrote: > Hi, > > I just stumbled across HHH-11153 ("Rename published groupId from > org.hibernate to org.hibernate.orm"), scheduled for ORM 6.0.0.Alpha1. > > I think that's a great idea and would suggest we do the same for Hibernate > Validator and Search in their respective 6.0 releases: > org.hibernate.validator and org.hibernate.search (for OGM we used > org.hibernate.ogm from the beginning). > > Any concerns? > > --Gunnar > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From manderse at redhat.com Wed Oct 5 02:30:15 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Wed, 05 Oct 2016 08:30:15 +0200 Subject: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project} In-Reply-To: References: Message-ID: <3BE9D1EF-3F34-4FA3-89D3-5DEC40C4F91C@redhat.com> Won't this break like every existing example and 3rd party integrations (think Spring projects) maven and gradle builds on the planet ? Or are hibernate 6 so radically different there is no chance you would just change the version number to have builds work with both hibernate 5 and 6 ? Not saying it should not be done - just wondering if we grok the full impact for users. /max > No concerns. > When talking about this with Steve I also added it to our next meeting > agenda, however it looks like we're all onboard so maybe there isn't > much to debate :) > > On 4 October 2016 at 19:19, Gunnar Morling > wrote: >> Hi, >> >> I just stumbled across HHH-11153 ("Rename published groupId from >> org.hibernate to org.hibernate.orm"), scheduled for ORM 6.0.0.Alpha1. >> >> I think that's a great idea and would suggest we do the same for >> Hibernate >> Validator and Search in their respective 6.0 releases: >> org.hibernate.validator and org.hibernate.search (for OGM we used >> org.hibernate.ogm from the beginning). >> >> Any concerns? >> >> --Gunnar >> _______________________________________________ >> 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 /max http://about.me/maxandersen From sanne at hibernate.org Wed Oct 5 05:13:43 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 5 Oct 2016 10:13:43 +0100 Subject: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project} In-Reply-To: <3BE9D1EF-3F34-4FA3-89D3-5DEC40C4F91C@redhat.com> References: <3BE9D1EF-3F34-4FA3-89D3-5DEC40C4F91C@redhat.com> Message-ID: Hi Max, the intent is to publish "relocation artifacts" like this one which we created when the Hibernate Search main artifact was renamed from "org.hibernate:hibernate-search" to "org.hibernate:hibernate-search-orm" https://raw.githubusercontent.com/hibernate/hibernate-search/master/legacy/pom.xml If the tool in question respects the Maven relocation rules, when consuming the old coordinates you'd get a warning and be transparently served the new coordinates. Maven itself works fine with this, I don't know about other tools.. I've heard no complaints from the Search users but of course that's a smaller population and not many tools AFAIK, so I'm looking forward for feedback on more specific problems. It's not clear yet however if we'll actually do this and for how long, as e.g. Gradle seems to not be able to produce these so we'll need to possibly hack a custom plugin for this? In the chat with Steve yesterday we both agreed that we shouldn't do this forever, but to treat it like a deprecated method; so it seems sensible to keep it for the lifetime of ORM 6.x. In the case of the above Search example we kept it for longer, as it's doing no harm and is not in the way as much as maintaining deprecated code could be. I actually have one concern, after a night of sleep :) This might be just something that *we* like to see as maintainer in terms of order, but I'm wondering if this organization makes sense for end users. Considering the "groupId" to be pretty much an "organization id", I'd wager that consumers see us as one consistent entity, and we'd be possibly damaging the brand. We keep some of our projects in separate repositories as it would otherwise be too much maintenance and synchronization work, but several users have expressed that this is confusing and they'd rather see us, among others, align version numbers and release schedules. Also I guess one reason for the "groupId" to exist at all is to help ensuring uniqueness of artifact ids among the whole ecosystem, so that people not aware of each other don't step on each others toes.. but that's certainly questionable in our case as we can easily discuss naming of new modules among us. I just wonder if we're not going in opposite direction of usability for our own sake of selfish sense of organization. On the other end, maybe grouping them together will make it clearer to end users which artifacts need to use the same version? As ultimately, that's what is often unclear.. Thanks, Sanne On 5 October 2016 at 07:30, Max Rydahl Andersen wrote: > Won't this break like every existing example and 3rd party integrations > (think Spring projects) maven and gradle builds on the planet > ? Or are hibernate 6 so radically different there is no chance you would > just change the version number to have > builds work with both hibernate 5 and 6 ? > > Not saying it should not be done - just wondering if we grok the full impact > for users. > > /max > > >> No concerns. >> When talking about this with Steve I also added it to our next meeting >> agenda, however it looks like we're all onboard so maybe there isn't >> much to debate :) >> >> On 4 October 2016 at 19:19, Gunnar Morling wrote: >>> >>> Hi, >>> >>> I just stumbled across HHH-11153 ("Rename published groupId from >>> org.hibernate to org.hibernate.orm"), scheduled for ORM 6.0.0.Alpha1. >>> >>> I think that's a great idea and would suggest we do the same for >>> Hibernate >>> Validator and Search in their respective 6.0 releases: >>> org.hibernate.validator and org.hibernate.search (for OGM we used >>> org.hibernate.ogm from the beginning). >>> >>> Any concerns? >>> >>> --Gunnar >>> _______________________________________________ >>> 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 > > > > /max > http://about.me/maxandersen From gunnar at hibernate.org Wed Oct 5 05:44:26 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 5 Oct 2016 11:44:26 +0200 Subject: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project} In-Reply-To: References: <3BE9D1EF-3F34-4FA3-89D3-5DEC40C4F91C@redhat.com> Message-ID: > On the other end, maybe grouping them together will make it clearer to > end users which artifacts need to use the same version? Right, that'd be my hope as well. It'll just more clearly emphasize which artifacts "belong together" because they are part of the same project. More fine-grained group ids also help with discoverability of the modules of one project. E.g. try to find all the backends for Hibernate Search from this list of >80 artifacts under org.hibernate: http://mvnrepository.com/artifact/org.hibernate. It looks much more digestable for OGM: http://mvnrepository.com/artifact/org.hibernate.ogm which already uses its own group id. Taking Spring as an example, they also have different group ids for things like Spring Data, Spring Integration etc. I don't think it harms their brand. But yes, it'll be a migration challenge, needing good communication and education. Personally I think that's acceptable for a major version, esp. if we happen to do it at the same major (6) for ORM, Search and Validator. --Gunnar 2016-10-05 11:13 GMT+02:00 Sanne Grinovero : > Hi Max, > > the intent is to publish "relocation artifacts" like this one which we > created when the Hibernate Search main artifact was renamed from > "org.hibernate:hibernate-search" to > "org.hibernate:hibernate-search-orm" > > https://raw.githubusercontent.com/hibernate/hibernate- > search/master/legacy/pom.xml > > If the tool in question respects the Maven relocation rules, when > consuming the old coordinates you'd get a warning and be transparently > served the new coordinates. Maven itself works fine with this, I don't > know about other tools.. I've heard no complaints from the Search > users but of course that's a smaller population and not many tools > AFAIK, so I'm looking forward for feedback on more specific problems. > > It's not clear yet however if we'll actually do this and for how long, > as e.g. Gradle seems to not be able to produce these so we'll need to > possibly hack a custom plugin for this? > > In the chat with Steve yesterday we both agreed that we shouldn't do > this forever, but to treat it like a deprecated method; so it seems > sensible to keep it for the lifetime of ORM 6.x. > In the case of the above Search example we kept it for longer, as it's > doing no harm and is not in the way as much as maintaining deprecated > code could be. > > I actually have one concern, after a night of sleep :) > This might be just something that *we* like to see as maintainer in > terms of order, but I'm wondering if this organization makes sense for > end users. Considering the "groupId" to be pretty much an > "organization id", I'd wager that consumers see us as one consistent > entity, and we'd be possibly damaging the brand. > > We keep some of our projects in separate repositories as it would > otherwise be too much maintenance and synchronization work, but > several users have expressed that this is confusing and they'd rather > see us, among others, align version numbers and release schedules. > > Also I guess one reason for the "groupId" to exist at all is to help > ensuring uniqueness of artifact ids among the whole ecosystem, so that > people not aware of each other don't step on each others toes.. but > that's certainly questionable in our case as we can easily discuss > naming of new modules among us. > > I just wonder if we're not going in opposite direction of usability > for our own sake of selfish sense of organization. > On the other end, maybe grouping them together will make it clearer to > end users which artifacts need to use the same version? > As ultimately, that's what is often unclear.. > > Thanks, > Sanne > > > > On 5 October 2016 at 07:30, Max Rydahl Andersen > wrote: > > Won't this break like every existing example and 3rd party integrations > > (think Spring projects) maven and gradle builds on the planet > > ? Or are hibernate 6 so radically different there is no chance you would > > just change the version number to have > > builds work with both hibernate 5 and 6 ? > > > > Not saying it should not be done - just wondering if we grok the full > impact > > for users. > > > > /max > > > > > >> No concerns. > >> When talking about this with Steve I also added it to our next meeting > >> agenda, however it looks like we're all onboard so maybe there isn't > >> much to debate :) > >> > >> On 4 October 2016 at 19:19, Gunnar Morling > wrote: > >>> > >>> Hi, > >>> > >>> I just stumbled across HHH-11153 ("Rename published groupId from > >>> org.hibernate to org.hibernate.orm"), scheduled for ORM 6.0.0.Alpha1. > >>> > >>> I think that's a great idea and would suggest we do the same for > >>> Hibernate > >>> Validator and Search in their respective 6.0 releases: > >>> org.hibernate.validator and org.hibernate.search (for OGM we used > >>> org.hibernate.ogm from the beginning). > >>> > >>> Any concerns? > >>> > >>> --Gunnar > >>> _______________________________________________ > >>> 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 > > > > > > > > /max > > http://about.me/maxandersen > From steve at hibernate.org Wed Oct 5 16:59:20 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 05 Oct 2016 20:59:20 +0000 Subject: [hibernate-dev] SQM - encoding type info into the tree Message-ID: In SQM's domain metamodel we decided to follow JPA's guidelines in terms of javax.persistence.metamodel.Metamodel. That is to say... a Type in SQM describes a Java type not its database mapping, just as it is in JPA. As a concrete example of the difference and its implication, consider a Boolean attribute. The Type for that attribute would be a BasicType which only describes the Java Boolean type; it contains no information about how that value is mapped to the database (aka it is not a "mapping type"). But this mapping information is important. It is simply not enough to know that the value is a Boolean, we have to know that it is "a Boolean mapped to a BIT" or "a Boolean mapped to a CHAR(1)" etc. As we are building the SQM, we ask the "consumer" (ORM, etc) to resolve domain metamodel info for us. The ideal being that as as we build the SQM tree in SQM we could encode "mapping type" information from the consumer into the tree structure. But the problem is how to define access to a "mapped type system" when SQM's type system is strictly domain-based. Where this really becomes problematic is when determining the "implicit type" for Expression nodes in the tree. Consider an example... {code} from Person p where p.active = ?1 {code} The idea is that we really want to be able to infer the type of the "?1" parameter expression based on its context in the query. Since it is used as an operand of a equality predicate we know that its type should be the same as the other operand, here: "p.active". But this is where the domain-type/mapping-type split comes into play. At the SQM level we have no notion of a "mapping type", so the fact that "p.active" is "a Boolean mapped to a BIT" or "a Boolean mapped to a CHAR(1)", which is really the information we want associated with the param expression. All we can know from the SQM side is that "p.active" is a BasicType and therefore "?1" should be to - but that is not enough contextual info to handle binding that param properly. I see a few options to address this: 1. Add a notion of "mapping type" to SQM's domain metamodel. The "mapping type" would not be ORM-specific (aka, no expectation of JDBC). Think of it more as a momento (pattern). This effectively creates a complete parallel of ORM's type system though, which always feels like a code smell to me. 2. Simply leave determination of an expression's "implicit type" out of SQM. Resolving an expression's implicit type based on Type as defined by JPA and currently by SQM is simply not expressive enough to be of any value. As the SQM consumer processes the SQM tree it would make that determination then. From sanne at hibernate.org Wed Oct 5 18:20:12 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 5 Oct 2016 23:20:12 +0100 Subject: [hibernate-dev] Hibernate Search: new 5.7 branch, dual streams development! Message-ID: I've promoted my "ORM 5.2 upgrade preview" pull request as upstream branch "5.7", just after having it rebased on the freshly baked tag: 5.6.0.Beta3 This implies we have now two active streams of development for Hibernate Search (!); we still have just one mission: finish 5.6 and its Elasticsearch support. We'll have to occasionally forward-port patches from 5.6 to 5.7; I propose to keep the work focused on 5.6 and intentionally ignore 5.7: then when the next 5.6.0.CR1 release happens one volunteer takes the full range of commits 5.6.0.Beta3-5.6.0.CR1 and applies it as a single block on 5.7. On branch 5.7 we'll exclusively apply patches to keep up with ORM upgrades. Hopefully there won't be too many conflicts: please keep this all in mind when tempted by some "cleanup refactoring". We'll have fun later ;-) For those wondering why: finishing 5.6 was taking more than expected, and many users need an Hibernate Search version compatible with ORM 5.2.0+ (while version 5.6 was aiming at ORM 5.1.x and we can't leave those users without any compatible version can we?). As soon as the Elasticsearch integration is satisfactory we'll return to more healthy time-window sprints and consequentially regular, periodic releases. Next step: finalize the simultaneous release of versions: - 5.6.0.Beta3 - 5.7.0.Alpha1 - 5.5.5.Final Thanks, Sanne From manderse at redhat.com Wed Oct 5 18:29:15 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Thu, 06 Oct 2016 00:29:15 +0200 Subject: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project} In-Reply-To: References: <3BE9D1EF-3F34-4FA3-89D3-5DEC40C4F91C@redhat.com> Message-ID: <951EFD82-A67E-48FE-ABF2-2D8BA355D6F9@redhat.com> yes, with relocation artefacts things could be made less annoying. Just wanted to be sure we at least considered it and I hope you can get Gradle to play nice ;) /max > Hi Max, > > the intent is to publish "relocation artifacts" like this one which we > created when the Hibernate Search main artifact was renamed from > "org.hibernate:hibernate-search" to > "org.hibernate:hibernate-search-orm" > > https://raw.githubusercontent.com/hibernate/hibernate-search/master/legacy/pom.xml > > If the tool in question respects the Maven relocation rules, when > consuming the old coordinates you'd get a warning and be transparently > served the new coordinates. Maven itself works fine with this, I don't > know about other tools.. I've heard no complaints from the Search > users but of course that's a smaller population and not many tools > AFAIK, so I'm looking forward for feedback on more specific problems. > > It's not clear yet however if we'll actually do this and for how long, > as e.g. Gradle seems to not be able to produce these so we'll need to > possibly hack a custom plugin for this? > > In the chat with Steve yesterday we both agreed that we shouldn't do > this forever, but to treat it like a deprecated method; so it seems > sensible to keep it for the lifetime of ORM 6.x. > In the case of the above Search example we kept it for longer, as it's > doing no harm and is not in the way as much as maintaining deprecated > code could be. > > I actually have one concern, after a night of sleep :) > This might be just something that *we* like to see as maintainer in > terms of order, but I'm wondering if this organization makes sense for > end users. Considering the "groupId" to be pretty much an > "organization id", I'd wager that consumers see us as one consistent > entity, and we'd be possibly damaging the brand. > > We keep some of our projects in separate repositories as it would > otherwise be too much maintenance and synchronization work, but > several users have expressed that this is confusing and they'd rather > see us, among others, align version numbers and release schedules. > > Also I guess one reason for the "groupId" to exist at all is to help > ensuring uniqueness of artifact ids among the whole ecosystem, so that > people not aware of each other don't step on each others toes.. but > that's certainly questionable in our case as we can easily discuss > naming of new modules among us. > > I just wonder if we're not going in opposite direction of usability > for our own sake of selfish sense of organization. > On the other end, maybe grouping them together will make it clearer to > end users which artifacts need to use the same version? > As ultimately, that's what is often unclear.. > > Thanks, > Sanne > > On 5 October 2016 at 07:30, Max Rydahl Andersen > wrote: >> Won't this break like every existing example and 3rd party >> integrations >> (think Spring projects) maven and gradle builds on the planet >> ? Or are hibernate 6 so radically different there is no chance you >> would >> just change the version number to have >> builds work with both hibernate 5 and 6 ? >> >> Not saying it should not be done - just wondering if we grok the full >> impact >> for users. >> >> /max >> >> >>> No concerns. >>> When talking about this with Steve I also added it to our next >>> meeting >>> agenda, however it looks like we're all onboard so maybe there isn't >>> much to debate :) >>> >>> On 4 October 2016 at 19:19, Gunnar Morling >>> wrote: >>>> >>>> Hi, >>>> >>>> I just stumbled across HHH-11153 ("Rename published groupId from >>>> org.hibernate to org.hibernate.orm"), scheduled for ORM >>>> 6.0.0.Alpha1. >>>> >>>> I think that's a great idea and would suggest we do the same for >>>> Hibernate >>>> Validator and Search in their respective 6.0 releases: >>>> org.hibernate.validator and org.hibernate.search (for OGM we used >>>> org.hibernate.ogm from the beginning). >>>> >>>> Any concerns? >>>> >>>> --Gunnar >>>> _______________________________________________ >>>> 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 >> >> >> >> /max >> http://about.me/maxandersen /max http://about.me/maxandersen From steve at hibernate.org Wed Oct 5 18:44:20 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 05 Oct 2016 22:44:20 +0000 Subject: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project} In-Reply-To: <951EFD82-A67E-48FE-ABF2-2D8BA355D6F9@redhat.com> References: <3BE9D1EF-3F34-4FA3-89D3-5DEC40C4F91C@redhat.com> <951EFD82-A67E-48FE-ABF2-2D8BA355D6F9@redhat.com> Message-ID: The grouping is certainly "nice". But given the possibility of difficulties renaming the groupId could have for users I'd not make this change just because it is nice. No, this is part of a larger change I want to do which is laid out in the JIRA Gunnar mentioned. Specifically I want to move away from publishing to JBoss Nexus and instead publish directly to Sonatype's OSSRH offering. On Wed, Oct 5, 2016, 5:32 PM Max Rydahl Andersen wrote: > yes, with relocation artefacts things could be made less annoying. > > Just wanted to be sure we at least considered it and I hope you can get > Gradle to play nice ;) > > /max > > > Hi Max, > > > > the intent is to publish "relocation artifacts" like this one which we > > created when the Hibernate Search main artifact was renamed from > > "org.hibernate:hibernate-search" to > > "org.hibernate:hibernate-search-orm" > > > > > https://raw.githubusercontent.com/hibernate/hibernate-search/master/legacy/pom.xml > > > > If the tool in question respects the Maven relocation rules, when > > consuming the old coordinates you'd get a warning and be transparently > > served the new coordinates. Maven itself works fine with this, I don't > > know about other tools.. I've heard no complaints from the Search > > users but of course that's a smaller population and not many tools > > AFAIK, so I'm looking forward for feedback on more specific problems. > > > > It's not clear yet however if we'll actually do this and for how long, > > as e.g. Gradle seems to not be able to produce these so we'll need to > > possibly hack a custom plugin for this? > > > > In the chat with Steve yesterday we both agreed that we shouldn't do > > this forever, but to treat it like a deprecated method; so it seems > > sensible to keep it for the lifetime of ORM 6.x. > > In the case of the above Search example we kept it for longer, as it's > > doing no harm and is not in the way as much as maintaining deprecated > > code could be. > > > > I actually have one concern, after a night of sleep :) > > This might be just something that *we* like to see as maintainer in > > terms of order, but I'm wondering if this organization makes sense for > > end users. Considering the "groupId" to be pretty much an > > "organization id", I'd wager that consumers see us as one consistent > > entity, and we'd be possibly damaging the brand. > > > > We keep some of our projects in separate repositories as it would > > otherwise be too much maintenance and synchronization work, but > > several users have expressed that this is confusing and they'd rather > > see us, among others, align version numbers and release schedules. > > > > Also I guess one reason for the "groupId" to exist at all is to help > > ensuring uniqueness of artifact ids among the whole ecosystem, so that > > people not aware of each other don't step on each others toes.. but > > that's certainly questionable in our case as we can easily discuss > > naming of new modules among us. > > > > I just wonder if we're not going in opposite direction of usability > > for our own sake of selfish sense of organization. > > On the other end, maybe grouping them together will make it clearer to > > end users which artifacts need to use the same version? > > As ultimately, that's what is often unclear.. > > > > Thanks, > > Sanne > > > > On 5 October 2016 at 07:30, Max Rydahl Andersen > > wrote: > >> Won't this break like every existing example and 3rd party > >> integrations > >> (think Spring projects) maven and gradle builds on the planet > >> ? Or are hibernate 6 so radically different there is no chance you > >> would > >> just change the version number to have > >> builds work with both hibernate 5 and 6 ? > >> > >> Not saying it should not be done - just wondering if we grok the full > >> impact > >> for users. > >> > >> /max > >> > >> > >>> No concerns. > >>> When talking about this with Steve I also added it to our next > >>> meeting > >>> agenda, however it looks like we're all onboard so maybe there isn't > >>> much to debate :) > >>> > >>> On 4 October 2016 at 19:19, Gunnar Morling > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> I just stumbled across HHH-11153 ("Rename published groupId from > >>>> org.hibernate to org.hibernate.orm"), scheduled for ORM > >>>> 6.0.0.Alpha1. > >>>> > >>>> I think that's a great idea and would suggest we do the same for > >>>> Hibernate > >>>> Validator and Search in their respective 6.0 releases: > >>>> org.hibernate.validator and org.hibernate.search (for OGM we used > >>>> org.hibernate.ogm from the beginning). > >>>> > >>>> Any concerns? > >>>> > >>>> --Gunnar > >>>> _______________________________________________ > >>>> 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 > >> > >> > >> > >> /max > >> http://about.me/maxandersen > > > /max > http://about.me/maxandersen > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Oct 5 18:48:00 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 05 Oct 2016 22:48:00 +0000 Subject: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project} In-Reply-To: References: <3BE9D1EF-3F34-4FA3-89D3-5DEC40C4F91C@redhat.com> <951EFD82-A67E-48FE-ABF2-2D8BA355D6F9@redhat.com> Message-ID: Are we required to change groupId for that? Asking mainly to get OGM there as well, as it's already using the proposed scheme. On Wed, 5 Oct 2016, 23:44 Steve Ebersole, wrote: > The grouping is certainly "nice". But given the possibility of > difficulties renaming the groupId could have for users I'd not make this > change just because it is nice. No, this is part of a larger change I want > to do which is laid out in the JIRA Gunnar mentioned. Specifically I want > to move away from publishing to JBoss Nexus and instead publish directly to > Sonatype's OSSRH offering. > > On Wed, Oct 5, 2016, 5:32 PM Max Rydahl Andersen > wrote: > > yes, with relocation artefacts things could be made less annoying. > > Just wanted to be sure we at least considered it and I hope you can get > Gradle to play nice ;) > > /max > > > Hi Max, > > > > the intent is to publish "relocation artifacts" like this one which we > > created when the Hibernate Search main artifact was renamed from > > "org.hibernate:hibernate-search" to > > "org.hibernate:hibernate-search-orm" > > > > > https://raw.githubusercontent.com/hibernate/hibernate-search/master/legacy/pom.xml > > > > If the tool in question respects the Maven relocation rules, when > > consuming the old coordinates you'd get a warning and be transparently > > served the new coordinates. Maven itself works fine with this, I don't > > know about other tools.. I've heard no complaints from the Search > > users but of course that's a smaller population and not many tools > > AFAIK, so I'm looking forward for feedback on more specific problems. > > > > It's not clear yet however if we'll actually do this and for how long, > > as e.g. Gradle seems to not be able to produce these so we'll need to > > possibly hack a custom plugin for this? > > > > In the chat with Steve yesterday we both agreed that we shouldn't do > > this forever, but to treat it like a deprecated method; so it seems > > sensible to keep it for the lifetime of ORM 6.x. > > In the case of the above Search example we kept it for longer, as it's > > doing no harm and is not in the way as much as maintaining deprecated > > code could be. > > > > I actually have one concern, after a night of sleep :) > > This might be just something that *we* like to see as maintainer in > > terms of order, but I'm wondering if this organization makes sense for > > end users. Considering the "groupId" to be pretty much an > > "organization id", I'd wager that consumers see us as one consistent > > entity, and we'd be possibly damaging the brand. > > > > We keep some of our projects in separate repositories as it would > > otherwise be too much maintenance and synchronization work, but > > several users have expressed that this is confusing and they'd rather > > see us, among others, align version numbers and release schedules. > > > > Also I guess one reason for the "groupId" to exist at all is to help > > ensuring uniqueness of artifact ids among the whole ecosystem, so that > > people not aware of each other don't step on each others toes.. but > > that's certainly questionable in our case as we can easily discuss > > naming of new modules among us. > > > > I just wonder if we're not going in opposite direction of usability > > for our own sake of selfish sense of organization. > > On the other end, maybe grouping them together will make it clearer to > > end users which artifacts need to use the same version? > > As ultimately, that's what is often unclear.. > > > > Thanks, > > Sanne > > > > On 5 October 2016 at 07:30, Max Rydahl Andersen > > wrote: > >> Won't this break like every existing example and 3rd party > >> integrations > >> (think Spring projects) maven and gradle builds on the planet > >> ? Or are hibernate 6 so radically different there is no chance you > >> would > >> just change the version number to have > >> builds work with both hibernate 5 and 6 ? > >> > >> Not saying it should not be done - just wondering if we grok the full > >> impact > >> for users. > >> > >> /max > >> > >> > >>> No concerns. > >>> When talking about this with Steve I also added it to our next > >>> meeting > >>> agenda, however it looks like we're all onboard so maybe there isn't > >>> much to debate :) > >>> > >>> On 4 October 2016 at 19:19, Gunnar Morling > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> I just stumbled across HHH-11153 ("Rename published groupId from > >>>> org.hibernate to org.hibernate.orm"), scheduled for ORM > >>>> 6.0.0.Alpha1. > >>>> > >>>> I think that's a great idea and would suggest we do the same for > >>>> Hibernate > >>>> Validator and Search in their respective 6.0 releases: > >>>> org.hibernate.validator and org.hibernate.search (for OGM we used > >>>> org.hibernate.ogm from the beginning). > >>>> > >>>> Any concerns? > >>>> > >>>> --Gunnar > >>>> _______________________________________________ > >>>> 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 > >> > >> > >> > >> /max > >> http://about.me/maxandersen > > > /max > http://about.me/maxandersen > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From steve at hibernate.org Wed Oct 5 21:07:33 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 06 Oct 2016 01:07:33 +0000 Subject: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project} In-Reply-To: References: <3BE9D1EF-3F34-4FA3-89D3-5DEC40C4F91C@redhat.com> <951EFD82-A67E-48FE-ABF2-2D8BA355D6F9@redhat.com> Message-ID: It's more a convenience of defining the rsync that currently happens between JBoss and Central. On Wed, Oct 5, 2016, 5:48 PM Sanne Grinovero wrote: > Are we required to change groupId for that? > Asking mainly to get OGM there as well, as it's already using the proposed > scheme. > > On Wed, 5 Oct 2016, 23:44 Steve Ebersole, wrote: > > The grouping is certainly "nice". But given the possibility of > difficulties renaming the groupId could have for users I'd not make this > change just because it is nice. No, this is part of a larger change I want > to do which is laid out in the JIRA Gunnar mentioned. Specifically I want > to move away from publishing to JBoss Nexus and instead publish directly to > Sonatype's OSSRH offering. > > On Wed, Oct 5, 2016, 5:32 PM Max Rydahl Andersen > wrote: > > yes, with relocation artefacts things could be made less annoying. > > Just wanted to be sure we at least considered it and I hope you can get > Gradle to play nice ;) > > /max > > > Hi Max, > > > > the intent is to publish "relocation artifacts" like this one which we > > created when the Hibernate Search main artifact was renamed from > > "org.hibernate:hibernate-search" to > > "org.hibernate:hibernate-search-orm" > > > > > https://raw.githubusercontent.com/hibernate/hibernate-search/master/legacy/pom.xml > > > > If the tool in question respects the Maven relocation rules, when > > consuming the old coordinates you'd get a warning and be transparently > > served the new coordinates. Maven itself works fine with this, I don't > > know about other tools.. I've heard no complaints from the Search > > users but of course that's a smaller population and not many tools > > AFAIK, so I'm looking forward for feedback on more specific problems. > > > > It's not clear yet however if we'll actually do this and for how long, > > as e.g. Gradle seems to not be able to produce these so we'll need to > > possibly hack a custom plugin for this? > > > > In the chat with Steve yesterday we both agreed that we shouldn't do > > this forever, but to treat it like a deprecated method; so it seems > > sensible to keep it for the lifetime of ORM 6.x. > > In the case of the above Search example we kept it for longer, as it's > > doing no harm and is not in the way as much as maintaining deprecated > > code could be. > > > > I actually have one concern, after a night of sleep :) > > This might be just something that *we* like to see as maintainer in > > terms of order, but I'm wondering if this organization makes sense for > > end users. Considering the "groupId" to be pretty much an > > "organization id", I'd wager that consumers see us as one consistent > > entity, and we'd be possibly damaging the brand. > > > > We keep some of our projects in separate repositories as it would > > otherwise be too much maintenance and synchronization work, but > > several users have expressed that this is confusing and they'd rather > > see us, among others, align version numbers and release schedules. > > > > Also I guess one reason for the "groupId" to exist at all is to help > > ensuring uniqueness of artifact ids among the whole ecosystem, so that > > people not aware of each other don't step on each others toes.. but > > that's certainly questionable in our case as we can easily discuss > > naming of new modules among us. > > > > I just wonder if we're not going in opposite direction of usability > > for our own sake of selfish sense of organization. > > On the other end, maybe grouping them together will make it clearer to > > end users which artifacts need to use the same version? > > As ultimately, that's what is often unclear.. > > > > Thanks, > > Sanne > > > > On 5 October 2016 at 07:30, Max Rydahl Andersen > > wrote: > >> Won't this break like every existing example and 3rd party > >> integrations > >> (think Spring projects) maven and gradle builds on the planet > >> ? Or are hibernate 6 so radically different there is no chance you > >> would > >> just change the version number to have > >> builds work with both hibernate 5 and 6 ? > >> > >> Not saying it should not be done - just wondering if we grok the full > >> impact > >> for users. > >> > >> /max > >> > >> > >>> No concerns. > >>> When talking about this with Steve I also added it to our next > >>> meeting > >>> agenda, however it looks like we're all onboard so maybe there isn't > >>> much to debate :) > >>> > >>> On 4 October 2016 at 19:19, Gunnar Morling > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> I just stumbled across HHH-11153 ("Rename published groupId from > >>>> org.hibernate to org.hibernate.orm"), scheduled for ORM > >>>> 6.0.0.Alpha1. > >>>> > >>>> I think that's a great idea and would suggest we do the same for > >>>> Hibernate > >>>> Validator and Search in their respective 6.0 releases: > >>>> org.hibernate.validator and org.hibernate.search (for OGM we used > >>>> org.hibernate.ogm from the beginning). > >>>> > >>>> Any concerns? > >>>> > >>>> --Gunnar > >>>> _______________________________________________ > >>>> 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 > >> > >> > >> > >> /max > >> http://about.me/maxandersen > > > /max > http://about.me/maxandersen > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From steve at hibernate.org Wed Oct 5 22:10:13 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 06 Oct 2016 02:10:13 +0000 Subject: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project} In-Reply-To: References: <3BE9D1EF-3F34-4FA3-89D3-5DEC40C4F91C@redhat.com> <951EFD82-A67E-48FE-ABF2-2D8BA355D6F9@redhat.com> Message-ID: To clarify my last reply... Today all of the artifacts under org.hibernate are published to JBoss Nexus and then rsync'ed to Central. When I move to publishing the artifacts for ORM to Central "directly" (via OSSRH), those artifacts need to be excluded from the rsync. But today, because all (most) of the projects use org.hibernate as the groupId there is no single directory I can say to exclude. Instead we'd have to list the ORM artifacts explicitly, individually. The problem ofc being when we add a new module to ORM we'd have to remember to add that to the list of exclusions. Thinking about it more though, don't we have that problem anyway since we still want to publish relocation artifacts? On Wed, Oct 5, 2016 at 8:04 PM Steve Ebersole wrote: > It's more a convenience of defining the rsync that currently happens > between JBoss and Central. > > On Wed, Oct 5, 2016, 5:48 PM Sanne Grinovero wrote: > > Are we required to change groupId for that? > Asking mainly to get OGM there as well, as it's already using the proposed > scheme. > > On Wed, 5 Oct 2016, 23:44 Steve Ebersole, wrote: > > The grouping is certainly "nice". But given the possibility of > difficulties renaming the groupId could have for users I'd not make this > change just because it is nice. No, this is part of a larger change I want > to do which is laid out in the JIRA Gunnar mentioned. Specifically I want > to move away from publishing to JBoss Nexus and instead publish directly to > Sonatype's OSSRH offering. > > On Wed, Oct 5, 2016, 5:32 PM Max Rydahl Andersen > wrote: > > yes, with relocation artefacts things could be made less annoying. > > Just wanted to be sure we at least considered it and I hope you can get > Gradle to play nice ;) > > /max > > > Hi Max, > > > > the intent is to publish "relocation artifacts" like this one which we > > created when the Hibernate Search main artifact was renamed from > > "org.hibernate:hibernate-search" to > > "org.hibernate:hibernate-search-orm" > > > > > https://raw.githubusercontent.com/hibernate/hibernate-search/master/legacy/pom.xml > > > > If the tool in question respects the Maven relocation rules, when > > consuming the old coordinates you'd get a warning and be transparently > > served the new coordinates. Maven itself works fine with this, I don't > > know about other tools.. I've heard no complaints from the Search > > users but of course that's a smaller population and not many tools > > AFAIK, so I'm looking forward for feedback on more specific problems. > > > > It's not clear yet however if we'll actually do this and for how long, > > as e.g. Gradle seems to not be able to produce these so we'll need to > > possibly hack a custom plugin for this? > > > > In the chat with Steve yesterday we both agreed that we shouldn't do > > this forever, but to treat it like a deprecated method; so it seems > > sensible to keep it for the lifetime of ORM 6.x. > > In the case of the above Search example we kept it for longer, as it's > > doing no harm and is not in the way as much as maintaining deprecated > > code could be. > > > > I actually have one concern, after a night of sleep :) > > This might be just something that *we* like to see as maintainer in > > terms of order, but I'm wondering if this organization makes sense for > > end users. Considering the "groupId" to be pretty much an > > "organization id", I'd wager that consumers see us as one consistent > > entity, and we'd be possibly damaging the brand. > > > > We keep some of our projects in separate repositories as it would > > otherwise be too much maintenance and synchronization work, but > > several users have expressed that this is confusing and they'd rather > > see us, among others, align version numbers and release schedules. > > > > Also I guess one reason for the "groupId" to exist at all is to help > > ensuring uniqueness of artifact ids among the whole ecosystem, so that > > people not aware of each other don't step on each others toes.. but > > that's certainly questionable in our case as we can easily discuss > > naming of new modules among us. > > > > I just wonder if we're not going in opposite direction of usability > > for our own sake of selfish sense of organization. > > On the other end, maybe grouping them together will make it clearer to > > end users which artifacts need to use the same version? > > As ultimately, that's what is often unclear.. > > > > Thanks, > > Sanne > > > > On 5 October 2016 at 07:30, Max Rydahl Andersen > > wrote: > >> Won't this break like every existing example and 3rd party > >> integrations > >> (think Spring projects) maven and gradle builds on the planet > >> ? Or are hibernate 6 so radically different there is no chance you > >> would > >> just change the version number to have > >> builds work with both hibernate 5 and 6 ? > >> > >> Not saying it should not be done - just wondering if we grok the full > >> impact > >> for users. > >> > >> /max > >> > >> > >>> No concerns. > >>> When talking about this with Steve I also added it to our next > >>> meeting > >>> agenda, however it looks like we're all onboard so maybe there isn't > >>> much to debate :) > >>> > >>> On 4 October 2016 at 19:19, Gunnar Morling > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> I just stumbled across HHH-11153 ("Rename published groupId from > >>>> org.hibernate to org.hibernate.orm"), scheduled for ORM > >>>> 6.0.0.Alpha1. > >>>> > >>>> I think that's a great idea and would suggest we do the same for > >>>> Hibernate > >>>> Validator and Search in their respective 6.0 releases: > >>>> org.hibernate.validator and org.hibernate.search (for OGM we used > >>>> org.hibernate.ogm from the beginning). > >>>> > >>>> Any concerns? > >>>> > >>>> --Gunnar > >>>> _______________________________________________ > >>>> 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 > >> > >> > >> > >> /max > >> http://about.me/maxandersen > > > /max > http://about.me/maxandersen > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From gunnar at hibernate.org Thu Oct 6 02:26:09 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 6 Oct 2016 08:26:09 +0200 Subject: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project} In-Reply-To: References: <3BE9D1EF-3F34-4FA3-89D3-5DEC40C4F91C@redhat.com> <951EFD82-A67E-48FE-ABF2-2D8BA355D6F9@redhat.com> Message-ID: > Thinking about it more though, don't we have that problem anyway since we > still want to publish relocation artifacts? Do we need to create relocation artifacts for new modules only added after the group id change? There won't be wrong references to these out in the wild, so people should be fine without them? Either way I think if ORM changes it in 6, we should do it consistently for HV/HSEARCH, too, as it will be less confusing down the road. 2016-10-06 4:10 GMT+02:00 Steve Ebersole : > To clarify my last reply... > > Today all of the artifacts under org.hibernate are published to JBoss Nexus > and then rsync'ed to Central. When I move to publishing the artifacts for > ORM to Central "directly" (via OSSRH), those artifacts need to be excluded > from the rsync. But today, because all (most) of the projects use > org.hibernate as the groupId there is no single directory I can say to > exclude. Instead we'd have to list the ORM artifacts explicitly, > individually. The problem ofc being when we add a new module to ORM we'd > have to remember to add that to the list of exclusions. > > Thinking about it more though, don't we have that problem anyway since we > still want to publish relocation artifacts? > > On Wed, Oct 5, 2016 at 8:04 PM Steve Ebersole wrote: > > > It's more a convenience of defining the rsync that currently happens > > between JBoss and Central. > > > > On Wed, Oct 5, 2016, 5:48 PM Sanne Grinovero > wrote: > > > > Are we required to change groupId for that? > > Asking mainly to get OGM there as well, as it's already using the > proposed > > scheme. > > > > On Wed, 5 Oct 2016, 23:44 Steve Ebersole, wrote: > > > > The grouping is certainly "nice". But given the possibility of > > difficulties renaming the groupId could have for users I'd not make this > > change just because it is nice. No, this is part of a larger change I > want > > to do which is laid out in the JIRA Gunnar mentioned. Specifically I > want > > to move away from publishing to JBoss Nexus and instead publish directly > to > > Sonatype's OSSRH offering. > > > > On Wed, Oct 5, 2016, 5:32 PM Max Rydahl Andersen > > wrote: > > > > yes, with relocation artefacts things could be made less annoying. > > > > Just wanted to be sure we at least considered it and I hope you can get > > Gradle to play nice ;) > > > > /max > > > > > Hi Max, > > > > > > the intent is to publish "relocation artifacts" like this one which we > > > created when the Hibernate Search main artifact was renamed from > > > "org.hibernate:hibernate-search" to > > > "org.hibernate:hibernate-search-orm" > > > > > > > > https://raw.githubusercontent.com/hibernate/hibernate- > search/master/legacy/pom.xml > > > > > > If the tool in question respects the Maven relocation rules, when > > > consuming the old coordinates you'd get a warning and be transparently > > > served the new coordinates. Maven itself works fine with this, I don't > > > know about other tools.. I've heard no complaints from the Search > > > users but of course that's a smaller population and not many tools > > > AFAIK, so I'm looking forward for feedback on more specific problems. > > > > > > It's not clear yet however if we'll actually do this and for how long, > > > as e.g. Gradle seems to not be able to produce these so we'll need to > > > possibly hack a custom plugin for this? > > > > > > In the chat with Steve yesterday we both agreed that we shouldn't do > > > this forever, but to treat it like a deprecated method; so it seems > > > sensible to keep it for the lifetime of ORM 6.x. > > > In the case of the above Search example we kept it for longer, as it's > > > doing no harm and is not in the way as much as maintaining deprecated > > > code could be. > > > > > > I actually have one concern, after a night of sleep :) > > > This might be just something that *we* like to see as maintainer in > > > terms of order, but I'm wondering if this organization makes sense for > > > end users. Considering the "groupId" to be pretty much an > > > "organization id", I'd wager that consumers see us as one consistent > > > entity, and we'd be possibly damaging the brand. > > > > > > We keep some of our projects in separate repositories as it would > > > otherwise be too much maintenance and synchronization work, but > > > several users have expressed that this is confusing and they'd rather > > > see us, among others, align version numbers and release schedules. > > > > > > Also I guess one reason for the "groupId" to exist at all is to help > > > ensuring uniqueness of artifact ids among the whole ecosystem, so that > > > people not aware of each other don't step on each others toes.. but > > > that's certainly questionable in our case as we can easily discuss > > > naming of new modules among us. > > > > > > I just wonder if we're not going in opposite direction of usability > > > for our own sake of selfish sense of organization. > > > On the other end, maybe grouping them together will make it clearer to > > > end users which artifacts need to use the same version? > > > As ultimately, that's what is often unclear.. > > > > > > Thanks, > > > Sanne > > > > > > On 5 October 2016 at 07:30, Max Rydahl Andersen > > > wrote: > > >> Won't this break like every existing example and 3rd party > > >> integrations > > >> (think Spring projects) maven and gradle builds on the planet > > >> ? Or are hibernate 6 so radically different there is no chance you > > >> would > > >> just change the version number to have > > >> builds work with both hibernate 5 and 6 ? > > >> > > >> Not saying it should not be done - just wondering if we grok the full > > >> impact > > >> for users. > > >> > > >> /max > > >> > > >> > > >>> No concerns. > > >>> When talking about this with Steve I also added it to our next > > >>> meeting > > >>> agenda, however it looks like we're all onboard so maybe there isn't > > >>> much to debate :) > > >>> > > >>> On 4 October 2016 at 19:19, Gunnar Morling > > >>> wrote: > > >>>> > > >>>> Hi, > > >>>> > > >>>> I just stumbled across HHH-11153 ("Rename published groupId from > > >>>> org.hibernate to org.hibernate.orm"), scheduled for ORM > > >>>> 6.0.0.Alpha1. > > >>>> > > >>>> I think that's a great idea and would suggest we do the same for > > >>>> Hibernate > > >>>> Validator and Search in their respective 6.0 releases: > > >>>> org.hibernate.validator and org.hibernate.search (for OGM we used > > >>>> org.hibernate.ogm from the beginning). > > >>>> > > >>>> Any concerns? > > >>>> > > >>>> --Gunnar > > >>>> _______________________________________________ > > >>>> 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 > > >> > > >> > > >> > > >> /max > > >> http://about.me/maxandersen > > > > > > /max > > http://about.me/maxandersen > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Thu Oct 6 06:03:22 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 6 Oct 2016 11:03:22 +0100 Subject: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project} In-Reply-To: References: <3BE9D1EF-3F34-4FA3-89D3-5DEC40C4F91C@redhat.com> <951EFD82-A67E-48FE-ABF2-2D8BA355D6F9@redhat.com> Message-ID: On 6 October 2016 at 07:26, Gunnar Morling wrote: >> Thinking about it more though, don't we have that problem anyway since we >> still want to publish relocation artifacts? > > Do we need to create relocation artifacts for new modules only added after > the group id change? There won't be wrong references to these out in the > wild, so people should be fine without them? What Steve (rightfully) suggests is that the relocation artifacts will have the old groupIds, so we would still be publishing new artifacts using the old ids, and will need to accommodate for that in any synchronisation rules. > Either way I think if ORM changes it in 6, we should do it consistently for > HV/HSEARCH, too, as it will be less confusing down the road. +1 > > 2016-10-06 4:10 GMT+02:00 Steve Ebersole : >> >> To clarify my last reply... >> >> Today all of the artifacts under org.hibernate are published to JBoss >> Nexus >> and then rsync'ed to Central. When I move to publishing the artifacts for >> ORM to Central "directly" (via OSSRH), those artifacts need to be excluded >> from the rsync. But today, because all (most) of the projects use >> org.hibernate as the groupId there is no single directory I can say to >> exclude. Instead we'd have to list the ORM artifacts explicitly, >> individually. The problem ofc being when we add a new module to ORM we'd >> have to remember to add that to the list of exclusions. >> >> Thinking about it more though, don't we have that problem anyway since we >> still want to publish relocation artifacts? >> >> On Wed, Oct 5, 2016 at 8:04 PM Steve Ebersole wrote: >> >> > It's more a convenience of defining the rsync that currently happens >> > between JBoss and Central. >> > >> > On Wed, Oct 5, 2016, 5:48 PM Sanne Grinovero >> > wrote: >> > >> > Are we required to change groupId for that? >> > Asking mainly to get OGM there as well, as it's already using the >> > proposed >> > scheme. >> > >> > On Wed, 5 Oct 2016, 23:44 Steve Ebersole, wrote: >> > >> > The grouping is certainly "nice". But given the possibility of >> > difficulties renaming the groupId could have for users I'd not make this >> > change just because it is nice. No, this is part of a larger change I >> > want >> > to do which is laid out in the JIRA Gunnar mentioned. Specifically I >> > want >> > to move away from publishing to JBoss Nexus and instead publish directly >> > to >> > Sonatype's OSSRH offering. >> > >> > On Wed, Oct 5, 2016, 5:32 PM Max Rydahl Andersen >> > wrote: >> > >> > yes, with relocation artefacts things could be made less annoying. >> > >> > Just wanted to be sure we at least considered it and I hope you can get >> > Gradle to play nice ;) >> > >> > /max >> > >> > > Hi Max, >> > > >> > > the intent is to publish "relocation artifacts" like this one which we >> > > created when the Hibernate Search main artifact was renamed from >> > > "org.hibernate:hibernate-search" to >> > > "org.hibernate:hibernate-search-orm" >> > > >> > > >> > >> > https://raw.githubusercontent.com/hibernate/hibernate-search/master/legacy/pom.xml >> > > >> > > If the tool in question respects the Maven relocation rules, when >> > > consuming the old coordinates you'd get a warning and be transparently >> > > served the new coordinates. Maven itself works fine with this, I don't >> > > know about other tools.. I've heard no complaints from the Search >> > > users but of course that's a smaller population and not many tools >> > > AFAIK, so I'm looking forward for feedback on more specific problems. >> > > >> > > It's not clear yet however if we'll actually do this and for how long, >> > > as e.g. Gradle seems to not be able to produce these so we'll need to >> > > possibly hack a custom plugin for this? >> > > >> > > In the chat with Steve yesterday we both agreed that we shouldn't do >> > > this forever, but to treat it like a deprecated method; so it seems >> > > sensible to keep it for the lifetime of ORM 6.x. >> > > In the case of the above Search example we kept it for longer, as it's >> > > doing no harm and is not in the way as much as maintaining deprecated >> > > code could be. >> > > >> > > I actually have one concern, after a night of sleep :) >> > > This might be just something that *we* like to see as maintainer in >> > > terms of order, but I'm wondering if this organization makes sense for >> > > end users. Considering the "groupId" to be pretty much an >> > > "organization id", I'd wager that consumers see us as one consistent >> > > entity, and we'd be possibly damaging the brand. >> > > >> > > We keep some of our projects in separate repositories as it would >> > > otherwise be too much maintenance and synchronization work, but >> > > several users have expressed that this is confusing and they'd rather >> > > see us, among others, align version numbers and release schedules. >> > > >> > > Also I guess one reason for the "groupId" to exist at all is to help >> > > ensuring uniqueness of artifact ids among the whole ecosystem, so that >> > > people not aware of each other don't step on each others toes.. but >> > > that's certainly questionable in our case as we can easily discuss >> > > naming of new modules among us. >> > > >> > > I just wonder if we're not going in opposite direction of usability >> > > for our own sake of selfish sense of organization. >> > > On the other end, maybe grouping them together will make it clearer to >> > > end users which artifacts need to use the same version? >> > > As ultimately, that's what is often unclear.. >> > > >> > > Thanks, >> > > Sanne >> > > >> > > On 5 October 2016 at 07:30, Max Rydahl Andersen >> > > wrote: >> > >> Won't this break like every existing example and 3rd party >> > >> integrations >> > >> (think Spring projects) maven and gradle builds on the planet >> > >> ? Or are hibernate 6 so radically different there is no chance you >> > >> would >> > >> just change the version number to have >> > >> builds work with both hibernate 5 and 6 ? >> > >> >> > >> Not saying it should not be done - just wondering if we grok the full >> > >> impact >> > >> for users. >> > >> >> > >> /max >> > >> >> > >> >> > >>> No concerns. >> > >>> When talking about this with Steve I also added it to our next >> > >>> meeting >> > >>> agenda, however it looks like we're all onboard so maybe there isn't >> > >>> much to debate :) >> > >>> >> > >>> On 4 October 2016 at 19:19, Gunnar Morling >> > >>> wrote: >> > >>>> >> > >>>> Hi, >> > >>>> >> > >>>> I just stumbled across HHH-11153 ("Rename published groupId from >> > >>>> org.hibernate to org.hibernate.orm"), scheduled for ORM >> > >>>> 6.0.0.Alpha1. >> > >>>> >> > >>>> I think that's a great idea and would suggest we do the same for >> > >>>> Hibernate >> > >>>> Validator and Search in their respective 6.0 releases: >> > >>>> org.hibernate.validator and org.hibernate.search (for OGM we used >> > >>>> org.hibernate.ogm from the beginning). >> > >>>> >> > >>>> Any concerns? >> > >>>> >> > >>>> --Gunnar >> > >>>> _______________________________________________ >> > >>>> 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 >> > >> >> > >> >> > >> >> > >> /max >> > >> http://about.me/maxandersen >> > >> > >> > /max >> > http://about.me/maxandersen >> > >> > _______________________________________________ >> > 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 Thu Oct 6 10:41:00 2016 From: andrea at hibernate.org (andrea boriero) Date: Thu, 6 Oct 2016 16:41:00 +0200 Subject: [hibernate-dev] SQM - encoding type info into the tree In-Reply-To: References: Message-ID: I'm inclined towards the second option but not sure if it can have limitations compared to the first one. On 5 October 2016 at 22:59, Steve Ebersole wrote: > In SQM's domain metamodel we decided to follow JPA's guidelines in terms > of javax.persistence.metamodel.Metamodel. That is to say... a Type in SQM > describes a Java type not its database mapping, just as it is in JPA. > > As a concrete example of the difference and its implication, consider a > Boolean attribute. The Type for that attribute would be > a BasicType which only describes the Java Boolean type; it > contains no information about how that value is mapped to the database (aka > it is not a "mapping type"). But this mapping information is important. > It is simply not enough to know that the value is a Boolean, we have to > know that it is "a Boolean mapped to a BIT" or "a Boolean mapped to a > CHAR(1)" etc. > > As we are building the SQM, we ask the "consumer" (ORM, etc) to resolve > domain metamodel info for us. The ideal being that as as we build the SQM > tree in SQM we could encode "mapping type" information from the consumer > into the tree structure. But the problem is how to define access to a > "mapped type system" when SQM's type system is strictly domain-based. > > Where this really becomes problematic is when determining the "implicit > type" for Expression nodes in the tree. Consider an example... > > {code} > from Person p where p.active = ?1 > {code} > > The idea is that we really want to be able to infer the type of the "?1" > parameter expression based on its context in the query. Since it is used > as an operand of a equality predicate we know that its type should be the > same as the other operand, here: "p.active". > > But this is where the domain-type/mapping-type split comes into play. At > the SQM level we have no notion of a "mapping type", so the fact that > "p.active" is "a Boolean mapped to a BIT" or "a Boolean mapped to a > CHAR(1)", which is really the information we want associated with the param > expression. All we can know from the SQM side is that "p.active" is a > BasicType and therefore "?1" should be to - but that is not enough > contextual info to handle binding that param properly. > > I see a few options to address this: > > 1. Add a notion of "mapping type" to SQM's domain metamodel. The > "mapping type" would not be ORM-specific (aka, no expectation of JDBC). > Think of it more as a momento (pattern). This effectively creates a > complete parallel of ORM's type system though, which always feels like a > code smell to me. > 2. Simply leave determination of an expression's "implicit type" out of > SQM. Resolving an expression's implicit type based on Type as defined > by > JPA and currently by SQM is simply not expressive enough to be of any > value. As the SQM consumer processes the SQM tree it would make that > determination then. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Oct 6 13:19:34 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 06 Oct 2016 17:19:34 +0000 Subject: [hibernate-dev] SQM - encoding type info into the tree In-Reply-To: References: Message-ID: Well there is then the ideological argument about this being a *semantic* query tree. I'd argue that resolving non-explicit types is part of that process. But if the semantic interpretation does not understand that more contextual type system, then there is not really much to do. I don't think we lose anything. We'd just do it later. On Thu, Oct 6, 2016 at 9:41 AM andrea boriero wrote: > I'm inclined towards the second option but not sure if it can have > limitations compared to the first one. > > On 5 October 2016 at 22:59, Steve Ebersole wrote: > > In SQM's domain metamodel we decided to follow JPA's guidelines in terms > of javax.persistence.metamodel.Metamodel. That is to say... a Type in SQM > describes a Java type not its database mapping, just as it is in JPA. > > As a concrete example of the difference and its implication, consider a > Boolean attribute. The Type for that attribute would be > a BasicType which only describes the Java Boolean type; it > contains no information about how that value is mapped to the database (aka > it is not a "mapping type"). But this mapping information is important. > It is simply not enough to know that the value is a Boolean, we have to > know that it is "a Boolean mapped to a BIT" or "a Boolean mapped to a > CHAR(1)" etc. > > As we are building the SQM, we ask the "consumer" (ORM, etc) to resolve > domain metamodel info for us. The ideal being that as as we build the SQM > tree in SQM we could encode "mapping type" information from the consumer > into the tree structure. But the problem is how to define access to a > "mapped type system" when SQM's type system is strictly domain-based. > > Where this really becomes problematic is when determining the "implicit > type" for Expression nodes in the tree. Consider an example... > > {code} > from Person p where p.active = ?1 > {code} > > The idea is that we really want to be able to infer the type of the "?1" > parameter expression based on its context in the query. Since it is used > as an operand of a equality predicate we know that its type should be the > same as the other operand, here: "p.active". > > But this is where the domain-type/mapping-type split comes into play. At > the SQM level we have no notion of a "mapping type", so the fact that > "p.active" is "a Boolean mapped to a BIT" or "a Boolean mapped to a > CHAR(1)", which is really the information we want associated with the param > expression. All we can know from the SQM side is that "p.active" is a > BasicType and therefore "?1" should be to - but that is not enough > contextual info to handle binding that param properly. > > I see a few options to address this: > > 1. Add a notion of "mapping type" to SQM's domain metamodel. The > > > "mapping type" would not be ORM-specific (aka, no expectation of JDBC). > Think of it more as a momento (pattern). This effectively creates a > complete parallel of ORM's type system though, which always feels like a > code smell to me. > > 2. Simply leave determination of an expression's "implicit type" out of > > > SQM. Resolving an expression's implicit type based on Type as defined > by > JPA and currently by SQM is simply not expressive enough to be of any > value. As the SQM consumer processes the SQM tree it would make that > determination then. > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From sanne at hibernate.org Thu Oct 6 16:38:25 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 6 Oct 2016 21:38:25 +0100 Subject: [hibernate-dev] Hibernate Search: Triple release! Message-ID: Hello all, today we published three releases of Hibernate Search: - 5.5.5.Final - 5.6.0.Beta3 - 5.7.0.Alpha1 For more information and an explanation please see our blog: - http://in.relation.to/2016/10/06/TripleHibernateSearchRelease/ Thanks, Sanne From rapidtransit440 at aol.com Sat Oct 8 14:25:19 2016 From: rapidtransit440 at aol.com (rapidtransit440 at aol.com) Date: Sat, 8 Oct 2016 14:25:19 -0400 Subject: [hibernate-dev] i18n, Anyone have any pointers? Message-ID: <157a58acd49-62b-3d86@webprd-a22.mail.aol.com> Through my travels, I've had to implement some services with Hibernate, so I thought I would like to join the line of people who thinks they can actually get a translation module working. My course so far is mostly copy pasta and make some modifications to InflightMetadataImpl and then DenormalizedTable, and then look at how @DiscrimnatorColumn is read and its meta data is produced, I'm assuming it is a SyntheticProperty? For right now I just want to make sure there isn't going to be a huge change upcoming in any part of the bootstrap process. Also I have only thought up until the bootstrap process, and if anyone can give me some advice what I should look into next would be appreciated. From zerg2k at yahoo.com Sun Oct 9 23:19:00 2016 From: zerg2k at yahoo.com (Noel) Date: Sun, 9 Oct 2016 23:19:00 -0400 Subject: [hibernate-dev] HBM migration suggestions Message-ID: <9B8DBCB1-52D1-4D63-B3E2-751D973521E1@yahoo.com> Hi guys, We have 200-ish hbm files we would like to convert to annotated classes. Is there any tool you guys recommend to tackle such a project ? Thanks in advance for your time, Noel From manderse at redhat.com Mon Oct 10 07:58:45 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Mon, 10 Oct 2016 13:58:45 +0200 Subject: [hibernate-dev] HBM migration suggestions In-Reply-To: <9B8DBCB1-52D1-4D63-B3E2-751D973521E1@yahoo.com> References: <9B8DBCB1-52D1-4D63-B3E2-751D973521E1@yahoo.com> Message-ID: <841B690F-7339-4148-9D6D-6655DA0E5472@redhat.com> hibernate tools can do it for the basic cases - but it haven't been updated in a long while, but you can customise the templates if you find issues. /max > Hi guys, > We have 200-ish hbm files we would like to convert to annotated > classes. Is there any tool you guys recommend to tackle such a project > ? > > Thanks in advance for your time, > > Noel > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev /max http://about.me/maxandersen From sanne at hibernate.org Mon Oct 10 09:24:22 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 10 Oct 2016 14:24:22 +0100 Subject: [hibernate-dev] HBM migration suggestions In-Reply-To: <841B690F-7339-4148-9D6D-6655DA0E5472@redhat.com> References: <9B8DBCB1-52D1-4D63-B3E2-751D973521E1@yahoo.com> <841B690F-7339-4148-9D6D-6655DA0E5472@redhat.com> Message-ID: I remember needing something like that and did it by having the legacy app create the schema in the RDBMs, then use reverse engineering to pojos. This was during the "Seam 2 era" so quite some time ago.. not sure how tools evolved since then. You'll need some manual tuning during both steps of course, but since I could tune & extend both the naming strategies (via code extensions) and the template files we got a quite complex application (600+ entities) converted in a couple of days. AFAIR my best learner lesson was to be ready to repeat it all (script it) multiple times, to prefer tune the templates and naming strategies iteratively over fixing things by hand. On 10 October 2016 at 12:58, Max Rydahl Andersen wrote: > hibernate tools can do it for the basic cases - but it haven't been > updated in a long while, but you can customise the templates if you find > issues. > > /max > >> Hi guys, >> We have 200-ish hbm files we would like to convert to annotated >> classes. Is there any tool you guys recommend to tackle such a project >> ? >> >> Thanks in advance for your time, >> >> Noel >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > /max > http://about.me/maxandersen > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Mon Oct 10 09:56:22 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 10 Oct 2016 13:56:22 +0000 Subject: [hibernate-dev] HBM migration suggestions In-Reply-To: References: <9B8DBCB1-52D1-4D63-B3E2-751D973521E1@yahoo.com> <841B690F-7339-4148-9D6D-6655DA0E5472@redhat.com> Message-ID: Do you have a tool to convert from orm.xml to annotations? The reason I ask is that we are pretty far along in the development of a hbm.xml -> orm.xml tool, with the caveat that the orm.xml is an "extended" form of the JPA orm.xml weaving in Hibernate-specifics. So it would depend on whether any hbm-specific features are used (property-ref being the biggest problem). That tool with be completed as part of 7.0, but like I said it is already pretty far along. On Mon, Oct 10, 2016 at 8:27 AM Sanne Grinovero wrote: > I remember needing something like that and did it by having the legacy > app create the schema in the RDBMs, then use reverse engineering to > pojos. This was during the "Seam 2 era" so quite some time ago.. not > sure how tools evolved since then. > > You'll need some manual tuning during both steps of course, but since > I could tune & extend both the naming strategies (via code extensions) > and the template files we got a quite complex application (600+ > entities) converted in a couple of days. AFAIR my best learner lesson > was to be ready to repeat it all (script it) multiple times, to prefer > tune the templates and naming strategies iteratively over fixing > things by hand. > > > > On 10 October 2016 at 12:58, Max Rydahl Andersen > wrote: > > hibernate tools can do it for the basic cases - but it haven't been > > updated in a long while, but you can customise the templates if you find > > issues. > > > > /max > > > >> Hi guys, > >> We have 200-ish hbm files we would like to convert to annotated > >> classes. Is there any tool you guys recommend to tackle such a project > >> ? > >> > >> Thanks in advance for your time, > >> > >> Noel > >> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > /max > > http://about.me/maxandersen > > _______________________________________________ > > 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 daltodavide at gmail.com Mon Oct 10 10:35:15 2016 From: daltodavide at gmail.com (Davide D'Alto) Date: Mon, 10 Oct 2016 15:35:15 +0100 Subject: [hibernate-dev] Hibernate OGM double release! Message-ID: Good news! We released Hibernate OGM 5.1 Alpha1 and 5.0.2 Final! Hibernate OGM 5.0.2.Final now supports MongoDB 3.2 and it?s still backward compatible with Hibernate OGM 5.0.1.Final. Hibernate OGM 5.1.0.Alpha1 brings support for Neo4 in remote mode. We also started to re-work the way Hibernate OGM groups operations before running them; this reduce the number of calls and commands to execute on the datastore, leading to better performance. You can find more about these releases and how to get them in the blog post: http://in.relation.to/2016/10/10/hibernate-ogm-5-1-alpha-and-5-0-2-released/ Thanks, Davide From manderse at redhat.com Mon Oct 10 11:36:01 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Mon, 10 Oct 2016 17:36:01 +0200 Subject: [hibernate-dev] HBM migration suggestions In-Reply-To: References: <9B8DBCB1-52D1-4D63-B3E2-751D973521E1@yahoo.com> <841B690F-7339-4148-9D6D-6655DA0E5472@redhat.com> Message-ID: <7F036A89-8A42-417C-8B36-770A059693EF@redhat.com> On 10 Oct 2016, at 15:24, Sanne Grinovero wrote: > I remember needing something like that and did it by having the legacy > app create the schema in the RDBMs, then use reverse engineering to > pojos. This was during the "Seam 2 era" so quite some time ago.. not > sure how tools evolved since then. That was doing it wrong then ;) hibernate tools have since day one been able to read any hibernate config and generate another config from it. Thus generating to the db first would be unnecessary. The tools haven't moved much since then though :) > You'll need some manual tuning during both steps of course, but since > I could tune & extend both the naming strategies (via code extensions) > and the template files we got a quite complex application (600+ > entities) converted in a couple of days. AFAIR my best learner lesson > was to be ready to repeat it all (script it) multiple times, to prefer > tune the templates and naming strategies iteratively over fixing > things by hand. > > On 10 October 2016 at 12:58, Max Rydahl Andersen > wrote: >> hibernate tools can do it for the basic cases - but it haven't been >> updated in a long while, but you can customise the templates if you >> find >> issues. >> >> /max >> >>> Hi guys, >>> We have 200-ish hbm files we would like to convert to annotated >>> classes. Is there any tool you guys recommend to tackle such a >>> project >>> ? >>> >>> Thanks in advance for your time, >>> >>> Noel >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> /max >> http://about.me/maxandersen >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev /max http://about.me/maxandersen From guillaume.smet at hibernate.org Tue Oct 11 06:11:58 2016 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Tue, 11 Oct 2016 12:11:58 +0200 Subject: [hibernate-dev] Hibernate Validator 5.3.0.Final is out Message-ID: Hi, It's with great pleasure that I announce you the release of the final version of Hibernate Validator 5.3.0. There is a lot of activity on Hibernate Validator these days and we decided to bring to the users several enhancements and bugfixes while we are making progress towards Bean Validation 2.0 and Hibernate Validator 6. See the announcement post http://in.relation.to/2016/10/11/hibernate-validator-530-final-out/ for more information about the release! On a side note, if you are interested in defining the future of Bean Validation, please come join us working on BV 2.0 here: http://beanvalidation.org/. -- Guillaume From zerg2k at yahoo.com Tue Oct 11 19:23:57 2016 From: zerg2k at yahoo.com (Noel Diaz) Date: Tue, 11 Oct 2016 23:23:57 +0000 (UTC) Subject: [hibernate-dev] HBM migration suggestions In-Reply-To: References: <9B8DBCB1-52D1-4D63-B3E2-751D973521E1@yahoo.com> <841B690F-7339-4148-9D6D-6655DA0E5472@redhat.com> Message-ID: <1688397314.2213985.1476228237479@mail.yahoo.com> This is great Steve. Can I take at least a sneak-peek into the tool?? On Monday, October 10, 2016 9:56 AM, Steve Ebersole wrote: Do you have a tool to convert from orm.xml to annotations?? The reason I ask is that we are pretty far along in the development of a hbm.xml -> orm.xml tool, with the caveat that the orm.xml is an "extended" form of the JPA orm.xml weaving in Hibernate-specifics.? So it would depend on whether any hbm-specific features are used (property-ref being the biggest problem). That tool with be completed as part of 7.0, but like I said it is already pretty far along. On Mon, Oct 10, 2016 at 8:27 AM Sanne Grinovero wrote: I remember needing something like that and did it by having the legacy app create the schema in the RDBMs, then use reverse engineering to pojos. This was during the "Seam 2 era" so quite some time ago.. not sure how tools evolved since then. You'll need some manual tuning during both steps of course, but since I could tune & extend both the naming strategies (via code extensions) and the template files we got a quite complex application (600+ entities) converted in a couple of days.? AFAIR my best learner lesson was to be ready to repeat it all (script it) multiple times, to prefer tune the templates and naming strategies iteratively over fixing things by hand. On 10 October 2016 at 12:58, Max Rydahl Andersen wrote: > hibernate tools can do it for the basic cases - but it haven't been > updated in a long while, but you can customise the templates if you find > issues. > > /max > >> Hi guys, >> We have 200-ish hbm files we would like to convert to annotated >> classes. Is there any tool you guys recommend to tackle such a project >> ? >> >> Thanks in advance for your time, >> >> Noel >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > /max > http://about.me/maxandersen > _______________________________________________ > 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 Tue Oct 11 19:44:59 2016 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 11 Oct 2016 23:44:59 +0000 Subject: [hibernate-dev] HBM migration suggestions In-Reply-To: <1688397314.2213985.1476228237479@mail.yahoo.com> References: <9B8DBCB1-52D1-4D63-B3E2-751D973521E1@yahoo.com> <841B690F-7339-4148-9D6D-6655DA0E5472@redhat.com> <1688397314.2213985.1476228237479@mail.yahoo.com> Message-ID: With obvious disclaimers, ofc! :) https://github.com/sebersole/hibernate-core/tree/jandex-binding is the branch The specific "converter" is https://github.com/sebersole/hibernate-core/blob/jandex-binding/hibernate-core/src/main/java/org/hibernate/boot/model/source/internal/hbm/HbmXmlTransformer.java The plan for this in 7.0 is to be available at runtime as well as at build-time via Gradle/Ant/Maven plugins. But for now you'd have to call that HbmXmlTransformer yourself. On Tue, Oct 11, 2016 at 6:27 PM Noel Diaz wrote: > This is great Steve. Can I take at least a sneak-peek into the tool? > > > > On Monday, October 10, 2016 9:56 AM, Steve Ebersole > wrote: > > > Do you have a tool to convert from orm.xml to annotations? The reason I > ask is that we are pretty far along in the development of a hbm.xml -> > orm.xml tool, with the caveat that the orm.xml is an "extended" form of the > JPA orm.xml weaving in Hibernate-specifics. So it would depend on whether > any hbm-specific features are used (property-ref being the biggest problem). > > That tool with be completed as part of 7.0, but like I said it is already > pretty far along. > > > On Mon, Oct 10, 2016 at 8:27 AM Sanne Grinovero > wrote: > > I remember needing something like that and did it by having the legacy > app create the schema in the RDBMs, then use reverse engineering to > pojos. This was during the "Seam 2 era" so quite some time ago.. not > sure how tools evolved since then. > > You'll need some manual tuning during both steps of course, but since > I could tune & extend both the naming strategies (via code extensions) > and the template files we got a quite complex application (600+ > entities) converted in a couple of days. AFAIR my best learner lesson > was to be ready to repeat it all (script it) multiple times, to prefer > tune the templates and naming strategies iteratively over fixing > things by hand. > > > > On 10 October 2016 at 12:58, Max Rydahl Andersen > wrote: > > hibernate tools can do it for the basic cases - but it haven't been > > updated in a long while, but you can customise the templates if you find > > issues. > > > > /max > > > >> Hi guys, > >> We have 200-ish hbm files we would like to convert to annotated > >> classes. Is there any tool you guys recommend to tackle such a project > >> ? > >> > >> Thanks in advance for your time, > >> > >> Noel > >> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > /max > > http://about.me/maxandersen > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > From steve at hibernate.org Wed Oct 12 16:36:40 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 12 Oct 2016 20:36:40 +0000 Subject: [hibernate-dev] Adding a Byte Buddy byte code provider to Hibernate In-Reply-To: References: Message-ID: Since this is gaining some traction, I think we need to start deciding: 1. whether to have Byte Buddy *replace* Javassist, or to have it as an alternative impl 2. IIUC some of our issues could be alleviated by generating a Javassist shaded jar. Should we consider that for Byte Buddy out the gate? On Wed, Oct 12, 2016 at 3:36 PM Steve Ebersole wrote: > oops, guess this works better if I send it to the group ;) > > > On Wed, Oct 12, 2016 at 1:09 PM Steve Ebersole > wrote: > > Since this is gaining some traction, I think we need to start deciding: > > 1. whether to have Byte Buddy *replace* Javassist, or to have it as an > alternative impl > 2. IIUC some of our issues could be alleviated by generating a > Javassist shaded jar. Should we consider that for Byte Buddy out the gate? > > > On Tue, Oct 4, 2016 at 9:18 AM Steve Ebersole wrote: > > I created https://hibernate.atlassian.net/browse/HHH-11152 to track this > > On Mon, Oct 3, 2016 at 6:55 AM Steve Ebersole wrote: > > I'd also like to revisit the BytecodeProvider contracts. I wrote those > really to fit CGLIB and Javassist and our legacy code around CGLIB > specifically. But I'd like to revamp that to be more logical. So feel > free to suggest any edits to the SPI that you feel make sense. > > We should also decide if we want to support both, or just move to > ByteBuddy. If we support both, we will not be able to leverage things > that ByteBuddy can do that Javassist cant (like you mention annotation > retention). Personally I think we should just pick one and go with it. > I can't imagine users generally care. However I do think the SPI still has > merit as it makes it easier to experiment with alternatives/replacements > later (as it made it easier for you here). > > > On Mon, Oct 3, 2016, 6:43 AM Rafael Winterhalter > wrote: > > Hi Steve, > > it is great to hear you are interested! By "proof of concept" I mean that > I have not yet put much effort into it as I did not know if this was an > option at all. I only wrote a very general implementation without testing > it to see if there is anything missing in Byte Buddy that Javassist is > offering and that you relied upon. Byte Buddy makes a few things different > when it comes to manipulating existing code but this is not in the scope of > what Hibernate is currently using Javassist for. > > I am more than happy to write a real BytecodeProvider using Byte Buddy. In > a first step, I would simply mimic the current Javassist provider. In a > later step, I would then try to apply a few optimizations to make the > interceptor a bit more lean; this would benefit performance due to on > inlining size and make it easier to debug. At this stage, we can also look > into a few features that Javassist does not offer as for example annotation > retention. > > I try to find some time in the next two or three weeks and get back with a > prototype. > > Best regards, Rafael > > 2016-10-02 2:23 GMT+02:00 Steve Ebersole : > > That's awesome that you were able to code something up Rafael. I will set > aside some time next week to look this over. > > When you say "proof of concept" I am curious how complete you feel this > is. You mentioned not dealing with the fast-class stuff, which is ok by me > - as you say, this is not so much an issue anymore as it was back in JDK > 1.4 :) More I mean in terms of both proxy generation support and bytecode > enhancement. In regards to those 2, how complete do you feel this work is? > > And again, thanks for taking this on. This is something I have wanted to > look at, but just could never find the time. Glad someone took this on. > > > On Sat, Oct 1, 2016 at 10:25 AM Rafael Winterhalter > wrote: > > Hello everybody, > > I was wondering how big the chances are to get a Byte Buddy bytecode > provider into Hibernate? Byte Buddy has matured a lot over the last two > years and it aims a lot on performance what is something Hibernate could > benefit of. There are comparion charts posted on the Byte Buddy webpage. As > a bonus, Byte Buddy is already ready for Java 9 and gives a lot of features > for free, for example generic meta data retention and a possibility to > retain annotations on subclassed types and overridden methods. > > I have written a simple proof of concept here: > https://github.com/raphw/hibernate-bb without having tested it - I did not > implement the fast class providers as I have learned after a lot of > benchmarking that those do not improve performance on Java 8+ VMs anymore. > Using such fast-classing rather pollutes the code cache than bring any > benefit. The only advantage with code generation in this field comes when > avoiding boxing what is not the case. But of course, I can implement > something in Byte Buddy to apply such a fast-class mechanism. > > Let me know what you think. I am more then happy to help you with > implementing such a provider. Other frameworks such as Mockito already use > Byte Buddy on a large scale and made good experiences with it. > > Best regards, Rafael > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > From coladict at gmail.com Thu Oct 13 08:52:46 2016 From: coladict at gmail.com (Jordan Gigov) Date: Thu, 13 Oct 2016 15:52:46 +0300 Subject: [hibernate-dev] Array datatypes optional module Message-ID: The feature is now ready for review. JIRA issue HHH-10999, Pull request #1499 It is not 5.1-compatible, because it requires the Session object to be passed as the WrapperOptions. One test fails due to bug in core: HHH-11171. I'm guessing a lot of type descriptors would fail those tests as well. They've only been presumed to work so far. From postmaster at lists.jboss.org Fri Oct 14 13:10:04 2016 From: postmaster at lists.jboss.org (The Post Office) Date: Sat, 15 Oct 2016 01:10:04 +0800 Subject: [hibernate-dev] (no subject) Message-ID: <201610141710.u9EHA8Q5024403@lists01.dmz-a.mwc.hst.phx2.redhat.com> From davide at hibernate.org Wed Oct 19 05:17:51 2016 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 19 Oct 2016 10:17:51 +0100 Subject: [hibernate-dev] [OGM] Neo4j integration dependencies Message-ID: The integration with Neo4j in OGM makes it possible for a user to select the strategy that he wants to use to connect to an embedded or remote Neo4j instance. There are 3 possible options: 1) Embedded mode, Neo4j run in the same JVM 2) Remote via HTTP interface using RestEasy 3) Remote via the Bolt protocol using the neo4j-java-driver library Everything is now in one single artifact meaning that for each case we have more dependencies than needed, in particular for the remote cases. Possible solutions I can think of at the moment are: 1) Have different maven artifacts: - We could have 3 artifacts: EMBEDDED, HTTP and BOLT - or 2 artifacts: EMBEDDED and REMOTE: This won't completely solve the issue because w would still have resteasy (for HTTP) and neo4j-java-driver (for BOLT) but it might be a good trade-off We will need to share some resource so this approach might require a Neo4j common library. 2) Make some dependencies optional (Need to test this, but it might work) 3) Use some maven plugin to generate different artifacts from the same module. I haven't used this approach before so I'm not sure if it is feasible. 4) ??? Any opinion about this? Issue on JIRA: https://hibernate.atlassian.net/browse/OGM-1190 Thanks, Davide From yoann at hibernate.org Wed Oct 19 05:44:51 2016 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 19 Oct 2016 11:44:51 +0200 Subject: [hibernate-dev] [OGM] Neo4j integration dependencies In-Reply-To: References: Message-ID: Is there any particular reason why we would not want to create three artifacts, besides backward compatibility? It seems the obvious and ideal solution, but I might be missing something. If there is common code, we can always create a fourth -neo4j-core artifact that would have no interest to users but would simply ensure we don't duplicate code, and would be delivered through transitive dependencies. About backward compatibility, I guess there are two options: - If the last released version of the artifact used to contain only the embedded mode, we can use maven relocation - Otherwise, we can advertise this artifact as deprecated, remove almost everything in it and add the relevant new artifacts as dependencies. Or am I being too naive? Yoann Rodi?re Hibernate NoORM Team On 19 October 2016 at 11:17, Davide D'Alto wrote: > The integration with Neo4j in OGM makes it possible for a user to > select the strategy that he wants to use to connect to an embedded or > remote Neo4j instance. > There are 3 possible options: > 1) Embedded mode, Neo4j run in the same JVM > 2) Remote via HTTP interface using RestEasy > 3) Remote via the Bolt protocol using the neo4j-java-driver library > > Everything is now in one single artifact meaning that for each case we > have more dependencies than needed, in particular for the remote > cases. > > Possible solutions I can think of at the moment are: > > 1) Have different maven artifacts: > - We could have 3 artifacts: EMBEDDED, HTTP and BOLT > - or 2 artifacts: EMBEDDED and REMOTE: This won't completely solve > the issue because w would still have > resteasy (for HTTP) and neo4j-java-driver (for BOLT) but it > might be a good trade-off > > We will need to share some resource so this approach might require > a Neo4j common library. > > 2) Make some dependencies optional (Need to test this, but it might work) > > 3) Use some maven plugin to generate different artifacts from the same > module. I haven't used this approach before so I'm not sure if it is > feasible. > > 4) ??? > > Any opinion about this? > > Issue on JIRA: https://hibernate.atlassian.net/browse/OGM-1190 > > Thanks, > Davide > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Oct 19 05:58:03 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 19 Oct 2016 10:58:03 +0100 Subject: [hibernate-dev] [OGM] Neo4j integration dependencies In-Reply-To: References: Message-ID: I would prefer to see these modules split as 3 different Maven modules, but I wouldn't personally consider such work a priority. Splitting them up would make for "lighter" fragments for e.g. Swarm, but at the cost of a couple more paragraphs of documentation which needs to be understood (more complex). So I dislike the 2-modules tradeoff as users would be faced with the additional configuration complexity, yet they would only get a half-baked reward in exchange for it. If you find some "interesting" Maven plugin which allows some kind of build-time reorganization of these dependencies then please make sure that we actually test the consumption of the output maven definitions. In other words, I'd avoid that! Thanks, Sanne On 19 October 2016 at 10:17, Davide D'Alto wrote: > The integration with Neo4j in OGM makes it possible for a user to > select the strategy that he wants to use to connect to an embedded or > remote Neo4j instance. > There are 3 possible options: > 1) Embedded mode, Neo4j run in the same JVM > 2) Remote via HTTP interface using RestEasy > 3) Remote via the Bolt protocol using the neo4j-java-driver library > > Everything is now in one single artifact meaning that for each case we > have more dependencies than needed, in particular for the remote > cases. > > Possible solutions I can think of at the moment are: > > 1) Have different maven artifacts: > - We could have 3 artifacts: EMBEDDED, HTTP and BOLT > - or 2 artifacts: EMBEDDED and REMOTE: This won't completely solve > the issue because w would still have > resteasy (for HTTP) and neo4j-java-driver (for BOLT) but it > might be a good trade-off > > We will need to share some resource so this approach might require > a Neo4j common library. > > 2) Make some dependencies optional (Need to test this, but it might work) > > 3) Use some maven plugin to generate different artifacts from the same > module. I haven't used this approach before so I'm not sure if it is > feasible. > > 4) ??? > > Any opinion about this? > > Issue on JIRA: https://hibernate.atlassian.net/browse/OGM-1190 > > Thanks, > Davide > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Wed Oct 19 05:59:44 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 19 Oct 2016 10:59:44 +0100 Subject: [hibernate-dev] [OGM] Neo4j integration dependencies In-Reply-To: References: Message-ID: On 19 October 2016 at 10:44, Yoann Rodiere wrote: > Is there any particular reason why we would not want to create three > artifacts, besides backward compatibility? It seems the obvious and ideal > solution, but I might be missing something. > > If there is common code, we can always create a fourth -neo4j-core artifact > that would have no interest to users but would simply ensure we don't > duplicate code, and would be delivered through transitive dependencies. > > About backward compatibility, I guess there are two options: > > - If the last released version of the artifact used to contain only the > embedded mode, we can use maven relocation > - Otherwise, we can advertise this artifact as deprecated, remove almost > everything in it and add the relevant new artifacts as dependencies. > > Or am I being too naive? Seems very reasonable. Maybe I'm naive too :) -- Sanne > > Yoann Rodi?re > Hibernate NoORM Team > > On 19 October 2016 at 11:17, Davide D'Alto wrote: > >> The integration with Neo4j in OGM makes it possible for a user to >> select the strategy that he wants to use to connect to an embedded or >> remote Neo4j instance. >> There are 3 possible options: >> 1) Embedded mode, Neo4j run in the same JVM >> 2) Remote via HTTP interface using RestEasy >> 3) Remote via the Bolt protocol using the neo4j-java-driver library >> >> Everything is now in one single artifact meaning that for each case we >> have more dependencies than needed, in particular for the remote >> cases. >> >> Possible solutions I can think of at the moment are: >> >> 1) Have different maven artifacts: >> - We could have 3 artifacts: EMBEDDED, HTTP and BOLT >> - or 2 artifacts: EMBEDDED and REMOTE: This won't completely solve >> the issue because w would still have >> resteasy (for HTTP) and neo4j-java-driver (for BOLT) but it >> might be a good trade-off >> >> We will need to share some resource so this approach might require >> a Neo4j common library. >> >> 2) Make some dependencies optional (Need to test this, but it might work) >> >> 3) Use some maven plugin to generate different artifacts from the same >> module. I haven't used this approach before so I'm not sure if it is >> feasible. >> >> 4) ??? >> >> Any opinion about this? >> >> Issue on JIRA: https://hibernate.atlassian.net/browse/OGM-1190 >> >> Thanks, >> Davide >> _______________________________________________ >> 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 davide at hibernate.org Wed Oct 19 06:08:17 2016 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 19 Oct 2016 11:08:17 +0100 Subject: [hibernate-dev] [OGM] Neo4j integration dependencies In-Reply-To: References: Message-ID: Splitting in 3 modules sounds good to me. I was sure in past there was some opposition about having additional modules. I might have imagined it On Wed, Oct 19, 2016 at 10:59 AM, Sanne Grinovero wrote: > On 19 October 2016 at 10:44, Yoann Rodiere wrote: >> Is there any particular reason why we would not want to create three >> artifacts, besides backward compatibility? It seems the obvious and ideal >> solution, but I might be missing something. >> >> If there is common code, we can always create a fourth -neo4j-core artifact >> that would have no interest to users but would simply ensure we don't >> duplicate code, and would be delivered through transitive dependencies. >> >> About backward compatibility, I guess there are two options: >> >> - If the last released version of the artifact used to contain only the >> embedded mode, we can use maven relocation >> - Otherwise, we can advertise this artifact as deprecated, remove almost >> everything in it and add the relevant new artifacts as dependencies. >> >> Or am I being too naive? > > Seems very reasonable. Maybe I'm naive too :) > > -- Sanne > >> >> Yoann Rodi?re >> Hibernate NoORM Team >> >> On 19 October 2016 at 11:17, Davide D'Alto wrote: >> >>> The integration with Neo4j in OGM makes it possible for a user to >>> select the strategy that he wants to use to connect to an embedded or >>> remote Neo4j instance. >>> There are 3 possible options: >>> 1) Embedded mode, Neo4j run in the same JVM >>> 2) Remote via HTTP interface using RestEasy >>> 3) Remote via the Bolt protocol using the neo4j-java-driver library >>> >>> Everything is now in one single artifact meaning that for each case we >>> have more dependencies than needed, in particular for the remote >>> cases. >>> >>> Possible solutions I can think of at the moment are: >>> >>> 1) Have different maven artifacts: >>> - We could have 3 artifacts: EMBEDDED, HTTP and BOLT >>> - or 2 artifacts: EMBEDDED and REMOTE: This won't completely solve >>> the issue because w would still have >>> resteasy (for HTTP) and neo4j-java-driver (for BOLT) but it >>> might be a good trade-off >>> >>> We will need to share some resource so this approach might require >>> a Neo4j common library. >>> >>> 2) Make some dependencies optional (Need to test this, but it might work) >>> >>> 3) Use some maven plugin to generate different artifacts from the same >>> module. I haven't used this approach before so I'm not sure if it is >>> feasible. >>> >>> 4) ??? >>> >>> Any opinion about this? >>> >>> Issue on JIRA: https://hibernate.atlassian.net/browse/OGM-1190 >>> >>> Thanks, >>> Davide >>> _______________________________________________ >>> 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 coladict at gmail.com Wed Oct 19 15:28:38 2016 From: coladict at gmail.com (Jordan Gigov) Date: Wed, 19 Oct 2016 22:28:38 +0300 Subject: [hibernate-dev] 6.0 - Type redesign Message-ID: I've been reading the wiki and email archives, and I have some notes for what needs to be decided before it needs to become retrofitted. After all, all that retrofitting is what the reason the types need to be redesigned. LiteralType.objectToSQLString is only used to append the DiscriminatorValue. Can't it just work with regular binding to the PreparedStatement so the unsafe interface can be removed? A type should be able to define classes Interfaces and Abstract classes that it can handle in their Java types. This will enable implementing handlers for things like javax.script.* objects that can have different providers, thus different class names of the final object. That would have to be a secondary check if no match is found by Java class name, because it's slower and dangerous when binding parameters to a query. If stored as Class object references, they would have to be held in WeakReference objects tied to a ReferenceQueue, so as not to prevent garbage collection when a context is unloaded in a multi-context server. If stored as Strings, there would have to be a call to Class.forName for each, which if successful would have to check isInstance on the object or isAssignableFrom on it's class (when evaluating DB model). There are currently no notes on how to handle binding the values to a PreparedStatement/CallableStatement. There is also no mention of how java.sql.SQLType that was added in Java 8 comes into play, which will help with vendor-specific types. When converting the new types to a bindable object they will need access to the Dialect and these methods of the java.sql.Connection: createArrayOf createBlob createClob createNClob createSQLXML createStruct getClientInfo getMetaData which returns DatabaseMetaData which can give access to the java.sql.Connection if we're trying to abstract away from it. Maybe also to: setClientInfo getWarnings when reading results from the database getTypeMap setTypeMap On Thu Jul 21 15:27:49 EDT 2016 Steve Ebersole wrote: > I know we could get around this by splitting (or keeping split) the notions > of ORM Type and JPA Type, but I would like to avoid that : this unification > is going to be important to the SQM Criteria support. Reading the description of javax.persistence.metamodel.Type, I'm not sure it serves the same purpose as Hibernate's Type and that it should be a super-interface of it. In fact, starting to read the Metamodel API chapter where these interfaces are defined, I'm fairly certain it's supposed to reflect the structure of the persistence unit. In other words, I don't think javax.persistence.metamodel.Type fits anywhere in this picture and it's a different concept altogether. As for OGM (which I've never used, but here's an idea) the problem with SqlTypeDescriptor (discussed in end of June, as I read the mail archives) maybe could be turned into an extension of a more generic StorageTypeDescriptor, and SQL would be just one type of storage? I don't know how that would work, since I've never had to use NoSQL and don't even know if that makes sense. Maybe the persistence context should provide the binders/extractors to each type upon use. From steve at hibernate.org Thu Oct 20 14:27:07 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 20 Oct 2016 18:27:07 +0000 Subject: [hibernate-dev] 6.0 - Type redesign In-Reply-To: References: Message-ID: On Wed, Oct 19, 2016 at 2:29 PM Jordan Gigov wrote: > I've been reading the wiki and email archives, and I have some notes > for what needs to be decided before it needs to become retrofitted. > After all, all that retrofitting is what the reason the types need to > be redesigned. > > LiteralType.objectToSQLString is only used to append the > DiscriminatorValue. > Can't it just work with regular binding to the PreparedStatement so > the unsafe interface can be removed? > LiteralType will not be part of the new contracts. A type should be able to define classes Interfaces and Abstract > classes that it can handle in their Java types. > This will enable implementing handlers for things like javax.script.* > objects that can have different providers, thus different class names > of the final object. > That would have to be a secondary check if no match is found by Java > class name, because it's slower and dangerous when binding > parameters to a query. > I am not sure what you are talking about here. If stored as Class object references, they would have to be held in > WeakReference objects tied to a ReferenceQueue, so as not to > prevent garbage collection when a context is unloaded in a multi-context > server. > > If stored as Strings, there would have to be a call to Class.forName > for each, which if successful would have to check isInstance on the > object or isAssignableFrom on it's class (when evaluating DB model). > Again, not really sure what you are talking about here. I guess you mean in some "cache" based on the Java type handled? And, generally speaking Hibernate never requires Java types for its type system because Hibernate supports detyped domain models; the one outlier there is any type deemed to be "basic" - those do require Java type. > There are currently no notes on how to handle binding the values to a > PreparedStatement/CallableStatement. > https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign#read-and-write-capabilities We just have not gotten to that point yet where that is better defined. > There is also no mention of how java.sql.SQLType that was added in > Java 8 comes into play, which will help with vendor-specific types. > There is currently not any plan to support java.sql.SQLType > When converting the new types to a bindable object they will need > access to the Dialect and these methods of the java.sql.Connection: > createArrayOf > createBlob > createClob > createNClob > createSQLXML > createStruct > getClientInfo > getMetaData which returns DatabaseMetaData which can give access to > the java.sql.Connection if we're trying to abstract away from it. > Statement also gives you access to the Connection (Statement#getConnection) > > Maybe also to: > setClientInfo > getWarnings when reading results from the database > getTypeMap > setTypeMap > > > Reading the description of javax.persistence.metamodel.Type, I'm not > sure it serves the same purpose as Hibernate's Type and that it should > be a super-interface of it. > In fact, starting to read the Metamodel API chapter where these > interfaces are defined, I'm fairly certain it's supposed to reflect > the structure of the persistence unit. > In other words, I don't think javax.persistence.metamodel.Type fits > anywhere in this picture and it's a different concept altogether. > As has been discussed elsewhere, that is correct. JPA's metamodel actually only describes the Java domain model. There is no database nor mapping information associated with it. JPA's type system is actually closer to Hibernate's JavaTypeDescriptor contract; not so much Hibernate's Type contract. Chris and Andrea are working on a prototype to see about having JavaTypeDescriptor implement the JPA type contracts. As for OGM (which I've never used, but here's an idea) the problem > with SqlTypeDescriptor (discussed in end of June, as I read the mail > archives) > maybe could be turned into an extension of a more generic > StorageTypeDescriptor, and SQL would be just one type of storage? I > don't know > how that would work, since I've never had to use NoSQL and don't even > know if that makes sense. > Maybe the persistence context should provide the binders/extractors to > each type upon use. > That wont work, because you'd also have to abstract the "database access". Anyway the only place I am concerned about that is in SQM and the type information it needs. I have already developed a proposed contract on the SQM side which I have already prototyped for ORM usage and is being evaluated for its appropriateness for OGM. So we shall see soon on that front. As far as the "mapping Type", I do not see a nice solution for ORM and OGM to share that I want to take on at this point. As I said above it would also mean abstracting access to the underlying data store (NoSQL and object stores do not exposed JDBC Connections, or if they do that is usually not the preferred/performant way to access them). This discussion is (waaaaaay) beyond the scope of this work. In general a lot of points are just out of date. If you want to influence the development of this or be part of it you should consider joining the HipChat channel where we discuss this stuff. I stopped trying to discuss here because no one generally answers. From steve at hibernate.org Thu Oct 20 14:34:45 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 20 Oct 2016 18:34:45 +0000 Subject: [hibernate-dev] SQM - encoding type info into the tree In-Reply-To: References: Message-ID: To follow up, there is now a proposal[1] and a prototype[2] (on the ORM side) for this. It essentially follows option (1). Davide is evaluating this atm for appropriateness for OGM. [1] https://github.com/hibernate/hibernate-semantic-query/tree/master/src/main/java/org/hibernate/sqm/domain [2] https://github.com/sebersole/hibernate-orm-sqm-poc/blob/master/src/main/java/org/hibernate/persister/common/internal/DomainMetamodelImpl.java On Thu, Oct 6, 2016 at 12:19 PM Steve Ebersole wrote: > Well there is then the ideological argument about this being a *semantic* > query tree. I'd argue that resolving non-explicit types is part of that > process. But if the semantic interpretation does not understand that more > contextual type system, then there is not really much to do. > > I don't think we lose anything. We'd just do it later. > > > > On Thu, Oct 6, 2016 at 9:41 AM andrea boriero > wrote: > > I'm inclined towards the second option but not sure if it can have > limitations compared to the first one. > > On 5 October 2016 at 22:59, Steve Ebersole wrote: > > In SQM's domain metamodel we decided to follow JPA's guidelines in terms > of javax.persistence.metamodel.Metamodel. That is to say... a Type in SQM > describes a Java type not its database mapping, just as it is in JPA. > > As a concrete example of the difference and its implication, consider a > Boolean attribute. The Type for that attribute would be > a BasicType which only describes the Java Boolean type; it > contains no information about how that value is mapped to the database (aka > it is not a "mapping type"). But this mapping information is important. > It is simply not enough to know that the value is a Boolean, we have to > know that it is "a Boolean mapped to a BIT" or "a Boolean mapped to a > CHAR(1)" etc. > > As we are building the SQM, we ask the "consumer" (ORM, etc) to resolve > domain metamodel info for us. The ideal being that as as we build the SQM > tree in SQM we could encode "mapping type" information from the consumer > into the tree structure. But the problem is how to define access to a > "mapped type system" when SQM's type system is strictly domain-based. > > Where this really becomes problematic is when determining the "implicit > type" for Expression nodes in the tree. Consider an example... > > {code} > from Person p where p.active = ?1 > {code} > > The idea is that we really want to be able to infer the type of the "?1" > parameter expression based on its context in the query. Since it is used > as an operand of a equality predicate we know that its type should be the > same as the other operand, here: "p.active". > > But this is where the domain-type/mapping-type split comes into play. At > the SQM level we have no notion of a "mapping type", so the fact that > "p.active" is "a Boolean mapped to a BIT" or "a Boolean mapped to a > CHAR(1)", which is really the information we want associated with the param > expression. All we can know from the SQM side is that "p.active" is a > BasicType and therefore "?1" should be to - but that is not enough > contextual info to handle binding that param properly. > > I see a few options to address this: > > 1. Add a notion of "mapping type" to SQM's domain metamodel. The > > > "mapping type" would not be ORM-specific (aka, no expectation of JDBC). > Think of it more as a momento (pattern). This effectively creates a > complete parallel of ORM's type system though, which always feels like a > code smell to me. > > 2. Simply leave determination of an expression's "implicit type" out of > > > SQM. Resolving an expression's implicit type based on Type as defined > by > JPA and currently by SQM is simply not expressive enough to be of any > value. As the SQM consumer processes the SQM tree it would make that > determination then. > > _______________________________________________ > 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 Oct 21 06:20:18 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 21 Oct 2016 12:20:18 +0200 Subject: [hibernate-dev] [OGM] Neo4j integration dependencies In-Reply-To: References: Message-ID: On Wed, Oct 19, 2016 at 11:59 AM, Sanne Grinovero wrote: > On 19 October 2016 at 10:44, Yoann Rodiere wrote: > > About backward compatibility, I guess there are two options: > > > > - If the last released version of the artifact used to contain only > the > > embedded mode, we can use maven relocation > > - Otherwise, we can advertise this artifact as deprecated, remove > almost > > everything in it and add the relevant new artifacts as dependencies. > > > > Or am I being too naive? > > Seems very reasonable. Maybe I'm naive too :) > Personally, as it does not sound like a good idea for users to keep the dependency on the aggregated dependency, I would simply break it and had a prominent note in the migration notes and in the release announcement. I think it's also a good way to advertise the new possibility of using Neo4j as remote and make the users choose the best solution for them. >From my experience maintaining applications for years, I always prefer to migrate early to the right solution when there is a compelling reason to do so and a clear logic in it. And +1 for the 3 different artifacts. -- Guillaume From yoann at hibernate.org Fri Oct 21 06:40:52 2016 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 21 Oct 2016 12:40:52 +0200 Subject: [hibernate-dev] [OGM] Neo4j integration dependencies In-Reply-To: References: Message-ID: On 21 October 2016 at 12:20, Guillaume Smet wrote: > I always prefer to migrate early to the right solution when there is a > compelling reason to do so and a clear logic in it. I totally agree with that, but I think it's more about what we promised to users than about what we think is the best practice they should follow. For APIs, we probably promised backward compatibility across minor versions. Even if we didn't explicitly promise this, doing otherwise would probably upset users. As to maven coordinates, that's kind of a grey area... I guess that, given users have to change their maven coordinates (the version) when upgrading anyway, the breaking artifact ID change may not be that bad. A bit surprising, but not really harmful. Yoann Rodi?re Hibernate NoORM Team From steve at hibernate.org Fri Oct 21 10:18:02 2016 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 21 Oct 2016 14:18:02 +0000 Subject: [hibernate-dev] 6.0 - Type redesign In-Reply-To: References: Message-ID: To be more clear... I just meant that to date we have not discussed any plans for supporting java.sql.SQLType, not that we discussed it and decided not to support it. On Thu, Oct 20, 2016 at 1:27 PM Steve Ebersole wrote: > On Wed, Oct 19, 2016 at 2:29 PM Jordan Gigov wrote: > > I've been reading the wiki and email archives, and I have some notes > for what needs to be decided before it needs to become retrofitted. > After all, all that retrofitting is what the reason the types need to > be redesigned. > > LiteralType.objectToSQLString is only used to append the > DiscriminatorValue. > Can't it just work with regular binding to the PreparedStatement so > the unsafe interface can be removed? > > > LiteralType will not be part of the new contracts. > > > A type should be able to define classes Interfaces and Abstract > classes that it can handle in their Java types. > This will enable implementing handlers for things like javax.script.* > objects that can have different providers, thus different class names > of the final object. > That would have to be a secondary check if no match is found by Java > class name, because it's slower and dangerous when binding > parameters to a query. > > > I am not sure what you are talking about here. > > > If stored as Class object references, they would have to be held in > WeakReference objects tied to a ReferenceQueue, so as not to > prevent garbage collection when a context is unloaded in a multi-context > server. > > If stored as Strings, there would have to be a call to Class.forName > for each, which if successful would have to check isInstance on the > object or isAssignableFrom on it's class (when evaluating DB model). > > > Again, not really sure what you are talking about here. I guess you mean > in some "cache" based on the Java type handled? > > And, generally speaking Hibernate never requires Java types for its type > system because Hibernate supports detyped domain models; the one outlier > there is any type deemed to be "basic" - those do require Java type. > > > > There are currently no notes on how to handle binding the values to a > PreparedStatement/CallableStatement. > > > > https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign#read-and-write-capabilities > > We just have not gotten to that point yet where that is better defined. > > > > There is also no mention of how java.sql.SQLType that was added in > Java 8 comes into play, which will help with vendor-specific types. > > > There is currently not any plan to support java.sql.SQLType > > > > When converting the new types to a bindable object they will need > access to the Dialect and these methods of the java.sql.Connection: > createArrayOf > createBlob > createClob > createNClob > createSQLXML > createStruct > getClientInfo > getMetaData which returns DatabaseMetaData which can give access to > the java.sql.Connection if we're trying to abstract away from it. > > > Statement also gives you access to the Connection (Statement#getConnection) > > > > Maybe also to: > setClientInfo > getWarnings when reading results from the database > getTypeMap > setTypeMap > > > Reading the description of javax.persistence.metamodel.Type, I'm not > sure it serves the same purpose as Hibernate's Type and that it should > be a super-interface of it. > In fact, starting to read the Metamodel API chapter where these > interfaces are defined, I'm fairly certain it's supposed to reflect > the structure of the persistence unit. > In other words, I don't think javax.persistence.metamodel.Type fits > anywhere in this picture and it's a different concept altogether. > > > As has been discussed elsewhere, that is correct. JPA's metamodel > actually only describes the Java domain model. There is no database nor > mapping information associated with it. JPA's type system is actually > closer to Hibernate's JavaTypeDescriptor contract; not so much Hibernate's > Type contract. Chris and Andrea are working on a prototype to see about > having JavaTypeDescriptor implement the JPA type contracts. > > > As for OGM (which I've never used, but here's an idea) the problem > with SqlTypeDescriptor (discussed in end of June, as I read the mail > archives) > maybe could be turned into an extension of a more generic > StorageTypeDescriptor, and SQL would be just one type of storage? I > don't know > how that would work, since I've never had to use NoSQL and don't even > know if that makes sense. > Maybe the persistence context should provide the binders/extractors to > each type upon use. > > > That wont work, because you'd also have to abstract the "database access". > > Anyway the only place I am concerned about that is in SQM and the type > information it needs. I have already developed a proposed contract on the > SQM side which I have already prototyped for ORM usage and is being > evaluated for its appropriateness for OGM. So we shall see soon on that > front. > > As far as the "mapping Type", I do not see a nice solution for ORM and OGM > to share that I want to take on at this point. As I said above it would > also mean abstracting access to the underlying data store (NoSQL and object > stores do not exposed JDBC Connections, or if they do that is usually not > the preferred/performant way to access them). This discussion is > (waaaaaay) beyond the scope of this work. > > In general a lot of points are just out of date. If you want to influence > the development of this or be part of it you should consider joining the > HipChat channel where we discuss this stuff. I stopped trying to discuss > here because no one generally answers. > > From gbadner at redhat.com Fri Oct 21 19:05:24 2016 From: gbadner at redhat.com (Gail Badner) Date: Fri, 21 Oct 2016 16:05:24 -0700 Subject: [hibernate-dev] Inadvertently pushed tags to hibernate-orm git repository Message-ID: Doh! I inadvertently pushed some Hibernate ORM tags used for EAP to the community server. I'm in the process of deleting them. Regards, Gail From steve at hibernate.org Mon Oct 24 15:19:43 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 24 Oct 2016 19:19:43 +0000 Subject: [hibernate-dev] dynamic instantiation queries Message-ID: Historically (well before JPA) HIbernate would handle dynamic instantiation queries in cases where one of the arguments being an entity-reference by passing just the entity's identifier rather than a complete reference to the entity. To be clear, I am talking about a query like: select new DTO( p ) from Person p Hibernate implicitly treats this like: select new DTO( p.id ) from Person p and expects DTO to have a ctor taking the appropriate ID type. JPA came along and also defines support for dynamic instantiation queries, but does not specify one way or the other how this case should be handled. I have been told other providers interpret this the opposite way. Makes sense. I think it is time we at least allow that as an option. Or maybe a nicer implementation that looks for both and picks the available one (if that's not too much effort). What do y'all think? From mihalcea.vlad at gmail.com Mon Oct 24 15:31:38 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 24 Oct 2016 22:31:38 +0300 Subject: [hibernate-dev] dynamic instantiation queries In-Reply-To: References: Message-ID: <580e61a5.832ec20a.d257f.6652@mx.google.com> Do you mean we should allow the dynamic instantiation to resolve entities when we pass the entity identifier? I think I saw this request on StackOverflow once. Did I understand the question properly? Vlad -----Original Message----- From: "Steve Ebersole" Sent: ?10/?24/?2016 22:21 To: "hibernate-dev" Subject: [hibernate-dev] dynamic instantiation queries Historically (well before JPA) HIbernate would handle dynamic instantiation queries in cases where one of the arguments being an entity-reference by passing just the entity's identifier rather than a complete reference to the entity. To be clear, I am talking about a query like: select new DTO( p ) from Person p Hibernate implicitly treats this like: select new DTO( p.id ) from Person p and expects DTO to have a ctor taking the appropriate ID type. JPA came along and also defines support for dynamic instantiation queries, but does not specify one way or the other how this case should be handled. I have been told other providers interpret this the opposite way. Makes sense. I think it is time we at least allow that as an option. Or maybe a nicer implementation that looks for both and picks the available one (if that's not too much effort). What do y'all think? _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Mon Oct 24 15:38:10 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 24 Oct 2016 19:38:10 +0000 Subject: [hibernate-dev] dynamic instantiation queries In-Reply-To: <580e61a5.832ec20a.d257f.6652@mx.google.com> References: <580e61a5.832ec20a.d257f.6652@mx.google.com> Message-ID: So Person is your entity, e.g.: @Entity class Person { @Id Long id; ... } For a query like `select new DTO( p ) from Person p` Hibernate expects a DTO like: class DTO { public DTO(Long id) { ... } } in fact a DTO like: class DTO { public DTO(Person person) { ... } } will not work with Hibernate. What I was proposing was for adding some support for that in 6.0 based on the SQM work. "Support" here could mean either: 1) add a flag that says whether to support legacy behavior, or this new behavior 2) attempt to dynamically infer what to do (looks at available ctors) (2) would be awesome I think. We'd still have to know how to handle cases where the "DTO" defined ctors matching both cases and which to prefer. On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea wrote: > Do you mean we should allow the dynamic instantiation to resolve entities > when we pass the entity identifier? > > I think I saw this request on StackOverflow once. > > Did I understand the question properly? > > Vlad > ------------------------------ > From: Steve Ebersole > Sent: ?10/?24/?2016 22:21 > To: hibernate-dev > Subject: [hibernate-dev] dynamic instantiation queries > > Historically (well before JPA) HIbernate would handle dynamic instantiation > queries in cases where one of the arguments being an entity-reference by > passing just the entity's identifier rather than a complete reference to > the entity. To be clear, I am talking about a query like: > > select new DTO( p ) from Person p > > Hibernate implicitly treats this like: > > select new DTO( p.id ) from Person p > > and expects DTO to have a ctor taking the appropriate ID type. > > JPA came along and also defines support for dynamic instantiation queries, > but does not specify one way or the other how this case should be handled. > I have been told other providers interpret this the opposite way. Makes > sense. I think it is time we at least allow that as an option. Or maybe a > nicer implementation that looks for both and picks the available one (if > that's not too much effort). > > What do y'all think? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From coladict at gmail.com Mon Oct 24 16:10:37 2016 From: coladict at gmail.com (Jordan Gigov) Date: Mon, 24 Oct 2016 23:10:37 +0300 Subject: [hibernate-dev] 6.0 - Type redesign In-Reply-To: References: Message-ID: 2016-10-20 21:27 GMT+03:00 Steve Ebersole : > >> A type should be able to define classes Interfaces and Abstract >> classes that it can handle in their Java types. >> This will enable implementing handlers for things like javax.script.* >> objects that can have different providers, thus different class names >> of the final object. >> That would have to be a secondary check if no match is found by Java >> class name, because it's slower and dangerous when binding >> parameters to a query. > > > I am not sure what you are talking about here. > > >> If stored as Class object references, they would have to be held in >> WeakReference objects tied to a ReferenceQueue, so as not to >> prevent garbage collection when a context is unloaded in a multi-context >> server. >> >> If stored as Strings, there would have to be a call to Class.forName >> for each, which if successful would have to check isInstance on the >> object or isAssignableFrom on it's class (when evaluating DB model). > > > Again, not really sure what you are talking about here. I guess you mean in > some "cache" based on the Java type handled? > I am talking about type registration and resolution in both. Right now, they're being registered in org.hibernate.boot.model.process.spi.MetadataBuildingProcess#handleTypes which creates a BasicTypeRegistry for resolving them. In the current state, they can only be registered by full class name. I'm proposing that they can optionally register interfaces. > Statement also gives you access to the Connection (Statement#getConnection) > Which JavaTypeDescriptor wrap and unwrap have no access to under the old model. > In general a lot of points are just out of date. If you want to influence > the development of this or be part of it you should consider joining the > HipChat channel where we discuss this stuff. I stopped trying to discuss > here because no one generally answers. > By HipChat do you mean the IRC #hibernate channel on Freenode? If not, the Community page has no mention of HipChat. Time zone differences would likely make that a poor choice for me. I'm in the EET zone. From sanne at hibernate.org Mon Oct 24 16:30:24 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 24 Oct 2016 21:30:24 +0100 Subject: [hibernate-dev] dynamic instantiation queries In-Reply-To: References: <580e61a5.832ec20a.d257f.6652@mx.google.com> Message-ID: Option 2# looks very nice indeed, I'd like that as it would be useful to be able to create immutable DTOs directly from a query; but I'm wondering what kind of difficulties this might pose, for example I'd assume the DTO constructor would be able to trigger lazy loading of any property of Person? Also wondering, if we expose query results as streams in the future, would such a feature not become obsolete? On 24 October 2016 at 20:38, Steve Ebersole wrote: > So Person is your entity, e.g.: > > @Entity > class Person { > @Id > Long id; > ... > } > > For a query like `select new DTO( p ) from Person p` Hibernate expects a > DTO like: > > class DTO { > public DTO(Long id) { > ... > } > } > > in fact a DTO like: > > class DTO { > public DTO(Person person) { > ... > } > } > > will not work with Hibernate. > > What I was proposing was for adding some support for that in 6.0 based on > the SQM work. "Support" here could mean either: > 1) add a flag that says whether to support legacy behavior, or this new > behavior > 2) attempt to dynamically infer what to do (looks at available ctors) > > (2) would be awesome I think. We'd still have to know how to handle cases > where the "DTO" defined ctors matching both cases and which to prefer. > > > On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea > wrote: > >> Do you mean we should allow the dynamic instantiation to resolve entities >> when we pass the entity identifier? >> >> I think I saw this request on StackOverflow once. >> >> Did I understand the question properly? >> >> Vlad >> ------------------------------ >> From: Steve Ebersole >> Sent: ?10/?24/?2016 22:21 >> To: hibernate-dev >> Subject: [hibernate-dev] dynamic instantiation queries >> >> Historically (well before JPA) HIbernate would handle dynamic instantiation >> queries in cases where one of the arguments being an entity-reference by >> passing just the entity's identifier rather than a complete reference to >> the entity. To be clear, I am talking about a query like: >> >> select new DTO( p ) from Person p >> >> Hibernate implicitly treats this like: >> >> select new DTO( p.id ) from Person p >> >> and expects DTO to have a ctor taking the appropriate ID type. >> >> JPA came along and also defines support for dynamic instantiation queries, >> but does not specify one way or the other how this case should be handled. >> I have been told other providers interpret this the opposite way. Makes >> sense. I think it is time we at least allow that as an option. Or maybe a >> nicer implementation that looks for both and picks the available one (if >> that's not too much effort). >> >> What do y'all think? >> _______________________________________________ >> 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 Oct 24 16:49:16 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 24 Oct 2016 20:49:16 +0000 Subject: [hibernate-dev] dynamic instantiation queries In-Reply-To: References: <580e61a5.832ec20a.d257f.6652@mx.google.com> Message-ID: I'm not sure what you are getting at. This is a feature Hibernate has had for close to 15 years. It's not a "new feature", I'm just proposing a new behavior to be more consistent with what people generally expect. On Mon, Oct 24, 2016, 3:30 PM Sanne Grinovero wrote: > Option 2# looks very nice indeed, I'd like that as it would be useful > to be able to create immutable DTOs directly from a query; but I'm > wondering what kind of difficulties this might pose, for example I'd > assume the DTO constructor would be able to trigger lazy loading of > any property of Person? > > Also wondering, if we expose query results as streams in the future, > would such a feature not become obsolete? > > > On 24 October 2016 at 20:38, Steve Ebersole wrote: > > So Person is your entity, e.g.: > > > > @Entity > > class Person { > > @Id > > Long id; > > ... > > } > > > > For a query like `select new DTO( p ) from Person p` Hibernate expects a > > DTO like: > > > > class DTO { > > public DTO(Long id) { > > ... > > } > > } > > > > in fact a DTO like: > > > > class DTO { > > public DTO(Person person) { > > ... > > } > > } > > > > will not work with Hibernate. > > > > What I was proposing was for adding some support for that in 6.0 based on > > the SQM work. "Support" here could mean either: > > 1) add a flag that says whether to support legacy behavior, or this new > > behavior > > 2) attempt to dynamically infer what to do (looks at available ctors) > > > > (2) would be awesome I think. We'd still have to know how to handle > cases > > where the "DTO" defined ctors matching both cases and which to prefer. > > > > > > On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea > > wrote: > > > >> Do you mean we should allow the dynamic instantiation to resolve > entities > >> when we pass the entity identifier? > >> > >> I think I saw this request on StackOverflow once. > >> > >> Did I understand the question properly? > >> > >> Vlad > >> ------------------------------ > >> From: Steve Ebersole > >> Sent: ?10/?24/?2016 22:21 > >> To: hibernate-dev > >> Subject: [hibernate-dev] dynamic instantiation queries > >> > >> Historically (well before JPA) HIbernate would handle dynamic > instantiation > >> queries in cases where one of the arguments being an entity-reference by > >> passing just the entity's identifier rather than a complete reference to > >> the entity. To be clear, I am talking about a query like: > >> > >> select new DTO( p ) from Person p > >> > >> Hibernate implicitly treats this like: > >> > >> select new DTO( p.id ) from Person p > >> > >> and expects DTO to have a ctor taking the appropriate ID type. > >> > >> JPA came along and also defines support for dynamic instantiation > queries, > >> but does not specify one way or the other how this case should be > handled. > >> I have been told other providers interpret this the opposite way. Makes > >> sense. I think it is time we at least allow that as an option. Or > maybe a > >> nicer implementation that looks for both and picks the available one (if > >> that's not too much effort). > >> > >> What do y'all think? > >> _______________________________________________ > >> 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 Oct 24 17:03:23 2016 From: andrea at hibernate.org (andrea boriero) Date: Mon, 24 Oct 2016 22:03:23 +0100 Subject: [hibernate-dev] dynamic instantiation queries In-Reply-To: References: <580e61a5.832ec20a.d257f.6652@mx.google.com> Message-ID: I think attempting to dynamically infer what to do using the existing ctr would be great On 24 October 2016 at 21:49, Steve Ebersole wrote: > I'm not sure what you are getting at. This is a feature Hibernate has had > for close to 15 years. It's not a "new feature", I'm just proposing a new > behavior to be more consistent with what people generally expect. > > On Mon, Oct 24, 2016, 3:30 PM Sanne Grinovero wrote: > > > Option 2# looks very nice indeed, I'd like that as it would be useful > > to be able to create immutable DTOs directly from a query; but I'm > > wondering what kind of difficulties this might pose, for example I'd > > assume the DTO constructor would be able to trigger lazy loading of > > any property of Person? > > > > Also wondering, if we expose query results as streams in the future, > > would such a feature not become obsolete? > > > > > > On 24 October 2016 at 20:38, Steve Ebersole wrote: > > > So Person is your entity, e.g.: > > > > > > @Entity > > > class Person { > > > @Id > > > Long id; > > > ... > > > } > > > > > > For a query like `select new DTO( p ) from Person p` Hibernate expects > a > > > DTO like: > > > > > > class DTO { > > > public DTO(Long id) { > > > ... > > > } > > > } > > > > > > in fact a DTO like: > > > > > > class DTO { > > > public DTO(Person person) { > > > ... > > > } > > > } > > > > > > will not work with Hibernate. > > > > > > What I was proposing was for adding some support for that in 6.0 based > on > > > the SQM work. "Support" here could mean either: > > > 1) add a flag that says whether to support legacy behavior, or this new > > > behavior > > > 2) attempt to dynamically infer what to do (looks at available ctors) > > > > > > (2) would be awesome I think. We'd still have to know how to handle > > cases > > > where the "DTO" defined ctors matching both cases and which to prefer. > > > > > > > > > On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea > > > > wrote: > > > > > >> Do you mean we should allow the dynamic instantiation to resolve > > entities > > >> when we pass the entity identifier? > > >> > > >> I think I saw this request on StackOverflow once. > > >> > > >> Did I understand the question properly? > > >> > > >> Vlad > > >> ------------------------------ > > >> From: Steve Ebersole > > >> Sent: ?10/?24/?2016 22:21 > > >> To: hibernate-dev > > >> Subject: [hibernate-dev] dynamic instantiation queries > > >> > > >> Historically (well before JPA) HIbernate would handle dynamic > > instantiation > > >> queries in cases where one of the arguments being an entity-reference > by > > >> passing just the entity's identifier rather than a complete reference > to > > >> the entity. To be clear, I am talking about a query like: > > >> > > >> select new DTO( p ) from Person p > > >> > > >> Hibernate implicitly treats this like: > > >> > > >> select new DTO( p.id ) from Person p > > >> > > >> and expects DTO to have a ctor taking the appropriate ID type. > > >> > > >> JPA came along and also defines support for dynamic instantiation > > queries, > > >> but does not specify one way or the other how this case should be > > handled. > > >> I have been told other providers interpret this the opposite way. > Makes > > >> sense. I think it is time we at least allow that as an option. Or > > maybe a > > >> nicer implementation that looks for both and picks the available one > (if > > >> that's not too much effort). > > >> > > >> What do y'all think? > > >> _______________________________________________ > > >> 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 Oct 24 17:34:34 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 24 Oct 2016 22:34:34 +0100 Subject: [hibernate-dev] dynamic instantiation queries In-Reply-To: References: <580e61a5.832ec20a.d257f.6652@mx.google.com> Message-ID: On 24 October 2016 at 21:49, Steve Ebersole wrote: > I'm not sure what you are getting at. This is a feature Hibernate has had > for close to 15 years. It's not a "new feature", I'm just proposing a new > behavior to be more consistent with what people generally expect. Yes I like the proposal; I'm just wondering if there might be some hidden complexities in allowing to initialise additional lazy properties during the query execution, as a side-effect of the constructor's code as I guess it might want to invoke various getters on the Person instance. If you say that's not a problem, then that's good news :) > > > On Mon, Oct 24, 2016, 3:30 PM Sanne Grinovero wrote: >> >> Option 2# looks very nice indeed, I'd like that as it would be useful >> to be able to create immutable DTOs directly from a query; but I'm >> wondering what kind of difficulties this might pose, for example I'd >> assume the DTO constructor would be able to trigger lazy loading of >> any property of Person? >> >> Also wondering, if we expose query results as streams in the future, >> would such a feature not become obsolete? >> >> >> On 24 October 2016 at 20:38, Steve Ebersole wrote: >> > So Person is your entity, e.g.: >> > >> > @Entity >> > class Person { >> > @Id >> > Long id; >> > ... >> > } >> > >> > For a query like `select new DTO( p ) from Person p` Hibernate expects a >> > DTO like: >> > >> > class DTO { >> > public DTO(Long id) { >> > ... >> > } >> > } >> > >> > in fact a DTO like: >> > >> > class DTO { >> > public DTO(Person person) { >> > ... >> > } >> > } >> > >> > will not work with Hibernate. >> > >> > What I was proposing was for adding some support for that in 6.0 based >> > on >> > the SQM work. "Support" here could mean either: >> > 1) add a flag that says whether to support legacy behavior, or this new >> > behavior >> > 2) attempt to dynamically infer what to do (looks at available ctors) >> > >> > (2) would be awesome I think. We'd still have to know how to handle >> > cases >> > where the "DTO" defined ctors matching both cases and which to prefer. >> > >> > >> > On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea >> > wrote: >> > >> >> Do you mean we should allow the dynamic instantiation to resolve >> >> entities >> >> when we pass the entity identifier? >> >> >> >> I think I saw this request on StackOverflow once. >> >> >> >> Did I understand the question properly? >> >> >> >> Vlad >> >> ------------------------------ >> >> From: Steve Ebersole >> >> Sent: ?10/?24/?2016 22:21 >> >> To: hibernate-dev >> >> Subject: [hibernate-dev] dynamic instantiation queries >> >> >> >> Historically (well before JPA) HIbernate would handle dynamic >> >> instantiation >> >> queries in cases where one of the arguments being an entity-reference >> >> by >> >> passing just the entity's identifier rather than a complete reference >> >> to >> >> the entity. To be clear, I am talking about a query like: >> >> >> >> select new DTO( p ) from Person p >> >> >> >> Hibernate implicitly treats this like: >> >> >> >> select new DTO( p.id ) from Person p >> >> >> >> and expects DTO to have a ctor taking the appropriate ID type. >> >> >> >> JPA came along and also defines support for dynamic instantiation >> >> queries, >> >> but does not specify one way or the other how this case should be >> >> handled. >> >> I have been told other providers interpret this the opposite way. >> >> Makes >> >> sense. I think it is time we at least allow that as an option. Or >> >> maybe a >> >> nicer implementation that looks for both and picks the available one >> >> (if >> >> that's not too much effort). >> >> >> >> What do y'all think? >> >> _______________________________________________ >> >> 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 Oct 24 19:40:47 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 24 Oct 2016 23:40:47 +0000 Subject: [hibernate-dev] dynamic instantiation queries In-Reply-To: References: <580e61a5.832ec20a.d257f.6652@mx.google.com> Message-ID: Still not really understanding what you are getting at. Do you have an example? The entity passed into the "DTO" would be managed. If they wanted to initialize stuff on that entity it would happen just as normal for a managed entity. Is that what you mean? On Mon, Oct 24, 2016, 4:34 PM Sanne Grinovero wrote: > On 24 October 2016 at 21:49, Steve Ebersole wrote: > > I'm not sure what you are getting at. This is a feature Hibernate has had > > for close to 15 years. It's not a "new feature", I'm just proposing a > new > > behavior to be more consistent with what people generally expect. > > Yes I like the proposal; I'm just wondering if there might be some > hidden complexities in allowing to initialise additional lazy > properties during the query execution, as a side-effect of the > constructor's code as I guess it might want to invoke various getters > on the Person instance. If you say that's not a problem, then that's > good news :) > > > > > > > On Mon, Oct 24, 2016, 3:30 PM Sanne Grinovero > wrote: > >> > >> Option 2# looks very nice indeed, I'd like that as it would be useful > >> to be able to create immutable DTOs directly from a query; but I'm > >> wondering what kind of difficulties this might pose, for example I'd > >> assume the DTO constructor would be able to trigger lazy loading of > >> any property of Person? > >> > >> Also wondering, if we expose query results as streams in the future, > >> would such a feature not become obsolete? > >> > >> > >> On 24 October 2016 at 20:38, Steve Ebersole > wrote: > >> > So Person is your entity, e.g.: > >> > > >> > @Entity > >> > class Person { > >> > @Id > >> > Long id; > >> > ... > >> > } > >> > > >> > For a query like `select new DTO( p ) from Person p` Hibernate > expects a > >> > DTO like: > >> > > >> > class DTO { > >> > public DTO(Long id) { > >> > ... > >> > } > >> > } > >> > > >> > in fact a DTO like: > >> > > >> > class DTO { > >> > public DTO(Person person) { > >> > ... > >> > } > >> > } > >> > > >> > will not work with Hibernate. > >> > > >> > What I was proposing was for adding some support for that in 6.0 based > >> > on > >> > the SQM work. "Support" here could mean either: > >> > 1) add a flag that says whether to support legacy behavior, or this > new > >> > behavior > >> > 2) attempt to dynamically infer what to do (looks at available ctors) > >> > > >> > (2) would be awesome I think. We'd still have to know how to handle > >> > cases > >> > where the "DTO" defined ctors matching both cases and which to prefer. > >> > > >> > > >> > On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea < > mihalcea.vlad at gmail.com> > >> > wrote: > >> > > >> >> Do you mean we should allow the dynamic instantiation to resolve > >> >> entities > >> >> when we pass the entity identifier? > >> >> > >> >> I think I saw this request on StackOverflow once. > >> >> > >> >> Did I understand the question properly? > >> >> > >> >> Vlad > >> >> ------------------------------ > >> >> From: Steve Ebersole > >> >> Sent: ?10/?24/?2016 22:21 > >> >> To: hibernate-dev > >> >> Subject: [hibernate-dev] dynamic instantiation queries > >> >> > >> >> Historically (well before JPA) HIbernate would handle dynamic > >> >> instantiation > >> >> queries in cases where one of the arguments being an entity-reference > >> >> by > >> >> passing just the entity's identifier rather than a complete reference > >> >> to > >> >> the entity. To be clear, I am talking about a query like: > >> >> > >> >> select new DTO( p ) from Person p > >> >> > >> >> Hibernate implicitly treats this like: > >> >> > >> >> select new DTO( p.id ) from Person p > >> >> > >> >> and expects DTO to have a ctor taking the appropriate ID type. > >> >> > >> >> JPA came along and also defines support for dynamic instantiation > >> >> queries, > >> >> but does not specify one way or the other how this case should be > >> >> handled. > >> >> I have been told other providers interpret this the opposite way. > >> >> Makes > >> >> sense. I think it is time we at least allow that as an option. Or > >> >> maybe a > >> >> nicer implementation that looks for both and picks the available one > >> >> (if > >> >> that's not too much effort). > >> >> > >> >> What do y'all think? > >> >> _______________________________________________ > >> >> hibernate-dev mailing list > >> >> hibernate-dev at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >> > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gbadner at redhat.com Wed Oct 26 01:48:46 2016 From: gbadner at redhat.com (Gail Badner) Date: Tue, 25 Oct 2016 22:48:46 -0700 Subject: [hibernate-dev] HHH-11144 Message-ID: HHH-11144 involves an entity that has 2 one-to-many associations with the same type of entity, and both associations have orphanRemoval = true. Andrea created a PR with test case at [1] I am not sure if this is a valid mapping. I I would like your thoughts on this. Here is an excerpt of the relevant bits: @Entity(name = "Item") public static class Item { @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, orphanRemoval = true) protected Set lowerItemRelations = new LinkedHashSet<>(); @OneToMany(mappedBy = "child", cascade = CascadeType.ALL, orphanRemoval = true) protected Set higherItemRelations = new LinkedHashSet<>(); } @Entity(name = "ItemRelation") public static class ItemRelation { @ManyToOne(optional = false) @JoinColumn(name = "PARENT_ID") private Item parent; @ManyToOne(optional = false) @JoinColumn(name = "CHILD_ID") private Item child; } HHH-11144 describes inconsistent behavior observed when Item#lowerItemRelations and Item#higherItemRelations both contain the same ItemRelation, then one of the collections is cleared. If the non-cleared collection is uninitialized, then the ItemRelation is orphan deleted. If the non-cleared collection is initialized, then the orphan-deleted ItemRelation is rescued when PERSIST_ON_FLUSH cascades to the non-cleared collection elements. The next time the collections are loaded from the database, both will still contain that same ItemRelation. The spec says: "Portable applications must otherwise not depend upon a specific order of removal, and must not reassign an entity that has been orphaned to another relationship or *otherwise attempt to persist it*" Is Hibernate doing the right thing by rescuing an orphan-deleted entity? In addition, this mapping allows a particular EntityRelation to be associated with 2 different Item entities, which would mean that the same ItemRelation would have 2 different owners with respect to orphan deletion.. The spec says: "The orphanRemoval functionality is intended for entities that are privately ?owned? by their parent entity." Does this mean that the mapping is invalid, since it would allow multiple parent entities, or does it mean that the resulting behavior is undefined (thus non-portable)? Please let me know your thoughts. Thanks, Gail [1] https://github.com/hibernate/hibernate-orm/pull/1607 From gbadner at redhat.com Wed Oct 26 03:12:21 2016 From: gbadner at redhat.com (Gail Badner) Date: Wed, 26 Oct 2016 00:12:21 -0700 Subject: [hibernate-dev] HHH-11155 : problems updating lazy properties in lazy groups Message-ID: Static update strings appear to cover only the following situations: 1) there are no uninitialized properties (so all updateable attributes should be updated); 2) all lazy properties are uninitialized (so only non-lazy, updateable attributes should be updated). As of 5.1, we have "lazy groups". It is possible some lazy groups are initialized, and some are uninitialized. We have a couple of alternatives for dealing with the various combinations: For example, if there are are 3 lazy groups: lazyGroup1, lazyGroup2, lazyGroup3. 1) Generate SQL update strings for all possible combinations of initialized lazy groups: SQL update strings are already generated for the following combinations: * lazyGroup1: uninitialized; lazyGroup2: uninitialized; lazyGroup3: uninitialized * lazyGroup1: initialized; lazyGroup2: initialized; lazyGroup3: initialized SQL update strings for the following combinations need to be generated to fix the bug: * lazyGroup1: initialized; lazyGroup2: uninitialized; lazyGroup3: uninitialized * lazyGroup1: uninitialized; lazyGroup2: initialized; lazyGroup3: uninitialized * lazyGroup1: uninitialized; lazyGroup2: uninitialized; lazyGroup3: initialized * lazyGroup1: initialized; lazyGroup2: initialized; lazyGroup3: uninitialized * lazyGroup1: initialized; lazyGroup2: uninitialized; lazyGroup3: initialized * lazyGroup1: uninitialized; lazyGroup2: initialized; lazyGroup3: initialized The update strings could be stored in a Map with key containing the names (or indexes?) of the corresponding initialized lazy groups. 2) Generate dynamic update strings when there is at least 1 uninitialized group, or when there are more than N lazy groups. What should N be? Comments or suggestions? A related bug is that calling a setter on a lazy property only initializes that one lazy property. It should also initialize other properties in the same lazy group. This one is pretty easy to fix. Thanks, Gail From andrea at hibernate.org Wed Oct 26 09:02:20 2016 From: andrea at hibernate.org (andrea boriero) Date: Wed, 26 Oct 2016 14:02:20 +0100 Subject: [hibernate-dev] Starting 5.2.4 release Message-ID: Please do not push anything to master branch. Thanks, Andrea From andrea at hibernate.org Wed Oct 26 13:12:45 2016 From: andrea at hibernate.org (andrea boriero) Date: Wed, 26 Oct 2016 18:12:45 +0100 Subject: [hibernate-dev] Hibernate ORM 5.2.4.Final has been released Message-ID: For details: http://in.relation.to/2016/10/26/hibernate-orm-524-final-release/ From sanne at hibernate.org Wed Oct 26 17:19:23 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 26 Oct 2016 22:19:23 +0100 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly Message-ID: Hi all, there's a conflict in the Javassist versions of the WildFly modules of Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not familiar with this functionality. The module declares *both*: - a dependency to the WildFly provided Javassist: - inclusion of Hibernate's own version of Javassist: Having both is causing trouble as they are both visible to the Hibernate classloader; however I couldn't score a quick win with the testsuiste by disabling either (all tests using these modules in the Hibernate Search testsuite fail). I suspect the problem is that JipiJapa also depends on the , while ORM obviously needs the more recent version of it. I'm not familiar with what JipiJapa's business around Javassist; could we keep the two clearly separated? Especially if we want to make Byte Buddy a viable alternative, I suspect the solution is that JipiJapa should not depend on Javassist directly, but invoke a generic instrumentation SPI on Hibernate; also with JipiJapa not able to see Javassist at all, we'd be in control of the one and only Javassist version visible to ORM: the one we compile and test with. Thanks, Sanne From gunnar at hibernate.org Wed Oct 26 17:39:15 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 26 Oct 2016 23:39:15 +0200 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: Would be interesting to know why JipiJapa is depending on it. In a quick search I couldn't spot any actual usages. JPADependencyProcessor adds a dependency to "org.javassist", maybe that could be avoided by having the ORM module re-export the version of JipiJipa it is using? For that he module ZIP would have to contain a module for the new JipiJapa version and ORM's module.xml would depend on it and re-export it. --Gunnar 2016-10-26 23:19 GMT+02:00 Sanne Grinovero : > Hi all, > > there's a conflict in the Javassist versions of the WildFly modules of > Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not > familiar with this functionality. > > The module declares *both*: > - a dependency to the WildFly provided Javassist: name="org.javassist"/> > - inclusion of Hibernate's own version of Javassist: path="javassist-3.20.0-GA.jar"/> > > Having both is causing trouble as they are both visible to the > Hibernate classloader; however I couldn't score a quick win with the > testsuiste by disabling either (all tests using these modules in the > Hibernate Search testsuite fail). > > I suspect the problem is that JipiJapa also depends on the name="org.javassist"/>, while ORM obviously needs the more recent > version of it. > > I'm not familiar with what JipiJapa's business around Javassist; could > we keep the two clearly separated? > > Especially if we want to make Byte Buddy a viable alternative, I > suspect the solution is that JipiJapa should not depend on Javassist > directly, but invoke a generic instrumentation SPI on Hibernate; also > with JipiJapa not able to see Javassist at all, we'd be in control of > the one and only Javassist version visible to ORM: the one we compile > and test with. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From smarlow at redhat.com Wed Oct 26 18:44:29 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 26 Oct 2016 18:44:29 -0400 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: Just to be clear, Jipijapa doesn't use Javassist at all. For JPA deployments that are using Hibernate, the (WildFly) JPA container is exporting the org.javassist:module to the application deployment classloader, so that the Javassist proxy runtime classes can be referenced by application classes that are rewritten by ORM. If we were to use ByteBuddy, there are no runtime proxy classes needed on the application classpath. There is currently no way to tell the JPA container how to export a different Javassist module to the application deployment. The best solution is for the JPA container to stop exporting Javassist to the application classpath, which means an ORM change to that effect (either shadow the Javassist runtime proxy classes or something like that, or try using ByteBuddy instead). If we were to add a configuration hint for the JPA compiler to inject a different version of javassist, I don't have confidence that the code change would be merged, since we really want a better fix. On Wed, Oct 26, 2016 at 5:19 PM, Sanne Grinovero wrote: > Hi all, > > there's a conflict in the Javassist versions of the WildFly modules of > Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not > familiar with this functionality. > > The module declares *both*: > - a dependency to the WildFly provided Javassist: name="org.javassist"/> > - inclusion of Hibernate's own version of Javassist: path="javassist-3.20.0-GA.jar"/> > > Having both is causing trouble as they are both visible to the > Hibernate classloader; however I couldn't score a quick win with the > testsuiste by disabling either (all tests using these modules in the > Hibernate Search testsuite fail). > > I suspect the problem is that JipiJapa also depends on the name="org.javassist"/>, while ORM obviously needs the more recent > version of it. > > I'm not familiar with what JipiJapa's business around Javassist; could > we keep the two clearly separated? > > Especially if we want to make Byte Buddy a viable alternative, I > suspect the solution is that JipiJapa should not depend on Javassist > directly, but invoke a generic instrumentation SPI on Hibernate; also > with JipiJapa not able to see Javassist at all, we'd be in control of > the one and only Javassist version visible to ORM: the one we compile > and test with. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Wed Oct 26 18:58:53 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 27 Oct 2016 00:58:53 +0200 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: Hi, 2016-10-27 0:44 GMT+02:00 Scott Marlow : > Just to be clear, Jipijapa doesn't use Javassist at all. Ok. What is the reason then that it is declaring this module dependency? > For JPA > deployments that are using Hibernate, the (WildFly) JPA container is > exporting the org.javassist:module to the application deployment > classloader, so that the Javassist proxy runtime classes can be > referenced by application classes that are rewritten by ORM. Couldn't this be achieved by having the ORM module re-export the Javassist module it depends on (in the module.xml of ORM, that is)? That way JipiJapa would make no assumption about Javassist at all, it'd be left to the ORM module as added by JipiJapa to the deployment. > If we > were to use ByteBuddy, there are no runtime proxy classes needed on > the application classpath. > > There is currently no way to tell the JPA container how to export a > different Javassist module to the application deployment. The best > solution is for the JPA container to stop exporting Javassist to the > application classpath, which means an ORM change to that effect > (either shadow the Javassist runtime proxy classes or something like > that, or try using ByteBuddy instead). > > If we were to add a configuration hint for the JPA compiler to inject > a different version of javassist, I don't have confidence that the > code change would be merged, since we really want a better fix. > > On Wed, Oct 26, 2016 at 5:19 PM, Sanne Grinovero > wrote: > > Hi all, > > > > there's a conflict in the Javassist versions of the WildFly modules of > > Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not > > familiar with this functionality. > > > > The module declares *both*: > > - a dependency to the WildFly provided Javassist: > name="org.javassist"/> > > - inclusion of Hibernate's own version of Javassist: > path="javassist-3.20.0-GA.jar"/> > > > > Having both is causing trouble as they are both visible to the > > Hibernate classloader; however I couldn't score a quick win with the > > testsuiste by disabling either (all tests using these modules in the > > Hibernate Search testsuite fail). > > > > I suspect the problem is that JipiJapa also depends on the > name="org.javassist"/>, while ORM obviously needs the more recent > > version of it. > > > > I'm not familiar with what JipiJapa's business around Javassist; could > > we keep the two clearly separated? > > > > Especially if we want to make Byte Buddy a viable alternative, I > > suspect the solution is that JipiJapa should not depend on Javassist > > directly, but invoke a generic instrumentation SPI on Hibernate; also > > with JipiJapa not able to see Javassist at all, we'd be in control of > > the one and only Javassist version visible to ORM: the one we compile > > and test with. > > > > 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 smarlow at redhat.com Wed Oct 26 21:30:16 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 26 Oct 2016 21:30:16 -0400 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: On Wed, Oct 26, 2016 at 6:58 PM, Gunnar Morling wrote: > Hi, > > 2016-10-27 0:44 GMT+02:00 Scott Marlow : >> >> Just to be clear, Jipijapa doesn't use Javassist at all. > > > Ok. What is the reason then that it is declaring this module dependency? No reason, looks like an unneeded dependency that could be removed. > >> >> For JPA >> deployments that are using Hibernate, the (WildFly) JPA container is >> exporting the org.javassist:module to the application deployment >> classloader, so that the Javassist proxy runtime classes can be >> referenced by application classes that are rewritten by ORM. > > > Couldn't this be achieved by having the ORM module re-export the Javassist > module it depends on (in the module.xml of ORM, that is)? > > > > That way JipiJapa would make no assumption about Javassist at all, it'd be > left to the ORM module as added by JipiJapa to the deployment. I agree. We created a pull request (Pull request link is https://github.com/wildfly/wildfly/pull/8474) for that previously but it didn't get merged because ORM shouldn't require the application classpath to contain Javassist classes, as that could conflict with the application also wanting to include a different version of Javassist for the application to use. Is the ORM testsuite building the WildFly app server from source? if yes, perhaps we could build WildFly with the newer Javassist: ./build.sh clean install -Dversion.org.javassist=3.20.0-GA Other option would be to use ByteBuddy to generate proxies instead of Javassist to eliminate the application dependency on the Javassist runtime classes. > >> >> If we >> were to use ByteBuddy, there are no runtime proxy classes needed on >> the application classpath. >> >> There is currently no way to tell the JPA container how to export a >> different Javassist module to the application deployment. The best >> solution is for the JPA container to stop exporting Javassist to the >> application classpath, which means an ORM change to that effect >> (either shadow the Javassist runtime proxy classes or something like >> that, or try using ByteBuddy instead). >> >> If we were to add a configuration hint for the JPA compiler to inject >> a different version of javassist, I don't have confidence that the >> code change would be merged, since we really want a better fix. >> >> On Wed, Oct 26, 2016 at 5:19 PM, Sanne Grinovero >> wrote: >> > Hi all, >> > >> > there's a conflict in the Javassist versions of the WildFly modules of >> > Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not >> > familiar with this functionality. >> > >> > The module declares *both*: >> > - a dependency to the WildFly provided Javassist: > > name="org.javassist"/> >> > - inclusion of Hibernate's own version of Javassist: > > path="javassist-3.20.0-GA.jar"/> >> > >> > Having both is causing trouble as they are both visible to the >> > Hibernate classloader; however I couldn't score a quick win with the >> > testsuiste by disabling either (all tests using these modules in the >> > Hibernate Search testsuite fail). >> > >> > I suspect the problem is that JipiJapa also depends on the > > name="org.javassist"/>, while ORM obviously needs the more recent >> > version of it. >> > >> > I'm not familiar with what JipiJapa's business around Javassist; could >> > we keep the two clearly separated? >> > >> > Especially if we want to make Byte Buddy a viable alternative, I >> > suspect the solution is that JipiJapa should not depend on Javassist >> > directly, but invoke a generic instrumentation SPI on Hibernate; also >> > with JipiJapa not able to see Javassist at all, we'd be in control of >> > the one and only Javassist version visible to ORM: the one we compile >> > and test with. >> > >> > Thanks, >> > Sanne >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From steve at hibernate.org Wed Oct 26 22:13:34 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 27 Oct 2016 02:13:34 +0000 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: On Wed, Oct 26, 2016 at 8:33 PM Scott Marlow wrote: > On Wed, Oct 26, 2016 at 6:58 PM, Gunnar Morling > wrote: > > Couldn't this be achieved by having the ORM module re-export the > Javassist > > module it depends on (in the module.xml of ORM, that is)? > > > > > > > > That way JipiJapa would make no assumption about Javassist at all, it'd > be > > left to the ORM module as added by JipiJapa to the deployment. > > I agree. > > We created a pull request (Pull request link is > https://github.com/wildfly/wildfly/pull/8474) for that previously but > it didn't get merged because ORM shouldn't require the application > classpath to contain Javassist classes, as that could conflict with > the application also wanting to include a different version of > Javassist for the application to use. > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module (the WF module) export Javassist. Not the application. Is the ORM testsuite building the WildFly app server from source? Good god no :) > Other option would be to use ByteBuddy to generate proxies instead of > Javassist to eliminate the application dependency on the Javassist > runtime classes. > Rafael Winterhalter is actually pretty far along on defining support for Byte Buddy in Hibernate[1]. So that might soon be an option. [1] https://hibernate.atlassian.net/browse/HHH-11152 From smarlow at redhat.com Wed Oct 26 22:27:18 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 26 Oct 2016 22:27:18 -0400 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module (the WF module) export Javassist. Not the application. > I agree, that is what our WF pull request did, which I think is an incremental improvement but that wasn't approved for the reason I gave. >> Is the ORM testsuite building the WildFly app server from source? > > > Good god no :) > > >> >> Other option would be to use ByteBuddy to generate proxies instead of >> Javassist to eliminate the application dependency on the Javassist >> runtime classes. > > > > Rafael Winterhalter is actually pretty far along on defining support for Byte Buddy in Hibernate[1]. So that might soon be an option. > > [1] https://hibernate.atlassian.net/browse/HHH-11152 > +100 :) From gunnar at hibernate.org Thu Oct 27 04:49:00 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 27 Oct 2016 10:49:00 +0200 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: Hi, 2016-10-27 4:27 GMT+02:00 Scott Marlow : > > > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module > (the WF module) export Javassist. Not the application. > Right, Hibernate ORM's module should be the one exposing it, not the application nor JipiJapa. This allows the ORM module to expose the right version of Javassist (or none at all eventually) without requiring JipiJapa to have the knowledge about this. As things stand, Javassist can be considered as part of ORM's API, hence it's module.xml should be the one making it available to the user. Of course eventually we don't want to expose Javassist at all, but as long as we do, the ORM module should be in charge of doing so. > > > > I agree, that is what our WF pull request did, which I think is an > incremental improvement but that wasn't approved for the reason I gave. > I don't quite get the reasoning here. We all agree that Javassist shouldn't be exposed at all (and there is good progress being made towards this by using ByteBuddy). But as long as we do, leaving this responsibility to the ORM module is the right thing to do IMO. E.g. what if a JPA provider doesn't need Javassist at all? Still JipiJapa would currently add it to the deployment. I've done the following changes locally: 1) Altered JPADependencyProcessor to not add the Javassist dependency to the deployment 2) Altered module.xml of jipijapa-hibernate5 to not depend on Javassist 3) Added a new module for the latest Javassist 4) Altered module.xml of ORM itself to depend on that new module *and* re-export it With all this in place, the tests in Hibernate Search pass successfully. Scott, do you think we can try another PR with that? Again, it doesn't change things in terms of exposure of Javassist to the application (it is exposed, just as it was before). But it puts the responsibility for doing so to ORM's module, allowing us (via the ORM module ZIP we provide) to expose a newer Javassist version as needed. Note that 2 - 4 can be done via the ORM module ZIP. But 1) is a change that needs to be done on the WF side, at least I don't see how this could be overridden? I.e. the module ZIP is rather pointless atm. and we don't have a good way to put the latest ORM into WF user's hands. Would be nice to change this. >> Is the ORM testsuite building the WildFly app server from source? > > > > > > Good god no :) > > > > > >> > >> Other option would be to use ByteBuddy to generate proxies instead of > >> Javassist to eliminate the application dependency on the Javassist > >> runtime classes. > > > > > > > > Rafael Winterhalter is actually pretty far along on defining support for > Byte Buddy in Hibernate[1]. So that might soon be an option. > > > > [1] https://hibernate.atlassian.net/browse/HHH-11152 > > > +100 :) > From sanne at hibernate.org Thu Oct 27 05:23:11 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 27 Oct 2016 10:23:11 +0100 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: We could fix 1) as well by incorporating the sources for jipijapa-hibernate52 in ORM. I think it belongs within Hibernate, as it won't be the last time that a new ORM version requires some adaptation of bootstrap. On 27 Oct 2016 09:51, "Gunnar Morling" wrote: > Hi, > > 2016-10-27 4:27 GMT+02:00 Scott Marlow : > > > > > > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM > module > > (the WF module) export Javassist. Not the application. > > > > Right, Hibernate ORM's module should be the one exposing it, not the > application nor JipiJapa. > > This allows the ORM module to expose the right version of Javassist (or > none at all eventually) without requiring JipiJapa to have the knowledge > about this. As things stand, Javassist can be considered as part of ORM's > API, hence it's module.xml should be the one making it available to the > user. > > Of course eventually we don't want to expose Javassist at all, but as long > as we do, the ORM module should be in charge of doing so. > > > > > > > > I agree, that is what our WF pull request did, which I think is an > > incremental improvement but that wasn't approved for the reason I gave. > > > > I don't quite get the reasoning here. We all agree that Javassist shouldn't > be exposed at all (and there is good progress being made towards this by > using ByteBuddy). > > But as long as we do, leaving this responsibility to the ORM module is the > right thing to do IMO. E.g. what if a JPA provider doesn't need Javassist > at all? Still JipiJapa would currently add it to the deployment. > > I've done the following changes locally: > > 1) Altered JPADependencyProcessor to not add the Javassist dependency to > the deployment > 2) Altered module.xml of jipijapa-hibernate5 to not depend on Javassist > 3) Added a new module for the latest Javassist > 4) Altered module.xml of ORM itself to depend on that new module *and* > re-export it > > With all this in place, the tests in Hibernate Search pass successfully. > > Scott, do you think we can try another PR with that? Again, it doesn't > change things in terms of exposure of Javassist to the application (it is > exposed, just as it was before). But it puts the responsibility for doing > so to ORM's module, allowing us (via the ORM module ZIP we provide) to > expose a newer Javassist version as needed. > > Note that 2 - 4 can be done via the ORM module ZIP. But 1) is a change that > needs to be done on the WF side, at least I don't see how this could be > overridden? > > I.e. the module ZIP is rather pointless atm. and we don't have a good way > to put the latest ORM into WF user's hands. Would be nice to change this. > > >> Is the ORM testsuite building the WildFly app server from source? > > > > > > > > > Good god no :) > > > > > > > > >> > > >> Other option would be to use ByteBuddy to generate proxies instead of > > >> Javassist to eliminate the application dependency on the Javassist > > >> runtime classes. > > > > > > > > > > > > Rafael Winterhalter is actually pretty far along on defining support > for > > Byte Buddy in Hibernate[1]. So that might soon be an option. > > > > > > [1] https://hibernate.atlassian.net/browse/HHH-11152 > > > > > +100 :) > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Thu Oct 27 05:38:21 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 27 Oct 2016 11:38:21 +0200 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: No, JPADependencyProcessor - which is adding the dependency - is part of "wildfly-jpa", not "jipijapa-hibernate". 2016-10-27 11:23 GMT+02:00 Sanne Grinovero : > We could fix 1) as well by incorporating the sources for > jipijapa-hibernate52 in ORM. > > I think it belongs within Hibernate, as it won't be the last time that a > new ORM version requires some adaptation of bootstrap. > > On 27 Oct 2016 09:51, "Gunnar Morling" wrote: > >> Hi, >> >> 2016-10-27 4:27 GMT+02:00 Scott Marlow : >> >> > >> > > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM >> module >> > (the WF module) export Javassist. Not the application. >> > >> >> Right, Hibernate ORM's module should be the one exposing it, not the >> application nor JipiJapa. >> >> This allows the ORM module to expose the right version of Javassist (or >> none at all eventually) without requiring JipiJapa to have the knowledge >> about this. As things stand, Javassist can be considered as part of ORM's >> API, hence it's module.xml should be the one making it available to the >> user. >> >> Of course eventually we don't want to expose Javassist at all, but as long >> as we do, the ORM module should be in charge of doing so. >> >> > > >> > >> > I agree, that is what our WF pull request did, which I think is an >> > incremental improvement but that wasn't approved for the reason I gave. >> > >> >> I don't quite get the reasoning here. We all agree that Javassist >> shouldn't >> be exposed at all (and there is good progress being made towards this by >> using ByteBuddy). >> >> But as long as we do, leaving this responsibility to the ORM module is the >> right thing to do IMO. E.g. what if a JPA provider doesn't need Javassist >> at all? Still JipiJapa would currently add it to the deployment. >> >> I've done the following changes locally: >> >> 1) Altered JPADependencyProcessor to not add the Javassist dependency to >> the deployment >> 2) Altered module.xml of jipijapa-hibernate5 to not depend on Javassist >> 3) Added a new module for the latest Javassist >> 4) Altered module.xml of ORM itself to depend on that new module *and* >> re-export it >> >> With all this in place, the tests in Hibernate Search pass successfully. >> >> Scott, do you think we can try another PR with that? Again, it doesn't >> change things in terms of exposure of Javassist to the application (it is >> exposed, just as it was before). But it puts the responsibility for doing >> so to ORM's module, allowing us (via the ORM module ZIP we provide) to >> expose a newer Javassist version as needed. >> >> Note that 2 - 4 can be done via the ORM module ZIP. But 1) is a change >> that >> needs to be done on the WF side, at least I don't see how this could be >> overridden? >> >> I.e. the module ZIP is rather pointless atm. and we don't have a good way >> to put the latest ORM into WF user's hands. Would be nice to change this. >> >> >> Is the ORM testsuite building the WildFly app server from source? >> > > >> > > >> > > Good god no :) >> > > >> > > >> > >> >> > >> Other option would be to use ByteBuddy to generate proxies instead of >> > >> Javassist to eliminate the application dependency on the Javassist >> > >> runtime classes. >> > > >> > > >> > > >> > > Rafael Winterhalter is actually pretty far along on defining support >> for >> > Byte Buddy in Hibernate[1]. So that might soon be an option. >> > > >> > > [1] https://hibernate.atlassian.net/browse/HHH-11152 >> > > >> > +100 :) >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From sanne at hibernate.org Thu Oct 27 06:12:53 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 27 Oct 2016 11:12:53 +0100 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: Ok well that's also odd isn't it? On 27 Oct 2016 10:38, "Gunnar Morling" wrote: > No, JPADependencyProcessor - which is adding the dependency - is part of > "wildfly-jpa", not "jipijapa-hibernate". > > 2016-10-27 11:23 GMT+02:00 Sanne Grinovero : > >> We could fix 1) as well by incorporating the sources for >> jipijapa-hibernate52 in ORM. >> >> I think it belongs within Hibernate, as it won't be the last time that a >> new ORM version requires some adaptation of bootstrap. >> >> On 27 Oct 2016 09:51, "Gunnar Morling" wrote: >> >>> Hi, >>> >>> 2016-10-27 4:27 GMT+02:00 Scott Marlow : >>> >>> > >>> > > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM >>> module >>> > (the WF module) export Javassist. Not the application. >>> > >>> >>> Right, Hibernate ORM's module should be the one exposing it, not the >>> application nor JipiJapa. >>> >>> This allows the ORM module to expose the right version of Javassist (or >>> none at all eventually) without requiring JipiJapa to have the knowledge >>> about this. As things stand, Javassist can be considered as part of ORM's >>> API, hence it's module.xml should be the one making it available to the >>> user. >>> >>> Of course eventually we don't want to expose Javassist at all, but as >>> long >>> as we do, the ORM module should be in charge of doing so. >>> >>> > > >>> > >>> > I agree, that is what our WF pull request did, which I think is an >>> > incremental improvement but that wasn't approved for the reason I gave. >>> > >>> >>> I don't quite get the reasoning here. We all agree that Javassist >>> shouldn't >>> be exposed at all (and there is good progress being made towards this by >>> using ByteBuddy). >>> >>> But as long as we do, leaving this responsibility to the ORM module is >>> the >>> right thing to do IMO. E.g. what if a JPA provider doesn't need Javassist >>> at all? Still JipiJapa would currently add it to the deployment. >>> >>> I've done the following changes locally: >>> >>> 1) Altered JPADependencyProcessor to not add the Javassist dependency to >>> the deployment >>> 2) Altered module.xml of jipijapa-hibernate5 to not depend on Javassist >>> 3) Added a new module for the latest Javassist >>> 4) Altered module.xml of ORM itself to depend on that new module *and* >>> re-export it >>> >>> With all this in place, the tests in Hibernate Search pass successfully. >>> >>> Scott, do you think we can try another PR with that? Again, it doesn't >>> change things in terms of exposure of Javassist to the application (it is >>> exposed, just as it was before). But it puts the responsibility for doing >>> so to ORM's module, allowing us (via the ORM module ZIP we provide) to >>> expose a newer Javassist version as needed. >>> >>> Note that 2 - 4 can be done via the ORM module ZIP. But 1) is a change >>> that >>> needs to be done on the WF side, at least I don't see how this could be >>> overridden? >>> >>> I.e. the module ZIP is rather pointless atm. and we don't have a good way >>> to put the latest ORM into WF user's hands. Would be nice to change this. >>> >>> >> Is the ORM testsuite building the WildFly app server from source? >>> > > >>> > > >>> > > Good god no :) >>> > > >>> > > >>> > >> >>> > >> Other option would be to use ByteBuddy to generate proxies instead >>> of >>> > >> Javassist to eliminate the application dependency on the Javassist >>> > >> runtime classes. >>> > > >>> > > >>> > > >>> > > Rafael Winterhalter is actually pretty far along on defining support >>> for >>> > Byte Buddy in Hibernate[1]. So that might soon be an option. >>> > > >>> > > [1] https://hibernate.atlassian.net/browse/HHH-11152 >>> > > >>> > +100 :) >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > From gunnar at hibernate.org Thu Oct 27 06:29:50 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 27 Oct 2016 12:29:50 +0200 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: JPADependencyProcessor deals with adding JPA dependencies generally (i.e. it works for whatever JPA provider is configured), so it seems reasonable by itself. But as said shouldn't be adding the dependency to Javassist as that's better left to the module(s) of the specific provider(s) needing it. 2016-10-27 12:12 GMT+02:00 Sanne Grinovero : > Ok well that's also odd isn't it? > > On 27 Oct 2016 10:38, "Gunnar Morling" wrote: > >> No, JPADependencyProcessor - which is adding the dependency - is part of >> "wildfly-jpa", not "jipijapa-hibernate". >> >> 2016-10-27 11:23 GMT+02:00 Sanne Grinovero : >> >>> We could fix 1) as well by incorporating the sources for >>> jipijapa-hibernate52 in ORM. >>> >>> I think it belongs within Hibernate, as it won't be the last time that a >>> new ORM version requires some adaptation of bootstrap. >>> >>> On 27 Oct 2016 09:51, "Gunnar Morling" wrote: >>> >>>> Hi, >>>> >>>> 2016-10-27 4:27 GMT+02:00 Scott Marlow : >>>> >>>> > >>>> > > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM >>>> module >>>> > (the WF module) export Javassist. Not the application. >>>> > >>>> >>>> Right, Hibernate ORM's module should be the one exposing it, not the >>>> application nor JipiJapa. >>>> >>>> This allows the ORM module to expose the right version of Javassist (or >>>> none at all eventually) without requiring JipiJapa to have the knowledge >>>> about this. As things stand, Javassist can be considered as part of >>>> ORM's >>>> API, hence it's module.xml should be the one making it available to the >>>> user. >>>> >>>> Of course eventually we don't want to expose Javassist at all, but as >>>> long >>>> as we do, the ORM module should be in charge of doing so. >>>> >>>> > > >>>> > >>>> > I agree, that is what our WF pull request did, which I think is an >>>> > incremental improvement but that wasn't approved for the reason I >>>> gave. >>>> > >>>> >>>> I don't quite get the reasoning here. We all agree that Javassist >>>> shouldn't >>>> be exposed at all (and there is good progress being made towards this by >>>> using ByteBuddy). >>>> >>>> But as long as we do, leaving this responsibility to the ORM module is >>>> the >>>> right thing to do IMO. E.g. what if a JPA provider doesn't need >>>> Javassist >>>> at all? Still JipiJapa would currently add it to the deployment. >>>> >>>> I've done the following changes locally: >>>> >>>> 1) Altered JPADependencyProcessor to not add the Javassist dependency to >>>> the deployment >>>> 2) Altered module.xml of jipijapa-hibernate5 to not depend on Javassist >>>> 3) Added a new module for the latest Javassist >>>> 4) Altered module.xml of ORM itself to depend on that new module *and* >>>> re-export it >>>> >>>> With all this in place, the tests in Hibernate Search pass successfully. >>>> >>>> Scott, do you think we can try another PR with that? Again, it doesn't >>>> change things in terms of exposure of Javassist to the application (it >>>> is >>>> exposed, just as it was before). But it puts the responsibility for >>>> doing >>>> so to ORM's module, allowing us (via the ORM module ZIP we provide) to >>>> expose a newer Javassist version as needed. >>>> >>>> Note that 2 - 4 can be done via the ORM module ZIP. But 1) is a change >>>> that >>>> needs to be done on the WF side, at least I don't see how this could be >>>> overridden? >>>> >>>> I.e. the module ZIP is rather pointless atm. and we don't have a good >>>> way >>>> to put the latest ORM into WF user's hands. Would be nice to change >>>> this. >>>> >>>> >> Is the ORM testsuite building the WildFly app server from source? >>>> > > >>>> > > >>>> > > Good god no :) >>>> > > >>>> > > >>>> > >> >>>> > >> Other option would be to use ByteBuddy to generate proxies instead >>>> of >>>> > >> Javassist to eliminate the application dependency on the Javassist >>>> > >> runtime classes. >>>> > > >>>> > > >>>> > > >>>> > > Rafael Winterhalter is actually pretty far along on defining >>>> support for >>>> > Byte Buddy in Hibernate[1]. So that might soon be an option. >>>> > > >>>> > > [1] https://hibernate.atlassian.net/browse/HHH-11152 >>>> > > >>>> > +100 :) >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >> From smarlow at redhat.com Thu Oct 27 08:38:49 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 27 Oct 2016 08:38:49 -0400 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: Only a WildFly deployment unit processor (DUP) can add dependencies to an application deployment. Jipijapa is not a DUP. On Thu, Oct 27, 2016 at 6:12 AM, Sanne Grinovero wrote: > Ok well that's also odd isn't it? > > > On 27 Oct 2016 10:38, "Gunnar Morling" wrote: >> >> No, JPADependencyProcessor - which is adding the dependency - is part of >> "wildfly-jpa", not "jipijapa-hibernate". >> >> >> 2016-10-27 11:23 GMT+02:00 Sanne Grinovero : >>> >>> We could fix 1) as well by incorporating the sources for >>> jipijapa-hibernate52 in ORM. >>> >>> I think it belongs within Hibernate, as it won't be the last time that a >>> new ORM version requires some adaptation of bootstrap. >>> >>> >>> On 27 Oct 2016 09:51, "Gunnar Morling" wrote: >>>> >>>> Hi, >>>> >>>> 2016-10-27 4:27 GMT+02:00 Scott Marlow : >>>> >>>> > >>>> > > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM >>>> > > module >>>> > (the WF module) export Javassist. Not the application. >>>> > >>>> >>>> Right, Hibernate ORM's module should be the one exposing it, not the >>>> application nor JipiJapa. >>>> >>>> This allows the ORM module to expose the right version of Javassist (or >>>> none at all eventually) without requiring JipiJapa to have the knowledge >>>> about this. As things stand, Javassist can be considered as part of >>>> ORM's >>>> API, hence it's module.xml should be the one making it available to the >>>> user. >>>> >>>> Of course eventually we don't want to expose Javassist at all, but as >>>> long >>>> as we do, the ORM module should be in charge of doing so. >>>> >>>> > > >>>> > >>>> > I agree, that is what our WF pull request did, which I think is an >>>> > incremental improvement but that wasn't approved for the reason I >>>> > gave. >>>> > >>>> >>>> I don't quite get the reasoning here. We all agree that Javassist >>>> shouldn't >>>> be exposed at all (and there is good progress being made towards this by >>>> using ByteBuddy). >>>> >>>> But as long as we do, leaving this responsibility to the ORM module is >>>> the >>>> right thing to do IMO. E.g. what if a JPA provider doesn't need >>>> Javassist >>>> at all? Still JipiJapa would currently add it to the deployment. >>>> >>>> I've done the following changes locally: >>>> >>>> 1) Altered JPADependencyProcessor to not add the Javassist dependency to >>>> the deployment >>>> 2) Altered module.xml of jipijapa-hibernate5 to not depend on Javassist >>>> 3) Added a new module for the latest Javassist >>>> 4) Altered module.xml of ORM itself to depend on that new module *and* >>>> re-export it >>>> >>>> With all this in place, the tests in Hibernate Search pass successfully. >>>> >>>> Scott, do you think we can try another PR with that? Again, it doesn't >>>> change things in terms of exposure of Javassist to the application (it >>>> is >>>> exposed, just as it was before). But it puts the responsibility for >>>> doing >>>> so to ORM's module, allowing us (via the ORM module ZIP we provide) to >>>> expose a newer Javassist version as needed. >>>> >>>> Note that 2 - 4 can be done via the ORM module ZIP. But 1) is a change >>>> that >>>> needs to be done on the WF side, at least I don't see how this could be >>>> overridden? >>>> >>>> I.e. the module ZIP is rather pointless atm. and we don't have a good >>>> way >>>> to put the latest ORM into WF user's hands. Would be nice to change >>>> this. >>>> >>>> >> Is the ORM testsuite building the WildFly app server from source? >>>> > > >>>> > > >>>> > > Good god no :) >>>> > > >>>> > > >>>> > >> >>>> > >> Other option would be to use ByteBuddy to generate proxies instead >>>> > >> of >>>> > >> Javassist to eliminate the application dependency on the Javassist >>>> > >> runtime classes. >>>> > > >>>> > > >>>> > > >>>> > > Rafael Winterhalter is actually pretty far along on defining support >>>> > > for >>>> > Byte Buddy in Hibernate[1]. So that might soon be an option. >>>> > > >>>> > > [1] https://hibernate.atlassian.net/browse/HHH-11152 >>>> > > >>>> > +100 :) >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > From smarlow at redhat.com Thu Oct 27 08:59:09 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 27 Oct 2016 08:59:09 -0400 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: On Thu, Oct 27, 2016 at 4:49 AM, Gunnar Morling wrote: > Hi, Hi, > > 2016-10-27 4:27 GMT+02:00 Scott Marlow : >> >> >> > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module >> > (the WF module) export Javassist. Not the application. > > > Right, Hibernate ORM's module should be the one exposing it, not the > application nor JipiJapa. JipiJapa has zero to do with this, we will create a pr later today to remove the unneeded dependencies, which has nothing to do with this conversation. > > I've done the following changes locally: > > 1) Altered JPADependencyProcessor to not add the Javassist dependency to the > deployment > 2) Altered module.xml of jipijapa-hibernate5 to not depend on Javassist I did the same locally, which is an unused dependency. I removed some other unused dependencies other as well. Gail and I will talk later about removing these unused dependencies. > 3) Added a new module for the latest Javassist > 4) Altered module.xml of ORM itself to depend on that new module *and* > re-export it > > With all this in place, the tests in Hibernate Search pass successfully. > > Scott, do you think we can try another PR with that? Again, it doesn't https://github.com/wildfly/wildfly/pull/8474 is still open, no need for a new PR when we already have an open one, with one exception, as I didn't actually remove the export of Javassist to the application classpath. I forget why. I'll try that locally and run the WildFly testsuite to see if there is a failure. From sanne at hibernate.org Thu Oct 27 09:02:50 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 27 Oct 2016 14:02:50 +0100 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: On 27 October 2016 at 13:38, Scott Marlow wrote: > Only a WildFly deployment unit processor (DUP) can add dependencies to > an application deployment. Jipijapa is not a DUP. Ah, thanks Scott that helps to understand this all. Still, I agree with Gunnar that any additional dependencies belong in the static module definition of the JPA provider implementation. Could you remove that javassist injection please? While at it, are other dependencies being injected? Would be nice to remove as much as possible, and leave it up to the specific implementations to choose its dependencies. Thanks, Sanne > > On Thu, Oct 27, 2016 at 6:12 AM, Sanne Grinovero wrote: >> Ok well that's also odd isn't it? >> >> >> On 27 Oct 2016 10:38, "Gunnar Morling" wrote: >>> >>> No, JPADependencyProcessor - which is adding the dependency - is part of >>> "wildfly-jpa", not "jipijapa-hibernate". >>> >>> >>> 2016-10-27 11:23 GMT+02:00 Sanne Grinovero : >>>> >>>> We could fix 1) as well by incorporating the sources for >>>> jipijapa-hibernate52 in ORM. >>>> >>>> I think it belongs within Hibernate, as it won't be the last time that a >>>> new ORM version requires some adaptation of bootstrap. >>>> >>>> >>>> On 27 Oct 2016 09:51, "Gunnar Morling" wrote: >>>>> >>>>> Hi, >>>>> >>>>> 2016-10-27 4:27 GMT+02:00 Scott Marlow : >>>>> >>>>> > >>>>> > > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM >>>>> > > module >>>>> > (the WF module) export Javassist. Not the application. >>>>> > >>>>> >>>>> Right, Hibernate ORM's module should be the one exposing it, not the >>>>> application nor JipiJapa. >>>>> >>>>> This allows the ORM module to expose the right version of Javassist (or >>>>> none at all eventually) without requiring JipiJapa to have the knowledge >>>>> about this. As things stand, Javassist can be considered as part of >>>>> ORM's >>>>> API, hence it's module.xml should be the one making it available to the >>>>> user. >>>>> >>>>> Of course eventually we don't want to expose Javassist at all, but as >>>>> long >>>>> as we do, the ORM module should be in charge of doing so. >>>>> >>>>> > > >>>>> > >>>>> > I agree, that is what our WF pull request did, which I think is an >>>>> > incremental improvement but that wasn't approved for the reason I >>>>> > gave. >>>>> > >>>>> >>>>> I don't quite get the reasoning here. We all agree that Javassist >>>>> shouldn't >>>>> be exposed at all (and there is good progress being made towards this by >>>>> using ByteBuddy). >>>>> >>>>> But as long as we do, leaving this responsibility to the ORM module is >>>>> the >>>>> right thing to do IMO. E.g. what if a JPA provider doesn't need >>>>> Javassist >>>>> at all? Still JipiJapa would currently add it to the deployment. >>>>> >>>>> I've done the following changes locally: >>>>> >>>>> 1) Altered JPADependencyProcessor to not add the Javassist dependency to >>>>> the deployment >>>>> 2) Altered module.xml of jipijapa-hibernate5 to not depend on Javassist >>>>> 3) Added a new module for the latest Javassist >>>>> 4) Altered module.xml of ORM itself to depend on that new module *and* >>>>> re-export it >>>>> >>>>> With all this in place, the tests in Hibernate Search pass successfully. >>>>> >>>>> Scott, do you think we can try another PR with that? Again, it doesn't >>>>> change things in terms of exposure of Javassist to the application (it >>>>> is >>>>> exposed, just as it was before). But it puts the responsibility for >>>>> doing >>>>> so to ORM's module, allowing us (via the ORM module ZIP we provide) to >>>>> expose a newer Javassist version as needed. >>>>> >>>>> Note that 2 - 4 can be done via the ORM module ZIP. But 1) is a change >>>>> that >>>>> needs to be done on the WF side, at least I don't see how this could be >>>>> overridden? >>>>> >>>>> I.e. the module ZIP is rather pointless atm. and we don't have a good >>>>> way >>>>> to put the latest ORM into WF user's hands. Would be nice to change >>>>> this. >>>>> >>>>> >> Is the ORM testsuite building the WildFly app server from source? >>>>> > > >>>>> > > >>>>> > > Good god no :) >>>>> > > >>>>> > > >>>>> > >> >>>>> > >> Other option would be to use ByteBuddy to generate proxies instead >>>>> > >> of >>>>> > >> Javassist to eliminate the application dependency on the Javassist >>>>> > >> runtime classes. >>>>> > > >>>>> > > >>>>> > > >>>>> > > Rafael Winterhalter is actually pretty far along on defining support >>>>> > > for >>>>> > Byte Buddy in Hibernate[1]. So that might soon be an option. >>>>> > > >>>>> > > [1] https://hibernate.atlassian.net/browse/HHH-11152 >>>>> > > >>>>> > +100 :) >>>>> > >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> >> From gunnar at hibernate.org Thu Oct 27 09:40:23 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 27 Oct 2016 15:40:23 +0200 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: 2016-10-27 14:59 GMT+02:00 Scott Marlow : > On Thu, Oct 27, 2016 at 4:49 AM, Gunnar Morling > wrote: > > Hi, > > Hi, > > > > > 2016-10-27 4:27 GMT+02:00 Scott Marlow : > >> > >> > >> > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM > module > >> > (the WF module) export Javassist. Not the application. > > > > > > Right, Hibernate ORM's module should be the one exposing it, not the > > application nor JipiJapa. > > JipiJapa has zero to do with this, we will create a pr later today to > remove the unneeded dependencies, which has nothing to do with this > conversation. > Yes, there is this superfluous dependency, thanks for removing it. But the other issue is hat in JPADependencyProcessor (that's what I meant when referring to "JipiJapa", sorry if that's not correct), a dependency to Javassist is injected. This shouldn't be the case for the reasons I've pointed out. Also with the PR https://github.com/wildfly/wildfly/pull/8474 you mentioned this seems to be the case. > > > > > > I've done the following changes locally: > > > > 1) Altered JPADependencyProcessor to not add the Javassist dependency to > the > > deployment > > 2) Altered module.xml of jipijapa-hibernate5 to not depend on Javassist > > I did the same locally, which is an unused dependency. I removed some > other unused dependencies other as well. Gail and I will talk later > about removing these unused dependencies. > > > 3) Added a new module for the latest Javassist > > 4) Altered module.xml of ORM itself to depend on that new module *and* > > re-export it > > > > With all this in place, the tests in Hibernate Search pass successfully. > > > > Scott, do you think we can try another PR with that? Again, it doesn't > > https://github.com/wildfly/wildfly/pull/8474 is still open, no need > for a new PR when we already have an open one, with one exception, as > I didn't actually remove the export of Javassist to the application > classpath. I forget why. I'll try that locally and run the WildFly > testsuite to see if there is a failure. > From smarlow at redhat.com Thu Oct 27 09:55:46 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 27 Oct 2016 09:55:46 -0400 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: I remember now why I didn't remove the JPADependencyProcessor injection of Javassist in https://github.com/wildfly/wildfly/pull/8474, it would cause a failure in applications that embeds a copy of the ORM jars but the application doesn't have the Javassisst jars on its classpath. Currently, JPADependencyProcessor ensures that Javassist is available to such an application. I could easily work around the above in the wildfly/testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/HibernateJarsInDeploymentTestCase.java test, however, this would break application compatibility, which is more important. This goes back to around 2011 when we first started auto injecting the Javassist classes to applications that are using Hibernate as a JPA persistence provider. The next time where we would be allowed to break application compatibility, would be on an EAP .zero release. If https://github.com/wildfly/wildfly/pull/8474 ever gets merged into WildFly, perhaps we could enhance JPADependencyProcessor with a persistence unit check for a "don't inject javassist" hint. Or maybe that could help the ORM testsuite now, in which case we could create an independent pull request for the "don't inject javassist" hint handling. On Thu, Oct 27, 2016 at 9:40 AM, Gunnar Morling wrote: > > > 2016-10-27 14:59 GMT+02:00 Scott Marlow : >> >> On Thu, Oct 27, 2016 at 4:49 AM, Gunnar Morling >> wrote: >> > Hi, >> >> Hi, >> >> > >> > 2016-10-27 4:27 GMT+02:00 Scott Marlow : >> >> >> >> >> >> > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM >> >> > module >> >> > (the WF module) export Javassist. Not the application. >> > >> > >> > Right, Hibernate ORM's module should be the one exposing it, not the >> > application nor JipiJapa. >> >> JipiJapa has zero to do with this, we will create a pr later today to >> remove the unneeded dependencies, which has nothing to do with this >> conversation. > > > Yes, there is this superfluous dependency, thanks for removing it. > > But the other issue is hat in JPADependencyProcessor (that's what I meant > when referring to "JipiJapa", sorry if that's not correct), a dependency to > Javassist is injected. This shouldn't be the case for the reasons I've > pointed out. Also with the PR https://github.com/wildfly/wildfly/pull/8474 > you mentioned this seems to be the case. >> >> >> > >> > I've done the following changes locally: >> > >> > 1) Altered JPADependencyProcessor to not add the Javassist dependency to >> > the >> > deployment >> > 2) Altered module.xml of jipijapa-hibernate5 to not depend on Javassist >> >> I did the same locally, which is an unused dependency. I removed some >> other unused dependencies other as well. Gail and I will talk later >> about removing these unused dependencies. >> >> > 3) Added a new module for the latest Javassist >> > 4) Altered module.xml of ORM itself to depend on that new module *and* >> > re-export it >> > >> > With all this in place, the tests in Hibernate Search pass successfully. >> > >> > Scott, do you think we can try another PR with that? Again, it doesn't >> >> https://github.com/wildfly/wildfly/pull/8474 is still open, no need >> for a new PR when we already have an open one, with one exception, as >> I didn't actually remove the export of Javassist to the application >> classpath. I forget why. I'll try that locally and run the WildFly >> testsuite to see if there is a failure. > > From steve at hibernate.org Thu Oct 27 10:07:11 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 27 Oct 2016 14:07:11 +0000 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: I would argue that that is a bad deployment. IMO if you supply your own Hibernate jars, you'd be responsible for supplying its dependency jars as well. Javassist is currently a non-optional dependency of ORM. On Thu, Oct 27, 2016 at 8:55 AM Scott Marlow wrote: > I remember now why I didn't remove the JPADependencyProcessor > injection of Javassist in > https://github.com/wildfly/wildfly/pull/8474, it would cause a failure > in applications that embeds a copy of the ORM jars but the application > doesn't have the Javassisst jars on its classpath. Currently, > JPADependencyProcessor ensures that Javassist is available to such an > application. > > I could easily work around the above in the > > wildfly/testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/HibernateJarsInDeploymentTestCase.java > test, however, this would break application compatibility, which is > more important. This goes back to around 2011 when we first started > auto injecting the Javassist classes to applications that are using > Hibernate as a JPA persistence provider. The next time where we would > be allowed to break application compatibility, would be on an EAP > .zero release. > > If https://github.com/wildfly/wildfly/pull/8474 ever gets merged into > WildFly, perhaps we could enhance JPADependencyProcessor with a > persistence unit check for a "don't inject javassist" hint. Or maybe > that could help the ORM testsuite now, in which case we could create > an independent pull request for the "don't inject javassist" hint > handling. > > On Thu, Oct 27, 2016 at 9:40 AM, Gunnar Morling > wrote: > > > > > > 2016-10-27 14:59 GMT+02:00 Scott Marlow : > >> > >> On Thu, Oct 27, 2016 at 4:49 AM, Gunnar Morling > >> wrote: > >> > Hi, > >> > >> Hi, > >> > >> > > >> > 2016-10-27 4:27 GMT+02:00 Scott Marlow : > >> >> > >> >> > >> >> > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM > >> >> > module > >> >> > (the WF module) export Javassist. Not the application. > >> > > >> > > >> > Right, Hibernate ORM's module should be the one exposing it, not the > >> > application nor JipiJapa. > >> > >> JipiJapa has zero to do with this, we will create a pr later today to > >> remove the unneeded dependencies, which has nothing to do with this > >> conversation. > > > > > > Yes, there is this superfluous dependency, thanks for removing it. > > > > But the other issue is hat in JPADependencyProcessor (that's what I meant > > when referring to "JipiJapa", sorry if that's not correct), a dependency > to > > Javassist is injected. This shouldn't be the case for the reasons I've > > pointed out. Also with the PR > https://github.com/wildfly/wildfly/pull/8474 > > you mentioned this seems to be the case. > >> > >> > >> > > >> > I've done the following changes locally: > >> > > >> > 1) Altered JPADependencyProcessor to not add the Javassist dependency > to > >> > the > >> > deployment > >> > 2) Altered module.xml of jipijapa-hibernate5 to not depend on > Javassist > >> > >> I did the same locally, which is an unused dependency. I removed some > >> other unused dependencies other as well. Gail and I will talk later > >> about removing these unused dependencies. > >> > >> > 3) Added a new module for the latest Javassist > >> > 4) Altered module.xml of ORM itself to depend on that new module *and* > >> > re-export it > >> > > >> > With all this in place, the tests in Hibernate Search pass > successfully. > >> > > >> > Scott, do you think we can try another PR with that? Again, it doesn't > >> > >> https://github.com/wildfly/wildfly/pull/8474 is still open, no need > >> for a new PR when we already have an open one, with one exception, as > >> I didn't actually remove the export of Javassist to the application > >> classpath. I forget why. I'll try that locally and run the WildFly > >> testsuite to see if there is a failure. > > > > > From gunnar at hibernate.org Thu Oct 27 10:09:03 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 27 Oct 2016 16:09:03 +0200 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: 2016-10-27 15:55 GMT+02:00 Scott Marlow : > I remember now why I didn't remove the JPADependencyProcessor > injection of Javassist in > https://github.com/wildfly/wildfly/pull/8474, it would cause a failure > in applications that embeds a copy of the ORM jars but the application > doesn't have the Javassisst jars on its classpath. Currently, > JPADependencyProcessor ensures that Javassist is available to such an > application. > Why would one support such use case? If a user is adding their own ORM in the app, I'd expect them to do it completely, with all the dependencies of *that version*. I mean, how would you even know whether the Javassist version you are adding is the right one? And what happens if the user *is* providing Javassist with the app? Tbh. allowing the user to add their own ORM in the app seems even more a justification to not inject Javassist. I could easily work around the above in the > wildfly/testsuite/compat/src/test/java/org/jboss/as/test/ > compat/jpa/hibernate/HibernateJarsInDeploymentTestCase.java > test, however, this would break application compatibility, which is > more important. This goes back to around 2011 when we first started > auto injecting the Javassist classes to applications that are using > Hibernate as a JPA persistence provider. The next time where we would > be allowed to break application compatibility, would be on an EAP > .zero release. > > If https://github.com/wildfly/wildfly/pull/8474 ever gets merged into > WildFly, perhaps we could enhance JPADependencyProcessor with a > persistence unit check for a "don't inject javassist" hint. Or maybe > that could help the ORM testsuite now, in which case we could create > an independent pull request for the "don't inject javassist" hint > handling. > Would that hint be another "knob" to be set by the user? If so, I wouldn't like it too much, it's just such a technical detail we shouldn't bother the user with. Another idea: can you examine the ORM module you are about to add and check wether it exports Javassist and if so, not auto-inject Javassist? Not sure whether it's doable in terms of capabilities of the module API. > > On Thu, Oct 27, 2016 at 9:40 AM, Gunnar Morling > wrote: > > > > > > 2016-10-27 14:59 GMT+02:00 Scott Marlow : > >> > >> On Thu, Oct 27, 2016 at 4:49 AM, Gunnar Morling > >> wrote: > >> > Hi, > >> > >> Hi, > >> > >> > > >> > 2016-10-27 4:27 GMT+02:00 Scott Marlow : > >> >> > >> >> > >> >> > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM > >> >> > module > >> >> > (the WF module) export Javassist. Not the application. > >> > > >> > > >> > Right, Hibernate ORM's module should be the one exposing it, not the > >> > application nor JipiJapa. > >> > >> JipiJapa has zero to do with this, we will create a pr later today to > >> remove the unneeded dependencies, which has nothing to do with this > >> conversation. > > > > > > Yes, there is this superfluous dependency, thanks for removing it. > > > > But the other issue is hat in JPADependencyProcessor (that's what I meant > > when referring to "JipiJapa", sorry if that's not correct), a dependency > to > > Javassist is injected. This shouldn't be the case for the reasons I've > > pointed out. Also with the PR https://github.com/wildfly/ > wildfly/pull/8474 > > you mentioned this seems to be the case. > >> > >> > >> > > >> > I've done the following changes locally: > >> > > >> > 1) Altered JPADependencyProcessor to not add the Javassist dependency > to > >> > the > >> > deployment > >> > 2) Altered module.xml of jipijapa-hibernate5 to not depend on > Javassist > >> > >> I did the same locally, which is an unused dependency. I removed some > >> other unused dependencies other as well. Gail and I will talk later > >> about removing these unused dependencies. > >> > >> > 3) Added a new module for the latest Javassist > >> > 4) Altered module.xml of ORM itself to depend on that new module *and* > >> > re-export it > >> > > >> > With all this in place, the tests in Hibernate Search pass > successfully. > >> > > >> > Scott, do you think we can try another PR with that? Again, it doesn't > >> > >> https://github.com/wildfly/wildfly/pull/8474 is still open, no need > >> for a new PR when we already have an open one, with one exception, as > >> I didn't actually remove the export of Javassist to the application > >> classpath. I forget why. I'll try that locally and run the WildFly > >> testsuite to see if there is a failure. > > > > > From smarlow at redhat.com Thu Oct 27 10:11:25 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 27 Oct 2016 10:11:25 -0400 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: We can call it a bad deployment, however, at the same time, we don't want to break application compatibility in a way that requires the application to be cracked open and modified (even if the fix is just a simple MANIFEST.MF change). On Thu, Oct 27, 2016 at 10:07 AM, Steve Ebersole wrote: > I would argue that that is a bad deployment. IMO if you supply your own > Hibernate jars, you'd be responsible for supplying its dependency jars as > well. Javassist is currently a non-optional dependency of ORM. > > On Thu, Oct 27, 2016 at 8:55 AM Scott Marlow wrote: >> >> I remember now why I didn't remove the JPADependencyProcessor >> injection of Javassist in >> https://github.com/wildfly/wildfly/pull/8474, it would cause a failure >> in applications that embeds a copy of the ORM jars but the application >> doesn't have the Javassisst jars on its classpath. Currently, >> JPADependencyProcessor ensures that Javassist is available to such an >> application. >> >> I could easily work around the above in the >> >> wildfly/testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/HibernateJarsInDeploymentTestCase.java >> test, however, this would break application compatibility, which is >> more important. This goes back to around 2011 when we first started >> auto injecting the Javassist classes to applications that are using >> Hibernate as a JPA persistence provider. The next time where we would >> be allowed to break application compatibility, would be on an EAP >> .zero release. >> >> If https://github.com/wildfly/wildfly/pull/8474 ever gets merged into >> WildFly, perhaps we could enhance JPADependencyProcessor with a >> persistence unit check for a "don't inject javassist" hint. Or maybe >> that could help the ORM testsuite now, in which case we could create >> an independent pull request for the "don't inject javassist" hint >> handling. >> >> On Thu, Oct 27, 2016 at 9:40 AM, Gunnar Morling >> wrote: >> > >> > >> > 2016-10-27 14:59 GMT+02:00 Scott Marlow : >> >> >> >> On Thu, Oct 27, 2016 at 4:49 AM, Gunnar Morling >> >> wrote: >> >> > Hi, >> >> >> >> Hi, >> >> >> >> > >> >> > 2016-10-27 4:27 GMT+02:00 Scott Marlow : >> >> >> >> >> >> >> >> >> > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM >> >> >> > module >> >> >> > (the WF module) export Javassist. Not the application. >> >> > >> >> > >> >> > Right, Hibernate ORM's module should be the one exposing it, not the >> >> > application nor JipiJapa. >> >> >> >> JipiJapa has zero to do with this, we will create a pr later today to >> >> remove the unneeded dependencies, which has nothing to do with this >> >> conversation. >> > >> > >> > Yes, there is this superfluous dependency, thanks for removing it. >> > >> > But the other issue is hat in JPADependencyProcessor (that's what I >> > meant >> > when referring to "JipiJapa", sorry if that's not correct), a dependency >> > to >> > Javassist is injected. This shouldn't be the case for the reasons I've >> > pointed out. Also with the PR >> > https://github.com/wildfly/wildfly/pull/8474 >> > you mentioned this seems to be the case. >> >> >> >> >> >> > >> >> > I've done the following changes locally: >> >> > >> >> > 1) Altered JPADependencyProcessor to not add the Javassist dependency >> >> > to >> >> > the >> >> > deployment >> >> > 2) Altered module.xml of jipijapa-hibernate5 to not depend on >> >> > Javassist >> >> >> >> I did the same locally, which is an unused dependency. I removed some >> >> other unused dependencies other as well. Gail and I will talk later >> >> about removing these unused dependencies. >> >> >> >> > 3) Added a new module for the latest Javassist >> >> > 4) Altered module.xml of ORM itself to depend on that new module >> >> > *and* >> >> > re-export it >> >> > >> >> > With all this in place, the tests in Hibernate Search pass >> >> > successfully. >> >> > >> >> > Scott, do you think we can try another PR with that? Again, it >> >> > doesn't >> >> >> >> https://github.com/wildfly/wildfly/pull/8474 is still open, no need >> >> for a new PR when we already have an open one, with one exception, as >> >> I didn't actually remove the export of Javassist to the application >> >> classpath. I forget why. I'll try that locally and run the WildFly >> >> testsuite to see if there is a failure. >> > >> > From steve at hibernate.org Thu Oct 27 10:14:18 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 27 Oct 2016 14:14:18 +0000 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: Dunno. To me this is a bug that Jipijapa/WF/DUP adds this dependency at all. How that gets resolved or not is completely up to Jipijapa/WF/DUP as it is the one(s) doing this. There is nothing Hibernate can do here. On Thu, Oct 27, 2016 at 9:11 AM Scott Marlow wrote: > We can call it a bad deployment, however, at the same time, we don't > want to break application compatibility in a way that requires the > application to be cracked open and modified (even if the fix is just a > simple MANIFEST.MF change). > > On Thu, Oct 27, 2016 at 10:07 AM, Steve Ebersole > wrote: > > I would argue that that is a bad deployment. IMO if you supply your own > > Hibernate jars, you'd be responsible for supplying its dependency jars as > > well. Javassist is currently a non-optional dependency of ORM. > > > > On Thu, Oct 27, 2016 at 8:55 AM Scott Marlow wrote: > >> > >> I remember now why I didn't remove the JPADependencyProcessor > >> injection of Javassist in > >> https://github.com/wildfly/wildfly/pull/8474, it would cause a failure > >> in applications that embeds a copy of the ORM jars but the application > >> doesn't have the Javassisst jars on its classpath. Currently, > >> JPADependencyProcessor ensures that Javassist is available to such an > >> application. > >> > >> I could easily work around the above in the > >> > >> > wildfly/testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/HibernateJarsInDeploymentTestCase.java > >> test, however, this would break application compatibility, which is > >> more important. This goes back to around 2011 when we first started > >> auto injecting the Javassist classes to applications that are using > >> Hibernate as a JPA persistence provider. The next time where we would > >> be allowed to break application compatibility, would be on an EAP > >> .zero release. > >> > >> If https://github.com/wildfly/wildfly/pull/8474 ever gets merged into > >> WildFly, perhaps we could enhance JPADependencyProcessor with a > >> persistence unit check for a "don't inject javassist" hint. Or maybe > >> that could help the ORM testsuite now, in which case we could create > >> an independent pull request for the "don't inject javassist" hint > >> handling. > >> > >> On Thu, Oct 27, 2016 at 9:40 AM, Gunnar Morling > >> wrote: > >> > > >> > > >> > 2016-10-27 14:59 GMT+02:00 Scott Marlow : > >> >> > >> >> On Thu, Oct 27, 2016 at 4:49 AM, Gunnar Morling < > gunnar at hibernate.org> > >> >> wrote: > >> >> > Hi, > >> >> > >> >> Hi, > >> >> > >> >> > > >> >> > 2016-10-27 4:27 GMT+02:00 Scott Marlow : > >> >> >> > >> >> >> > >> >> >> > Unless I am mistaken, Gunnar is suggesting that the Hibernate > ORM > >> >> >> > module > >> >> >> > (the WF module) export Javassist. Not the application. > >> >> > > >> >> > > >> >> > Right, Hibernate ORM's module should be the one exposing it, not > the > >> >> > application nor JipiJapa. > >> >> > >> >> JipiJapa has zero to do with this, we will create a pr later today to > >> >> remove the unneeded dependencies, which has nothing to do with this > >> >> conversation. > >> > > >> > > >> > Yes, there is this superfluous dependency, thanks for removing it. > >> > > >> > But the other issue is hat in JPADependencyProcessor (that's what I > >> > meant > >> > when referring to "JipiJapa", sorry if that's not correct), a > dependency > >> > to > >> > Javassist is injected. This shouldn't be the case for the reasons I've > >> > pointed out. Also with the PR > >> > https://github.com/wildfly/wildfly/pull/8474 > >> > you mentioned this seems to be the case. > >> >> > >> >> > >> >> > > >> >> > I've done the following changes locally: > >> >> > > >> >> > 1) Altered JPADependencyProcessor to not add the Javassist > dependency > >> >> > to > >> >> > the > >> >> > deployment > >> >> > 2) Altered module.xml of jipijapa-hibernate5 to not depend on > >> >> > Javassist > >> >> > >> >> I did the same locally, which is an unused dependency. I removed > some > >> >> other unused dependencies other as well. Gail and I will talk later > >> >> about removing these unused dependencies. > >> >> > >> >> > 3) Added a new module for the latest Javassist > >> >> > 4) Altered module.xml of ORM itself to depend on that new module > >> >> > *and* > >> >> > re-export it > >> >> > > >> >> > With all this in place, the tests in Hibernate Search pass > >> >> > successfully. > >> >> > > >> >> > Scott, do you think we can try another PR with that? Again, it > >> >> > doesn't > >> >> > >> >> https://github.com/wildfly/wildfly/pull/8474 is still open, no need > >> >> for a new PR when we already have an open one, with one exception, as > >> >> I didn't actually remove the export of Javassist to the application > >> >> classpath. I forget why. I'll try that locally and run the WildFly > >> >> testsuite to see if there is a failure. > >> > > >> > > From smarlow at redhat.com Thu Oct 27 10:39:02 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 27 Oct 2016 10:39:02 -0400 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: On Thu, Oct 27, 2016 at 10:09 AM, Gunnar Morling wrote: > 2016-10-27 15:55 GMT+02:00 Scott Marlow : >> >> I remember now why I didn't remove the JPADependencyProcessor >> injection of Javassist in >> https://github.com/wildfly/wildfly/pull/8474, it would cause a failure >> in applications that embeds a copy of the ORM jars but the application >> doesn't have the Javassisst jars on its classpath. Currently, >> JPADependencyProcessor ensures that Javassist is available to such an >> application. > > > Why would one support such use case? If a user is adding their own ORM in > the app, I'd expect them to do it completely, with all the dependencies of > *that version*. I mean, how would you even know whether the Javassist > version you are adding is the right one? I think that exporting the Javassist classes from ORM was considered a bad idea back then in 2011. Now, we don't want to lose application compatibility. > > And what happens if the user *is* providing Javassist with the app? Tbh. > allowing the user to add their own ORM in the app seems even more a > justification to not inject Javassist. Sure, lets get to the point where we can allow the user to have their own Javassist. > >> I could easily work around the above in the >> >> wildfly/testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/HibernateJarsInDeploymentTestCase.java >> test, however, this would break application compatibility, which is >> more important. This goes back to around 2011 when we first started >> auto injecting the Javassist classes to applications that are using >> Hibernate as a JPA persistence provider. The next time where we would >> be allowed to break application compatibility, would be on an EAP >> .zero release. >> >> If https://github.com/wildfly/wildfly/pull/8474 ever gets merged into >> WildFly, perhaps we could enhance JPADependencyProcessor with a >> persistence unit check for a "don't inject javassist" hint. Or maybe >> that could help the ORM testsuite now, in which case we could create >> an independent pull request for the "don't inject javassist" hint >> handling. > > > Would that hint be another "knob" to be set by the user? If so, I wouldn't > like it too much, it's just such a technical detail we shouldn't bother the > user with. Yes, it would be another knob, however, it is likely to only be used by the Hibernate ORM testsuite, as I haven't heard of any user request for this. > > Another idea: can you examine the ORM module you are about to add and check > wether it exports Javassist and if so, not auto-inject Javassist? Not sure > whether it's doable in terms of capabilities of the module API. I'm not 100%, we would likely need to explore what is available from the application deployment org.jboss.as.server.deployment.module.ModuleSpecification at the early deployment phase that JPADependencyProcessor is called in. ModuleSpecification seems to have getSystemDependencies() + getUserDependencies() + getLocalDependencies() calls, but I'm not sure how (deployment) expensive it would be to sequentially walk through each module dependency and look for javassist classes. > >> >> >> On Thu, Oct 27, 2016 at 9:40 AM, Gunnar Morling >> wrote: >> > >> > >> > 2016-10-27 14:59 GMT+02:00 Scott Marlow : >> >> >> >> On Thu, Oct 27, 2016 at 4:49 AM, Gunnar Morling >> >> wrote: >> >> > Hi, >> >> >> >> Hi, >> >> >> >> > >> >> > 2016-10-27 4:27 GMT+02:00 Scott Marlow : >> >> >> >> >> >> >> >> >> > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM >> >> >> > module >> >> >> > (the WF module) export Javassist. Not the application. >> >> > >> >> > >> >> > Right, Hibernate ORM's module should be the one exposing it, not the >> >> > application nor JipiJapa. >> >> >> >> JipiJapa has zero to do with this, we will create a pr later today to >> >> remove the unneeded dependencies, which has nothing to do with this >> >> conversation. >> > >> > >> > Yes, there is this superfluous dependency, thanks for removing it. >> > >> > But the other issue is hat in JPADependencyProcessor (that's what I >> > meant >> > when referring to "JipiJapa", sorry if that's not correct), a dependency >> > to >> > Javassist is injected. This shouldn't be the case for the reasons I've >> > pointed out. Also with the PR >> > https://github.com/wildfly/wildfly/pull/8474 >> > you mentioned this seems to be the case. >> >> >> >> >> >> > >> >> > I've done the following changes locally: >> >> > >> >> > 1) Altered JPADependencyProcessor to not add the Javassist dependency >> >> > to >> >> > the >> >> > deployment >> >> > 2) Altered module.xml of jipijapa-hibernate5 to not depend on >> >> > Javassist >> >> >> >> I did the same locally, which is an unused dependency. I removed some >> >> other unused dependencies other as well. Gail and I will talk later >> >> about removing these unused dependencies. >> >> >> >> > 3) Added a new module for the latest Javassist >> >> > 4) Altered module.xml of ORM itself to depend on that new module >> >> > *and* >> >> > re-export it >> >> > >> >> > With all this in place, the tests in Hibernate Search pass >> >> > successfully. >> >> > >> >> > Scott, do you think we can try another PR with that? Again, it >> >> > doesn't >> >> >> >> https://github.com/wildfly/wildfly/pull/8474 is still open, no need >> >> for a new PR when we already have an open one, with one exception, as >> >> I didn't actually remove the export of Javassist to the application >> >> classpath. I forget why. I'll try that locally and run the WildFly >> >> testsuite to see if there is a failure. >> > >> > > > From guillaume.smet at hibernate.org Thu Oct 27 11:23:08 2016 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Thu, 27 Oct 2016 17:23:08 +0200 Subject: [hibernate-dev] Hibernate Validator 5.3.1.Final is out Message-ID: Hi, I'm pleased to announce the first maintenance release of Hibernate Validator 5.3. For more information, please see the full announcement here: http://in.relation.to/2016/10/27/hibernate-validator-531-final-out/ . Have a nice day! -- Guillaume From smarlow at redhat.com Thu Oct 27 12:10:13 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 27 Oct 2016 12:10:13 -0400 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: I updated https://github.com/wildfly/wildfly/pull/8474 to make a push for applying the pull request and also mentioned the desire to update JPADependencyProcessor to not inject Javassist into applications. Perhaps others from the WildFly team will disagree with me and make an exception to break applications with Hibernate ORM embedded in a small way, that has a tiny (one line change) workaround needed. :-) On Thu, Oct 27, 2016 at 10:39 AM, Scott Marlow wrote: > On Thu, Oct 27, 2016 at 10:09 AM, Gunnar Morling wrote: >> 2016-10-27 15:55 GMT+02:00 Scott Marlow : >>> >>> I remember now why I didn't remove the JPADependencyProcessor >>> injection of Javassist in >>> https://github.com/wildfly/wildfly/pull/8474, it would cause a failure >>> in applications that embeds a copy of the ORM jars but the application >>> doesn't have the Javassisst jars on its classpath. Currently, >>> JPADependencyProcessor ensures that Javassist is available to such an >>> application. >> >> >> Why would one support such use case? If a user is adding their own ORM in >> the app, I'd expect them to do it completely, with all the dependencies of >> *that version*. I mean, how would you even know whether the Javassist >> version you are adding is the right one? > > I think that exporting the Javassist classes from ORM was considered a > bad idea back then in 2011. Now, we don't want to lose application > compatibility. > >> >> And what happens if the user *is* providing Javassist with the app? Tbh. >> allowing the user to add their own ORM in the app seems even more a >> justification to not inject Javassist. > > Sure, lets get to the point where we can allow the user to have their > own Javassist. > >> >>> I could easily work around the above in the >>> >>> wildfly/testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/hibernate/HibernateJarsInDeploymentTestCase.java >>> test, however, this would break application compatibility, which is >>> more important. This goes back to around 2011 when we first started >>> auto injecting the Javassist classes to applications that are using >>> Hibernate as a JPA persistence provider. The next time where we would >>> be allowed to break application compatibility, would be on an EAP >>> .zero release. >>> >>> If https://github.com/wildfly/wildfly/pull/8474 ever gets merged into >>> WildFly, perhaps we could enhance JPADependencyProcessor with a >>> persistence unit check for a "don't inject javassist" hint. Or maybe >>> that could help the ORM testsuite now, in which case we could create >>> an independent pull request for the "don't inject javassist" hint >>> handling. >> >> >> Would that hint be another "knob" to be set by the user? If so, I wouldn't >> like it too much, it's just such a technical detail we shouldn't bother the >> user with. > > Yes, it would be another knob, however, it is likely to only be used > by the Hibernate ORM testsuite, as I haven't heard of any user request > for this. > >> >> Another idea: can you examine the ORM module you are about to add and check >> wether it exports Javassist and if so, not auto-inject Javassist? Not sure >> whether it's doable in terms of capabilities of the module API. > > I'm not 100%, we would likely need to explore what is available from > the application deployment > org.jboss.as.server.deployment.module.ModuleSpecification at the early > deployment phase that JPADependencyProcessor is called in. > ModuleSpecification seems to have getSystemDependencies() + > getUserDependencies() + getLocalDependencies() calls, but I'm not sure > how (deployment) expensive it would be to sequentially walk through > each module dependency and look for javassist classes. > >> >>> >>> >>> On Thu, Oct 27, 2016 at 9:40 AM, Gunnar Morling >>> wrote: >>> > >>> > >>> > 2016-10-27 14:59 GMT+02:00 Scott Marlow : >>> >> >>> >> On Thu, Oct 27, 2016 at 4:49 AM, Gunnar Morling >>> >> wrote: >>> >> > Hi, >>> >> >>> >> Hi, >>> >> >>> >> > >>> >> > 2016-10-27 4:27 GMT+02:00 Scott Marlow : >>> >> >> >>> >> >> >>> >> >> > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM >>> >> >> > module >>> >> >> > (the WF module) export Javassist. Not the application. >>> >> > >>> >> > >>> >> > Right, Hibernate ORM's module should be the one exposing it, not the >>> >> > application nor JipiJapa. >>> >> >>> >> JipiJapa has zero to do with this, we will create a pr later today to >>> >> remove the unneeded dependencies, which has nothing to do with this >>> >> conversation. >>> > >>> > >>> > Yes, there is this superfluous dependency, thanks for removing it. >>> > >>> > But the other issue is hat in JPADependencyProcessor (that's what I >>> > meant >>> > when referring to "JipiJapa", sorry if that's not correct), a dependency >>> > to >>> > Javassist is injected. This shouldn't be the case for the reasons I've >>> > pointed out. Also with the PR >>> > https://github.com/wildfly/wildfly/pull/8474 >>> > you mentioned this seems to be the case. >>> >> >>> >> >>> >> > >>> >> > I've done the following changes locally: >>> >> > >>> >> > 1) Altered JPADependencyProcessor to not add the Javassist dependency >>> >> > to >>> >> > the >>> >> > deployment >>> >> > 2) Altered module.xml of jipijapa-hibernate5 to not depend on >>> >> > Javassist >>> >> >>> >> I did the same locally, which is an unused dependency. I removed some >>> >> other unused dependencies other as well. Gail and I will talk later >>> >> about removing these unused dependencies. >>> >> >>> >> > 3) Added a new module for the latest Javassist >>> >> > 4) Altered module.xml of ORM itself to depend on that new module >>> >> > *and* >>> >> > re-export it >>> >> > >>> >> > With all this in place, the tests in Hibernate Search pass >>> >> > successfully. >>> >> > >>> >> > Scott, do you think we can try another PR with that? Again, it >>> >> > doesn't >>> >> >>> >> https://github.com/wildfly/wildfly/pull/8474 is still open, no need >>> >> for a new PR when we already have an open one, with one exception, as >>> >> I didn't actually remove the export of Javassist to the application >>> >> classpath. I forget why. I'll try that locally and run the WildFly >>> >> testsuite to see if there is a failure. >>> > >>> > >> >> From smarlow at redhat.com Thu Oct 27 19:04:45 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 27 Oct 2016 19:04:45 -0400 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: On Thu, Oct 27, 2016 at 10:14 AM, Steve Ebersole wrote: > Dunno. To me this is a bug that Jipijapa/WF/DUP adds this dependency at > all. How that gets resolved or not is completely up to Jipijapa/WF/DUP as > it is the one(s) doing this. There is nothing Hibernate can do here. > > I updated the https://github.com/scottmarlow/wildfly/tree/WFLY-459_javassistnative pull request as requested, JPADependencyProcessor will no longer add Javassist to the application deployment (if the change is merged). What changed? If applications embed Hibernate jars, the app developer shouldn't be surprised by this change that requires them to specify their own Javassist dependency. I'm not sure if it would help but Sanne could comment on the pull request that he approves the PR (if Sanne agrees the updated change is now correct). That might negate earlier feedback against the pull request, not being correct. From smarlow at redhat.com Fri Oct 28 09:44:00 2016 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 28 Oct 2016 09:44:00 -0400 Subject: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly In-Reply-To: References: Message-ID: >> Right, Hibernate ORM's module should be the one exposing it, not the >> application nor JipiJapa. > > JipiJapa has zero to do with this, we will create a pr later today to > remove the unneeded dependencies, which has nothing to do with this > conversation. https://github.com/wildfly/wildfly/pull/9305 is for removing the unused Javassist dependency from JipiJapa. Also removed a few other unused dependencies. From sanne at hibernate.org Fri Oct 28 11:07:52 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 28 Oct 2016 16:07:52 +0100 Subject: [hibernate-dev] Feature reduction in Hibernate Search Message-ID: We're not working yet on Hibernate Search 6, but since it's the next big chapter I hope we're all making notes - if not JIRAs - of what we'd like changed in the next version. As a reminder, the main themes of version 6 are: - upgrade to Apache Lucene 6 - API changes to (better) accommodate for non-Lucene backends, such as Elasticsearch - align with the Hibernate portfolio of projects version 6 I'd like you to also think about features which should be dropped: it's not healthy - certainly not sustainable - to see a project like this as a place to keep adding features, without ever removing or simplifying some. If you have thoughts in the area, let's bring them up in the mailing list: no rush, but the sooner the better. However I'd prefer to discuss each proposal independently so please refrain from sending specific deprecation ideas to this same email thread. Thanks, Sanne