Re: [hibernate-dev] Hibernate ORM FAQ in JBoss wiki
Thanks, Vlad! 2016-02-16 16:35 GMT+01:00 Vlad Mihalcea : > Thanks for the hint. I didn't even know about their existence. > > I added it to my TODO list. > > Vlad > > On Tue, Feb 16, 2016 at 5:24 PM, Gunnar Morling > wrote: >> >> Vlad, all, >> >> In the JBoss.org wiki there are several interesting FAQs around Hibernate >> ORM: >> >> https://developer.jboss.org/en/hibernate/faq >> >> They provide very useful info (just learned something new by reading >> them), but since the last updated more than five years have passed. So >> I suppose some stuff is outdated by now. >> >> Assuming those contents are worth keeping, it would be great if they >> could be revised, sorted out / updated as needed and moved over to >> http://hibernate.org/orm/faq/ eventually. >> >> Do you think you could take a look at these at some point? I know it's >> fair bit of work, but the Hibernate community would be deeply grateful >> to your forever :) >> >> Cheers, >> >> --Gunnar >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications...
Hi, I'd like to propose an alternative approach for proxy generation which would avoid version issues with Javassist. The idea is to generate proxies which are fully "self-contained", i.e. their byte code contains no references to a library such as Javassist, but instead invocations of a either a custom method handler contract we define ourselves or something unproblematic such as java.lang.reflect.InvocationHandler. Such code generation could be done "by hand" using ASM, but there is a handy library named ByteBuddy [1] which essentially provides a nice DSL for creating types at runtime (it sits on top of ASM itself). It makes it very easy to create proxy classes which call out to an instance of InvocationHandler when the proxied methods are called. Note that it enables the usage of InvocationHandler not only for interfaces (such as the original usage in the JDK) but also for class proxies. The code generated for proxies does not contain any references to ButeBuddy's API, i.e. after creation they are usable without ByteBuddy being available (*). That way ByteBuddy should not have to be exposed to user deployments, unlike with the current Javassist solution. It'd only be a tool used *internally* within Hibernate. I've pushed a very rough draft of that approach to my fork of ORM at https://github.com/hibernate/hibernate-orm/commit/0b1739059b74aaab7d3aa91bba85b204ee367d92. It's not complete and some tests fail. I'd need to look into these in more depth, but I don't think they represent general problems. But this sketch might be good enough already to be dropped into WildFly and run some tests. Any feedback welcome. Cheers, --Gunnar [1] bytebuddy.net/ (*) I could serialize a generated proxy to disk and re-read+execute it subsequently from another application without ByteBuddy on the classpath 2016-02-16 20:07 GMT+01:00 Scott Marlow : > https://hibernate.atlassian.net/browse/HHH-10536 is for tracking this. > Please revise as it makes sense. > > In the related WildFly dev discussion about $subject, Stuart asked if we > would have two separate Hibernate ORM jars (one that depends on the > shaded Javassist and one that depends on regular Javassist). That seems > like a separate concern but perhaps others will feel stronger about it. > > Also, in the WildFly discussion, I asked whether it makes a difference > to Hibernate, whether the javassist.util.proxy classes that we want to > shade, are in the javassist.jar or a new javassist-runtime.jar? If we > shade all of the classes in a javassist-runtime.jar, that might be a > better long term contract, then if we shaded the javassist.util.proxy > classes which could be renamed over time. Does it make a difference > whether we shade the javassist.util.proxy or entire javassist-runtime.jar? > > Thanks, > Scott > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications...
+1 Avoiding a runtime dependency seems far better than shading. Maybe the same could be done with Javassist? On Wed, 17 Feb 2016 12:15 Gunnar Morling wrote: > Hi, > > I'd like to propose an alternative approach for proxy generation which > would avoid version issues with Javassist. > > The idea is to generate proxies which are fully "self-contained", i.e. > their byte code contains no references to a library such as Javassist, > but instead invocations of a either a custom method handler contract > we define ourselves or something unproblematic such as > java.lang.reflect.InvocationHandler. > > Such code generation could be done "by hand" using ASM, but there is a > handy library named ByteBuddy [1] which essentially provides a nice > DSL for creating types at runtime (it sits on top of ASM itself). It > makes it very easy to create proxy classes which call out to an > instance of InvocationHandler when the proxied methods are called. > Note that it enables the usage of InvocationHandler not only for > interfaces (such as the original usage in the JDK) but also for class > proxies. > > The code generated for proxies does not contain any references to > ButeBuddy's API, i.e. after creation they are usable without ByteBuddy > being available (*). That way ByteBuddy should not have to be exposed > to user deployments, unlike with the current Javassist solution. It'd > only be a tool used *internally* within Hibernate. > > I've pushed a very rough draft of that approach to my fork of ORM at > > https://github.com/hibernate/hibernate-orm/commit/0b1739059b74aaab7d3aa91bba85b204ee367d92 > . > > It's not complete and some tests fail. I'd need to look into these in > more depth, but I don't think they represent general problems. But > this sketch might be good enough already to be dropped into WildFly > and run some tests. > > Any feedback welcome. > > Cheers, > > --Gunnar > > [1] bytebuddy.net/ > (*) I could serialize a generated proxy to disk and re-read+execute it > subsequently from another application without ByteBuddy on the > classpath > > > 2016-02-16 20:07 GMT+01:00 Scott Marlow : > > https://hibernate.atlassian.net/browse/HHH-10536 is for tracking this. > > Please revise as it makes sense. > > > > In the related WildFly dev discussion about $subject, Stuart asked if we > > would have two separate Hibernate ORM jars (one that depends on the > > shaded Javassist and one that depends on regular Javassist). That seems > > like a separate concern but perhaps others will feel stronger about it. > > > > Also, in the WildFly discussion, I asked whether it makes a difference > > to Hibernate, whether the javassist.util.proxy classes that we want to > > shade, are in the javassist.jar or a new javassist-runtime.jar? If we > > shade all of the classes in a javassist-runtime.jar, that might be a > > better long term contract, then if we shaded the javassist.util.proxy > > classes which could be renamed over time. Does it make a difference > > whether we shade the javassist.util.proxy or entire > javassist-runtime.jar? > > > > Thanks, > > Scott > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications...
Hi, > I'd like to propose an alternative approach for proxy generation which > would avoid version issues with Javassist. > > The idea is to generate proxies which are fully "self-contained", i.e. > their byte code contains no references to a library such as Javassist, > but instead invocations of a either a custom method handler contract > we define ourselves or something unproblematic such as > java.lang.reflect.InvocationHandler. +1 Great idea. I used ByteBuddy as well a bit and I think it is a good library. --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Who deleted http://docs.jboss.org/hibernate/validator ?
Right I would prefer to internalize the doc under hibernate.org. > On 16 févr. 2016, at 22:15, Steve Ebersole wrote: > > No, personally I am talking strictly about the > hibernate.org/orm/documentation nav > > >> On Tue, Feb 16, 2016 at 3:14 PM Vlad Mihalcea >> wrote: >> Hi, >> >> I can surely take a look on this. We just need to discuss which task has >> higher priority: this one or finishing the User Guide. >> >> Since we have a single HTML doc, we could, at first, have an upper toolbar >> with all currently supported doc versions: 5.1, 5.0, 4.3, 4.2 >> By default, we load current which is the latest version. >> >> When the user clicks 4.2, we just go to >> http://docs.jboss.org/hibernate/orm/4.2/manual/en-US/html_single/ >> If he clicks 5.0, we go to >> http://docs.jboss.org/hibernate/orm/5.0/manual/en-US/html_single/ >> If he clicks 5.1, he navigates to >> http://docs.jboss.org/hibernate/orm/5.1/userguide/html_single/Hibernate_User_Guide.html >> >> Is this what you were thinking of too? >> >> Vlad >> >>> On Tue, Feb 16, 2016 at 8:54 PM, Emmanuel Bernard >>> wrote: >>> +1. I like the idea to land on current by default and be able to go to >>> older versions of the documentation section if requested. >>> >>> It will require some work but I do think that it is doable in Awestruct. >>> >>> Maybe Vlad could spend some time mocking a website in that configuration >>> and once we converge start working in the Awestruct implementation. >>> I would rather see Vlad working on it as he is our doc focused expert. >>> Davide and I can offer Awestruct assistance of course. >>> >>> > On 12 févr. 2016, at 19:12, Steve Ebersole wrote: >>> > >>> > Emmanuel, Davide, etal... >>> > >>> > I think I want to redo that decision to put versioned links on the nav. >>> > That was always just a temp solution, as it was the easiest way to add >>> > handling for versioned docs. But as I add 5.1 docs we would now have 4 >>> > links on the nav for docs. That's starting to get fugly. >>> > >>> > Instead I'd like to have one link (Documentation) that points to a page >>> > for >>> > "current" documentation. Then from that page (and all the versioned doc >>> > pages) I'd like to have a set of links to older docs (or docs by version). >>> > Ideas on how to best achieve that in our website build? >>> > >>> > >>> >> On Fri, Feb 12, 2016 at 12:05 PM Steve Ebersole >>> >> wrote: >>> >> >>> >> Vlad, today I will work updating the website for ORM. Versioned >>> >> information (documentation) is very difficult to deal with there (imho) >>> >> >>> >> On Fri, Feb 12, 2016 at 12:01 PM Steve Ebersole >>> >> wrote: >>> >> >>> >>> I went all the way back to 3.0. rsync started >>> >>> >>> >>> On Fri, Feb 12, 2016 at 11:44 AM Gunnar Morling >>> >>> wrote: >>> >>> >>> The more, the better. At least 4.3 is needed as it's the last BV 1.0 >>> compatible version. I don't exactly remember what we had there, but I >>> suppose all the way back till 3.0. So if you are at 4.2, you are >>> almost there :) >>> >>> 2016-02-12 18:31 GMT+01:00 Steve Ebersole : >>> > so far I have downloaded back to 4.2. Should I stop at 5.0? >>> > >>> > >>> > On Fri, Feb 12, 2016 at 11:25 AM Gunnar Morling >>> > wrote: >>> >> >>> >> Hey, >>> >> >>> >> That's weird indeed. Last time I checked (at the time of the HV 5.2.3 >>> >> release), everything was still in place. >>> >> >>> >> http://hibernate.org/validator/documentation/ links to the following: >>> >> >>> >> * http://docs.jboss.org/hibernate/validator/5.3/reference/en-US/html/ >>> >> * >>> http://docs.jboss.org/hibernate/validator/5.3/reference/en-US/html_single/ >>> >> * >>> http://docs.jboss.org/hibernate/validator/5.3/reference/en-US/pdf/hibernate_validator_reference.pdf >>> >> * http://docs.jboss.org/hibernate/validator/5.3/api/ (JavaDoc) >>> >> >>> >> And the same for 5.2 and 4.3. Would be great to restore these ones >>> >> and >>> >> the "stable" alias at least; 5.1 and 5.0 would be bonus I suppose. >>> >> >>> >> Thanks, Steve, if you are taking this over. >>> >> >>> >> --Gunnar >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> 2016-02-12 18:16 GMT+01:00 Davide D'Alto : >>> >>> Links seems to be in the format x.y >>> >>> At least looking at the links on >>> >>> http://hibernate.org/validator/documentation/ >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Feb 12, 2016 at 5:08 PM, Steve Ebersole < >>> st...@hibernate.org> >>> >>> wrote: >>> >>> >>> What's the level of versions for the validator docs on the server? >>> x.y? >>> >>> On Fri, Feb 12, 2016 at 10:59 AM Steve Ebersole < >>> st...@hibernate.org> >>> wrote: >>> >>> > If the old style guides were there after the release, but gone >>> since >>> >>>
Re: [hibernate-dev] Who deleted http://docs.jboss.org/hibernate/validator ?
I dont think we should be "internalizing" the docs under hibernate.org if by that you mean hosting them there. Like I mentioned I am really not a fan of the practical side of that which means having to do git commands to that hibernate.org repo to publish docs for a release. Maybe that's just me. I really am just talking about the doc link pages. I.e.: http://hibernate.org/orm/documentation/5.1/ http://hibernate.org/orm/documentation/5.0/ etc On Wed, Feb 17, 2016 at 8:16 AM Emmanuel Bernard wrote: > Right I would prefer to internalize the doc under hibernate.org. > > On 16 févr. 2016, at 22:15, Steve Ebersole wrote: > > No, personally I am talking strictly about the > hibernate.org/orm/documentation nav > > > On Tue, Feb 16, 2016 at 3:14 PM Vlad Mihalcea > wrote: > >> Hi, >> >> I can surely take a look on this. We just need to discuss which task has >> higher priority: this one or finishing the User Guide. >> >> Since we have a single HTML doc, we could, at first, have an upper >> toolbar with all currently supported doc versions: 5.1, 5.0, 4.3, 4.2 >> By default, we load current which is the latest version. >> >> When the user clicks 4.2, we just go to >> http://docs.jboss.org/hibernate/orm/4.2/manual/en-US/html_single/ >> If he clicks 5.0, we go to >> http://docs.jboss.org/hibernate/orm/5.0/manual/en-US/html_single/ >> If he clicks 5.1, he navigates to >> http://docs.jboss.org/hibernate/orm/5.1/userguide/html_single/Hibernate_User_Guide.html >> >> Is this what you were thinking of too? >> >> Vlad >> >> On Tue, Feb 16, 2016 at 8:54 PM, Emmanuel Bernard > > wrote: >> >>> +1. I like the idea to land on current by default and be able to go to >>> older versions of the documentation section if requested. >>> >>> It will require some work but I do think that it is doable in Awestruct. >>> >>> Maybe Vlad could spend some time mocking a website in that configuration >>> and once we converge start working in the Awestruct implementation. >>> I would rather see Vlad working on it as he is our doc focused expert. >>> Davide and I can offer Awestruct assistance of course. >>> >>> > On 12 févr. 2016, at 19:12, Steve Ebersole >>> wrote: >>> > >>> > Emmanuel, Davide, etal... >>> > >>> > I think I want to redo that decision to put versioned links on the nav. >>> > That was always just a temp solution, as it was the easiest way to add >>> > handling for versioned docs. But as I add 5.1 docs we would now have 4 >>> > links on the nav for docs. That's starting to get fugly. >>> > >>> > Instead I'd like to have one link (Documentation) that points to a >>> page for >>> > "current" documentation. Then from that page (and all the versioned >>> doc >>> > pages) I'd like to have a set of links to older docs (or docs by >>> version). >>> > Ideas on how to best achieve that in our website build? >>> > >>> > >>> >> On Fri, Feb 12, 2016 at 12:05 PM Steve Ebersole >>> wrote: >>> >> >>> >> Vlad, today I will work updating the website for ORM. Versioned >>> >> information (documentation) is very difficult to deal with there >>> (imho) >>> >> >>> >> On Fri, Feb 12, 2016 at 12:01 PM Steve Ebersole >>> >> wrote: >>> >> >>> >>> I went all the way back to 3.0. rsync started >>> >>> >>> >>> On Fri, Feb 12, 2016 at 11:44 AM Gunnar Morling < >>> gun...@hibernate.org> >>> >>> wrote: >>> >>> >>> The more, the better. At least 4.3 is needed as it's the last BV 1.0 >>> compatible version. I don't exactly remember what we had there, but >>> I >>> suppose all the way back till 3.0. So if you are at 4.2, you are >>> almost there :) >>> >>> 2016-02-12 18:31 GMT+01:00 Steve Ebersole : >>> > so far I have downloaded back to 4.2. Should I stop at 5.0? >>> > >>> > >>> > On Fri, Feb 12, 2016 at 11:25 AM Gunnar Morling < >>> gun...@hibernate.org> >>> > wrote: >>> >> >>> >> Hey, >>> >> >>> >> That's weird indeed. Last time I checked (at the time of the HV >>> 5.2.3 >>> >> release), everything was still in place. >>> >> >>> >> http://hibernate.org/validator/documentation/ links to the >>> following: >>> >> >>> >> * >>> http://docs.jboss.org/hibernate/validator/5.3/reference/en-US/html/ >>> >> * >>> >>> http://docs.jboss.org/hibernate/validator/5.3/reference/en-US/html_single/ >>> >> * >>> >>> http://docs.jboss.org/hibernate/validator/5.3/reference/en-US/pdf/hibernate_validator_reference.pdf >>> >> * http://docs.jboss.org/hibernate/validator/5.3/api/ (JavaDoc) >>> >> >>> >> And the same for 5.2 and 4.3. Would be great to restore these >>> ones and >>> >> the "stable" alias at least; 5.1 and 5.0 would be bonus I suppose. >>> >> >>> >> Thanks, Steve, if you are taking this over. >>> >> >>> >> --Gunnar >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> 2016-02-12 18:16 GMT+01:00 Davide D'Alto : >>> >>> Links seems to be in the format x.y >>> >>> At least looking at
[hibernate-dev] Preparing to release Hibernate 5.0.8.Final
I'm starting the release process. Please do not push any commits to 5.0 branch until 5.0.8.Final is released. Thanks, Gail ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Problem with symlink handling for documentation tasks (HHH-10512)
I just uploaded the docs from release directory using `../gradlew uploadDocumentation`. The docs ended up being uploaded to https://docs.jboss.org/hibernate/5.0/, instead of https://docs.jboss.org/hibernate/orm/5.0/. Can someone help me get this uploaded to the proper location with the correct symlinks? I'm confused about what was intended by HHH-10512. After tagging and changing the version to 5.0.9-SNAPSHOT, I'll create a Jira issue to fix this for 5.0.9. I'll check to see if it's similarly broken in master. Thanks, Gail ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] ORM 5.0.8.Final has been released
For details: http://in.relation.to/2016/02/17/hibernate-orm-508-final-release/ ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Trouble announcing 5.0.8.Final on Twitter and Google+
I was able to announce on https://twitter.com/hibernate, but not on https://twitter.com/hibernate_dev. I'm being asked for an email address when I try to log on. I am also not able to announce on Google+ and have not been able to for some time. Can someone please provide details about how to do it? Could someone please announce on https://twitter.com/hibernate_dev and Google+? Blog is http://in.relation.to/2016/02/17/hibernate-orm-508-final-release/ Thanks, Gail ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trouble announcing 5.0.8.Final on Twitter and Google+
For Twitter, I don't know. As for Google+ you have to tell me your Google+ name as I mentioned when I set that service up. I tried searching for you, but found nothing. On Wed, Feb 17, 2016 at 6:57 PM Gail Badner wrote: > I was able to announce on https://twitter.com/hibernate, but not on > https://twitter.com/hibernate_dev. I'm being asked for an email address > when I try to log on. > > I am also not able to announce on Google+ and have not been able to for > some time. Can someone please provide details about how to do it? > > Could someone please announce on https://twitter.com/hibernate_dev and > Google+? > > Blog is http://in.relation.to/2016/02/17/hibernate-orm-508-final-release/ > > Thanks, > Gail > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trouble announcing 5.0.8.Final on Twitter and Google+
Hi Gail, Announcing on @hibernate is just fine. The @hibernate_dev account only has 80 followers and it's meant for Hibernate developers. This account features every GitHub commit and that's one reason why few people choose to follow this account. Vlad On Thu, Feb 18, 2016 at 3:24 AM, Steve Ebersole wrote: > For Twitter, I don't know. As for Google+ you have to tell me your Google+ > name as I mentioned when I set that service up. I tried searching for you, > but found nothing. > > On Wed, Feb 17, 2016 at 6:57 PM Gail Badner wrote: > > > I was able to announce on https://twitter.com/hibernate, but not on > > https://twitter.com/hibernate_dev. I'm being asked for an email address > > when I try to log on. > > > > I am also not able to announce on Google+ and have not been able to for > > some time. Can someone please provide details about how to do it? > > > > Could someone please announce on https://twitter.com/hibernate_dev and > > Google+? > > > > Blog is > http://in.relation.to/2016/02/17/hibernate-orm-508-final-release/ > > > > Thanks, > > Gail > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
