From guillaume.smet at gmail.com Fri Mar 1 03:40:55 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 1 Mar 2019 09:40:55 +0100 Subject: [hibernate-dev] Hibernate NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of this week's NoORM meeting: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-02-26-14.03.log.html Have a nice day. -- Guillaume From guillaume.smet at gmail.com Mon Mar 4 05:29:01 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 4 Mar 2019 11:29:01 +0100 Subject: [hibernate-dev] [ORM] Converging on 5.4.2 Message-ID: Hi, I'm busy on other things these days but I would like to release a 5.4.2 soon anyway as we already have fixed 28 issues, some of them quite annoying. Gail, I think most of the remaining open PRs need your attention. If you could take a look at them, that would be great. Let's maybe take a timebox of a few days and postpone to the next version whatever we are not confident enough to merge in this timebox. - https://github.com/hibernate/hibernate-orm/pull/2799 -> this one just has a checkstyle issue, it should be simple enough - https://github.com/hibernate/hibernate-orm/pull/2800 -> the date issue, Yoann pushed a new version, I think it should go in so that we can gather feedback before thinking about backporting it - https://github.com/hibernate/hibernate-orm/pull/2801 -> don't know exactly the purpose or the state of this one but it looks like it should be addressed - https://github.com/hibernate/hibernate-orm/pull/2789 -> looks like it fixes a corner case but we would need to be sure it's safe - https://github.com/hibernate/hibernate-orm/pull/2753 -> this one I'm not sure at all Thanks. -- Guillaume From gbadner at redhat.com Mon Mar 4 12:53:35 2019 From: gbadner at redhat.com (Gail Badner) Date: Mon, 4 Mar 2019 09:53:35 -0800 Subject: [hibernate-dev] [ORM] Converging on 5.4.2 In-Reply-To: References: Message-ID: On Mon, Mar 4, 2019 at 2:31 AM Guillaume Smet wrote: > Hi, > > I'm busy on other things these days but I would like to release a 5.4.2 > soon anyway as we already have fixed 28 issues, some of them quite > annoying. > > Gail, I think most of the remaining open PRs need your attention. > > If you could take a look at them, that would be great. Let's maybe take a > timebox of a few days and postpone to the next version whatever we are not > confident enough to merge in this timebox. > > - https://github.com/hibernate/hibernate-orm/pull/2799 -> this one just > has > a checkstyle issue, it should be simple enough > I need to add more tests for this one. > - https://github.com/hibernate/hibernate-orm/pull/2800 -> the date issue, > Yoann pushed a new version, I think it should go in so that we can gather > feedback before thinking about backporting it > +1; I'll review this in the next couple of days. > - https://github.com/hibernate/hibernate-orm/pull/2801 -> don't know > exactly the purpose or the state of this one but it looks like it should be > addressed > +1; I'll review this in the next couple of days. > - https://github.com/hibernate/hibernate-orm/pull/2789 -> looks like it > fixes a corner case but we would need to be sure it's safe > +1; I'll review this in the next couple of days. > - https://github.com/hibernate/hibernate-orm/pull/2753 -> this one I'm not > sure at all > I'm not sure either; I'll take a look though. > > Thanks. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From vivek.ravikumar at yahoo.in Tue Mar 5 22:28:24 2019 From: vivek.ravikumar at yahoo.in (Vivek R) Date: Wed, 6 Mar 2019 03:28:24 +0000 (UTC) Subject: [hibernate-dev] Mail ID References: <937557229.80108.1551842904842.ref@mail.yahoo.com> Message-ID: <937557229.80108.1551842904842@mail.yahoo.com> vivek.ravikumar at yahoo.in Sent from Yahoo Mail on Android From BENJAMIC at uk.ibm.com Fri Mar 8 05:14:32 2019 From: BENJAMIC at uk.ibm.com (Benjamin Confino) Date: Fri, 8 Mar 2019 10:14:32 +0000 Subject: [hibernate-dev] ExtendedBeanManager Message-ID: Hello I'm attempting to write a prototype implementation for Hibernate's Extended Bean Manager and I seem to have hit a problem. I have placed a proxy class that implements both BeanManager and ExtendedBeanManager into the property javax.persistence.bean.manager. I can see that the invocation handler for the proxy is being called by hibernate, but there is no call to registerLifecycleListener. Instead I see hibernate trying to use the bean manager before it has been initialised. Do I need to do anything extra to configure hibernate? I was under the impression that if the object in javax.persistence.bean.manager implemented ExtendedBeanManager everything would automatically be configured. Regards Benjamin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From yoann at hibernate.org Fri Mar 8 10:46:33 2019 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 8 Mar 2019 16:46:33 +0100 Subject: [hibernate-dev] ExtendedBeanManager In-Reply-To: References: Message-ID: Hello, It's supposed to work as you described. Have you tried making your class implement *only* ExtendedBeanManager? It should have worked even if your class implements both, but there might be a bug... As far as I know we only ever pass objects implementing either BeanManager or ExtendedBeanManager, never both. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Fri, 8 Mar 2019 at 11:16, Benjamin Confino wrote: > Hello > > I'm attempting to write a prototype implementation for Hibernate's > Extended Bean Manager and I seem to have hit a problem. I have placed a > proxy class that implements both BeanManager and ExtendedBeanManager into > the property javax.persistence.bean.manager. I can see that the invocation > handler for the proxy is being called by hibernate, but there is no call > to registerLifecycleListener. Instead I see hibernate trying to use the > bean manager before it has been initialised. > > Do I need to do anything extra to configure hibernate? I was under the > impression that if the object in javax.persistence.bean.manager > implemented ExtendedBeanManager everything would automatically be > configured. > > Regards > Benjamin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From BENJAMIC at uk.ibm.com Fri Mar 8 11:29:14 2019 From: BENJAMIC at uk.ibm.com (Benjamin Confino) Date: Fri, 8 Mar 2019 16:29:14 +0000 Subject: [hibernate-dev] ExtendedBeanManager In-Reply-To: References: Message-ID: Hello Yoann Indeed I have tried that as an experiment, I got the following error when I did: Caused by: java.lang.ClassCastException: Cannot cast class com.sun.proxy.$Proxy22 to interface javax.enterprise.inject.spi.BeanManager at java.lang.Class.cast(Class.java:2623) at org.hibernate.resource.beans.container.internal.CdiBeanContainerBuilder.fromBeanManagerReference(CdiBeanContainerBuilder.java:72) That was more or less what I expected so I didn't think much of it at the time, but from your email it sounds like this isn't what you'd expect? If it helps I'm running with hibernate-core-5.4.1.Final.jar - I'm not sure what other info will help you but if you let me know I can send it over. Regards Benjamin From: Yoann Rodiere To: Benjamin Confino Cc: Hibernate Dev Date: 08/03/2019 15:52 Subject: Re: [hibernate-dev] ExtendedBeanManager Sent by: hibernate-dev-bounces at lists.jboss.org Hello, It's supposed to work as you described. Have you tried making your class implement *only* ExtendedBeanManager? It should have worked even if your class implements both, but there might be a bug... As far as I know we only ever pass objects implementing either BeanManager or ExtendedBeanManager, never both. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Fri, 8 Mar 2019 at 11:16, Benjamin Confino wrote: > Hello > > I'm attempting to write a prototype implementation for Hibernate's > Extended Bean Manager and I seem to have hit a problem. I have placed a > proxy class that implements both BeanManager and ExtendedBeanManager into > the property javax.persistence.bean.manager. I can see that the invocation > handler for the proxy is being called by hibernate, but there is no call > to registerLifecycleListener. Instead I see hibernate trying to use the > bean manager before it has been initialised. > > Do I need to do anything extra to configure hibernate? I was under the > impression that if the object in javax.persistence.bean.manager > implemented ExtendedBeanManager everything would automatically be > configured. > > Regards > Benjamin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_hibernate-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=uiDe53gn7U2NJbNV61E624TnE-C3umU_rNhHkcDS8sY&s=6lA6rZaAqy_SI2NeT6wPJoFF3xich4FH7DYNDvGTCDo&e= > _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_hibernate-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=uiDe53gn7U2NJbNV61E624TnE-C3umU_rNhHkcDS8sY&s=6lA6rZaAqy_SI2NeT6wPJoFF3xich4FH7DYNDvGTCDo&e= Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From yoann at hibernate.org Fri Mar 8 11:50:25 2019 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 8 Mar 2019 17:50:25 +0100 Subject: [hibernate-dev] ExtendedBeanManager In-Reply-To: References: Message-ID: >From your stack trace, it seems that the object you pass to Hibernate ORM is not correctly detected as implementing the ExtendedBeanManager. And actually I just checked, and there seems to be a bug: we require the object to implement the deprecated org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager interface, even though we only need its parent class, org.hibernate.resource.beans.container.spi.ExtendedBeanManager ... I'll create a ticket for that. Until this is fixed, you will need to implement the deprecated org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Fri, 8 Mar 2019 at 17:30, Benjamin Confino wrote: > Hello Yoann > > Indeed I have tried that as an experiment, I got the following error when > I did: > > Caused by: java.lang.ClassCastException: Cannot cast class > com.sun.proxy.$Proxy22 to interface javax.enterprise.inject.spi.BeanManager > at java.lang.Class.cast(Class.java:2623) > at > org.hibernate.resource.beans.container.internal.CdiBeanContainerBuilder.fromBeanManagerReference(CdiBeanContainerBuilder.java:72) > > That was more or less what I expected so I didn't think much of it at the > time, but from your email it sounds like this isn't what you'd expect? > > If it helps I'm running with hibernate-core-5.4.1.Final.jar - I'm not sure > what other info will help you but if you let me know I can send it over. > > Regards > Benjamin > > > > > From: Yoann Rodiere > To: Benjamin Confino > Cc: Hibernate Dev > Date: 08/03/2019 15:52 > Subject: Re: [hibernate-dev] ExtendedBeanManager > Sent by: hibernate-dev-bounces at lists.jboss.org > ------------------------------ > > > > Hello, > > It's supposed to work as you described. > > Have you tried making your class implement *only* ExtendedBeanManager? > It should have worked even if your class implements both, but there might > be a bug... As far as I know we only ever pass objects implementing either > BeanManager or ExtendedBeanManager, never both. > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Fri, 8 Mar 2019 at 11:16, Benjamin Confino wrote: > > > Hello > > > > I'm attempting to write a prototype implementation for Hibernate's > > Extended Bean Manager and I seem to have hit a problem. I have placed a > > proxy class that implements both BeanManager and ExtendedBeanManager into > > the property javax.persistence.bean.manager. I can see that the > invocation > > handler for the proxy is being called by hibernate, but there is no call > > to registerLifecycleListener. Instead I see hibernate trying to use the > > bean manager before it has been initialised. > > > > Do I need to do anything extra to configure hibernate? I was under the > > impression that if the object in javax.persistence.bean.manager > > implemented ExtendedBeanManager everything would automatically be > > configured. > > > > Regards > > Benjamin > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > _______________________________________________ > > 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 > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From steve at hibernate.org Fri Mar 8 11:56:49 2019 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 8 Mar 2019 10:56:49 -0600 Subject: [hibernate-dev] ExtendedBeanManager In-Reply-To: References: Message-ID: Just be careful. We kept the deprecated one as WildFly "needs it" On Fri, Mar 8, 2019 at 10:55 AM Yoann Rodiere wrote: > From your stack trace, it seems that the object you pass to Hibernate ORM > is not correctly detected as implementing the ExtendedBeanManager. > > And actually I just checked, and there seems to be a bug: we require the > object to implement the deprecated > org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager interface, even though > we only need its parent class, > org.hibernate.resource.beans.container.spi.ExtendedBeanManager ... > > I'll create a ticket for that. Until this is fixed, you will need to > implement the deprecated > org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager. > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Fri, 8 Mar 2019 at 17:30, Benjamin Confino wrote: > > > Hello Yoann > > > > Indeed I have tried that as an experiment, I got the following error when > > I did: > > > > Caused by: java.lang.ClassCastException: Cannot cast class > > com.sun.proxy.$Proxy22 to interface > javax.enterprise.inject.spi.BeanManager > > at java.lang.Class.cast(Class.java:2623) > > at > > > org.hibernate.resource.beans.container.internal.CdiBeanContainerBuilder.fromBeanManagerReference(CdiBeanContainerBuilder.java:72) > > > > That was more or less what I expected so I didn't think much of it at the > > time, but from your email it sounds like this isn't what you'd expect? > > > > If it helps I'm running with hibernate-core-5.4.1.Final.jar - I'm not > sure > > what other info will help you but if you let me know I can send it over. > > > > Regards > > Benjamin > > > > > > > > > > From: Yoann Rodiere > > To: Benjamin Confino > > Cc: Hibernate Dev > > Date: 08/03/2019 15:52 > > Subject: Re: [hibernate-dev] ExtendedBeanManager > > Sent by: hibernate-dev-bounces at lists.jboss.org > > ------------------------------ > > > > > > > > Hello, > > > > It's supposed to work as you described. > > > > Have you tried making your class implement *only* ExtendedBeanManager? > > It should have worked even if your class implements both, but there might > > be a bug... As far as I know we only ever pass objects implementing > either > > BeanManager or ExtendedBeanManager, never both. > > > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > > > On Fri, 8 Mar 2019 at 11:16, Benjamin Confino > wrote: > > > > > Hello > > > > > > I'm attempting to write a prototype implementation for Hibernate's > > > Extended Bean Manager and I seem to have hit a problem. I have placed a > > > proxy class that implements both BeanManager and ExtendedBeanManager > into > > > the property javax.persistence.bean.manager. I can see that the > > invocation > > > handler for the proxy is being called by hibernate, but there is no > call > > > to registerLifecycleListener. Instead I see hibernate trying to use the > > > bean manager before it has been initialised. > > > > > > Do I need to do anything extra to configure hibernate? I was under the > > > impression that if the object in javax.persistence.bean.manager > > > implemented ExtendedBeanManager everything would automatically be > > > configured. > > > > > > Regards > > > Benjamin > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > > > _______________________________________________ > > > 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 > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From yoann at hibernate.org Fri Mar 8 12:03:10 2019 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 8 Mar 2019 18:03:10 +0100 Subject: [hibernate-dev] ExtendedBeanManager In-Reply-To: References: Message-ID: Yes, I'll keep the deprecated one and will run tests as appropriate. 5.3/5.4 are already "tainted" anyway: there are some versions that won't work with application servers using the new interface. So application servers are unlikely to switch to the new interface until they stop supporting 5.3/5.4. I think I will only fix this in 6, then backport if it's really easy and safe. Ticket: https://hibernate.atlassian.net/browse/HHH-13309 Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Fri, 8 Mar 2019 at 17:57, Steve Ebersole wrote: > Just be careful. We kept the deprecated one as WildFly "needs it" > > On Fri, Mar 8, 2019 at 10:55 AM Yoann Rodiere wrote: > >> From your stack trace, it seems that the object you pass to Hibernate ORM >> is not correctly detected as implementing the ExtendedBeanManager. >> >> And actually I just checked, and there seems to be a bug: we require the >> object to implement the deprecated >> org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager interface, even though >> we only need its parent class, >> org.hibernate.resource.beans.container.spi.ExtendedBeanManager ... >> >> I'll create a ticket for that. Until this is fixed, you will need to >> implement the deprecated >> org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager. >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> >> On Fri, 8 Mar 2019 at 17:30, Benjamin Confino >> wrote: >> >> > Hello Yoann >> > >> > Indeed I have tried that as an experiment, I got the following error >> when >> > I did: >> > >> > Caused by: java.lang.ClassCastException: Cannot cast class >> > com.sun.proxy.$Proxy22 to interface >> javax.enterprise.inject.spi.BeanManager >> > at java.lang.Class.cast(Class.java:2623) >> > at >> > >> org.hibernate.resource.beans.container.internal.CdiBeanContainerBuilder.fromBeanManagerReference(CdiBeanContainerBuilder.java:72) >> > >> > That was more or less what I expected so I didn't think much of it at >> the >> > time, but from your email it sounds like this isn't what you'd expect? >> > >> > If it helps I'm running with hibernate-core-5.4.1.Final.jar - I'm not >> sure >> > what other info will help you but if you let me know I can send it over. >> > >> > Regards >> > Benjamin >> > >> > >> > >> > >> > From: Yoann Rodiere >> > To: Benjamin Confino >> > Cc: Hibernate Dev >> > Date: 08/03/2019 15:52 >> > Subject: Re: [hibernate-dev] ExtendedBeanManager >> > Sent by: hibernate-dev-bounces at lists.jboss.org >> > ------------------------------ >> > >> > >> > >> > Hello, >> > >> > It's supposed to work as you described. >> > >> > Have you tried making your class implement *only* ExtendedBeanManager? >> > It should have worked even if your class implements both, but there >> might >> > be a bug... As far as I know we only ever pass objects implementing >> either >> > BeanManager or ExtendedBeanManager, never both. >> > >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > yoann at hibernate.org >> > >> > >> > On Fri, 8 Mar 2019 at 11:16, Benjamin Confino >> wrote: >> > >> > > Hello >> > > >> > > I'm attempting to write a prototype implementation for Hibernate's >> > > Extended Bean Manager and I seem to have hit a problem. I have placed >> a >> > > proxy class that implements both BeanManager and ExtendedBeanManager >> into >> > > the property javax.persistence.bean.manager. I can see that the >> > invocation >> > > handler for the proxy is being called by hibernate, but there is no >> call >> > > to registerLifecycleListener. Instead I see hibernate trying to use >> the >> > > bean manager before it has been initialised. >> > > >> > > Do I need to do anything extra to configure hibernate? I was under the >> > > impression that if the object in javax.persistence.bean.manager >> > > implemented ExtendedBeanManager everything would automatically be >> > > configured. >> > > >> > > Regards >> > > Benjamin >> > > Unless stated otherwise above: >> > > IBM United Kingdom Limited - Registered in England and Wales with >> number >> > > 741598. >> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> > 3AU >> > > _______________________________________________ >> > > 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 >> > >> > >> > >> > Unless stated otherwise above: >> > IBM United Kingdom Limited - Registered in England and Wales with number >> > 741598. >> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> 3AU >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From BENJAMIC at uk.ibm.com Fri Mar 8 13:43:40 2019 From: BENJAMIC at uk.ibm.com (Benjamin Confino) Date: Fri, 8 Mar 2019 18:43:40 +0000 Subject: [hibernate-dev] ExtendedBeanManager In-Reply-To: References: Message-ID: Thank you Yoann Implementing the old interface has let me progress. From: Yoann Rodiere To: Benjamin Confino Cc: Hibernate Dev Date: 08/03/2019 16:55 Subject: Re: [hibernate-dev] ExtendedBeanManager Sent by: hibernate-dev-bounces at lists.jboss.org >From your stack trace, it seems that the object you pass to Hibernate ORM is not correctly detected as implementing the ExtendedBeanManager. And actually I just checked, and there seems to be a bug: we require the object to implement the deprecated org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager interface, even though we only need its parent class, org.hibernate.resource.beans.container.spi.ExtendedBeanManager ... I'll create a ticket for that. Until this is fixed, you will need to implement the deprecated org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Fri, 8 Mar 2019 at 17:30, Benjamin Confino wrote: > Hello Yoann > > Indeed I have tried that as an experiment, I got the following error when > I did: > > Caused by: java.lang.ClassCastException: Cannot cast class > com.sun.proxy.$Proxy22 to interface javax.enterprise.inject.spi.BeanManager > at java.lang.Class.cast(Class.java:2623) > at > org.hibernate.resource.beans.container.internal.CdiBeanContainerBuilder.fromBeanManagerReference(CdiBeanContainerBuilder.java:72) > > That was more or less what I expected so I didn't think much of it at the > time, but from your email it sounds like this isn't what you'd expect? > > If it helps I'm running with hibernate-core-5.4.1.Final.jar - I'm not sure > what other info will help you but if you let me know I can send it over. > > Regards > Benjamin > > > > > From: Yoann Rodiere > To: Benjamin Confino > Cc: Hibernate Dev > Date: 08/03/2019 15:52 > Subject: Re: [hibernate-dev] ExtendedBeanManager > Sent by: hibernate-dev-bounces at lists.jboss.org > ------------------------------ > > > > Hello, > > It's supposed to work as you described. > > Have you tried making your class implement *only* ExtendedBeanManager? > It should have worked even if your class implements both, but there might > be a bug... As far as I know we only ever pass objects implementing either > BeanManager or ExtendedBeanManager, never both. > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Fri, 8 Mar 2019 at 11:16, Benjamin Confino wrote: > > > Hello > > > > I'm attempting to write a prototype implementation for Hibernate's > > Extended Bean Manager and I seem to have hit a problem. I have placed a > > proxy class that implements both BeanManager and ExtendedBeanManager into > > the property javax.persistence.bean.manager. I can see that the > invocation > > handler for the proxy is being called by hibernate, but there is no call > > to registerLifecycleListener. Instead I see hibernate trying to use the > > bean manager before it has been initialised. > > > > Do I need to do anything extra to configure hibernate? I was under the > > impression that if the object in javax.persistence.bean.manager > > implemented ExtendedBeanManager everything would automatically be > > configured. > > > > Regards > > Benjamin > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_hibernate-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=STnSVK6ZUUx5NZPFf5M9jB5IZG8kYQIeoxuBrVWDxEQ&s=6RxBUl4H8CyCjq_no_zRYstRtMIcoHHD_6s6driv_yU&e= > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_hibernate-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=STnSVK6ZUUx5NZPFf5M9jB5IZG8kYQIeoxuBrVWDxEQ&s=6RxBUl4H8CyCjq_no_zRYstRtMIcoHHD_6s6driv_yU&e= > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_hibernate-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=STnSVK6ZUUx5NZPFf5M9jB5IZG8kYQIeoxuBrVWDxEQ&s=6RxBUl4H8CyCjq_no_zRYstRtMIcoHHD_6s6driv_yU&e= Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From emmanuel at hibernate.org Sat Mar 9 03:26:04 2019 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Sat, 9 Mar 2019 09:26:04 +0100 Subject: [hibernate-dev] Quarkus + search request Message-ID: https://twitter.com/quarkusio/status/1104297031273775106?s=21 From guillaume.smet at gmail.com Sat Mar 9 07:14:42 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Sat, 9 Mar 2019 13:14:42 +0100 Subject: [hibernate-dev] Quarkus + search request In-Reply-To: References: Message-ID: So a quick note about where we're at: - Yoann is mostly done with the changes to make in Search 6 (it probably needs a rebase and I need to test them but if I don't find any issue, it's done) - I need to rebase my work on top of all the Quarkus renamings - I had an issue with the ORM extension and integrators I need to figure out - the config needs some love to be more future proof but it's already in pretty good shape - in the meantime, Yoann and Fabio made good progress in making Search 6 usable (but still experimental, APIs are still evolving) I think I was really not far from making it work last time I worked on it. All in all, I plan to hopefully finish this next week. It will be Search 6 *Alpha*. And it will be Elasticsearch only for now. On Sat, Mar 9, 2019 at 9:34 AM Emmanuel Bernard wrote: > https://twitter.com/quarkusio/status/1104297031273775106?s=21 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From yoann at hibernate.org Mon Mar 11 03:10:56 2019 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 11 Mar 2019 08:10:56 +0100 Subject: [hibernate-dev] Quarkus + search request In-Reply-To: References: Message-ID: Basically what Guillaume said. Guillaume, I don't know if you discussed it already, but Sanne is planning to have a look at this Integrator issue, apparently it's supposed to work already, so there's probably a bug if it doesn't work. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Sat, 9 Mar 2019 at 13:54, Guillaume Smet wrote: > So a quick note about where we're at: > - Yoann is mostly done with the changes to make in Search 6 (it probably > needs a rebase and I need to test them but if I don't find any issue, it's > done) > - I need to rebase my work on top of all the Quarkus renamings > - I had an issue with the ORM extension and integrators I need to figure > out > - the config needs some love to be more future proof but it's already in > pretty good shape > - in the meantime, Yoann and Fabio made good progress in making Search 6 > usable (but still experimental, APIs are still evolving) > > I think I was really not far from making it work last time I worked on it. > > All in all, I plan to hopefully finish this next week. > > It will be Search 6 *Alpha*. And it will be Elasticsearch only for now. > > On Sat, Mar 9, 2019 at 9:34 AM Emmanuel Bernard > wrote: > > > https://twitter.com/quarkusio/status/1104297031273775106?s=21 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Tue Mar 12 10:24:53 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 12 Mar 2019 15:24:53 +0100 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of this week's NoORM IRC meeting: 15:23 < jbott> Meeting ended Tue Mar 12 14:22:50 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:23 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-03-12-14.00.html 15:23 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-03-12-14.00.txt 15:23 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-03-12-14.00.log.html Cheers. -- Guillaume From rory.odonnell at oracle.com Wed Mar 20 04:55:32 2019 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Wed, 20 Mar 2019 08:55:32 +0000 Subject: [hibernate-dev] Release Announcement: General Availability of Java 12 / JDK 12 Message-ID: <74fadec5-db88-b245-ebdc-ca9115d1f7f2@oracle.com> Hi Sanne, *1) Release Announcement: General Availability of Java 12 / JDK 12 [1] * * JDK 12, the reference implementation of Java 12, is now Generally Available. * GPL-licensed OpenJDK builds from Oracle are available here: https://jdk.java.net/12 This release includes the following? eight features: * JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental) * JEP 230: Microbenchmark Suite * JEP 334: JVM Constants API * JEP 340: One AArch64 Port, Not Two * JEP 341: Default CDS Archives * JEP 344: Abortable Mixed Collections for G1 * JEP 346: Promptly Return Unused Committed Memory from G1 * JEP 325: Switch Expressions (Preview) Thanks to everyone who contributed JDK 12, whether by creating features or enhancements, logging? bugs, or downloading and testing the early-access builds. *2) JDK 13 EA build 12, under both the GPL and Oracle EA licenses, is now available at **http://jdk.java.net/13**.* * Proposed - Schedule for JDK 13 [2] o 2019/06/13 Rampdown Phase One o 2019/07/18 Rampdown Phase Two o 2019/08/08 Initial Release Candidate o 2019/08/22 Final Release Candidate o 2019/09/17 General Availability * Recent Bug fixes of Interest o Build 9: + 8214719: Deprecate -Xverify:none option + 8216360: Deprecate -XX:CompilationPolicyChoice o Build 10: + 8218995: Deprecate the -XX:FailOverToOldVerifier option o Build 12 : 8160247: Mark deprecated javax.security.cert APIs with forRemoval=true + 8220050: Deprecate -XX:-ThreadLocalHandshakes + Apache Lucene Reported - 8219448: split-if update_uses accesses stale idom data * Changes in this build [3] Rgds,Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002718.html [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002716.html [3] Changes in this build -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From guillaume.smet at hibernate.org Thu Mar 21 15:23:29 2019 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Thu, 21 Mar 2019 20:23:29 +0100 Subject: [hibernate-dev] Hibernate Validator 6.0.16.Final released Message-ID: Hi, We just released Hibernate Validator 6.0.16.Final with a few bugfixes. Hibernate Validator is now also tested with JDK 12. More information about the release can be found in the announcement: http://in.relation.to/2019/03/21/hibernate-validator-6016-final-out/ . Have a nice day. -- Guillaume From gbadner at redhat.com Fri Mar 22 02:54:32 2019 From: gbadner at redhat.com (Gail Badner) Date: Thu, 21 Mar 2019 23:54:32 -0700 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing Message-ID: Scott added bytecode enhancement to some WildFly tests for WFLY-11891 [1], which are failing. Here is Scott's PR with the updated tests: [2] When I stepped into org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase, I can see that they are failing in ByteBuddy code. I see that: - enhancement of org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets skipped several times in a row; - enhancement of some other classes get skipped; - before trying to enhance org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, an exception is thrown. Unfortunately, I'm having trouble getting a good stacktrace to show what happens in ByteBuddy code. Here is what I'm seeing: net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") /* class name differs from run to run */ calls net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( " org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") calls net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate( classLoader, "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5" ) calls classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"), which returns null; (I don't actually see a class file with this name) returns new TypePool.Resolution.Illegal( "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class" ) returns TypePool.Resolution.Illegal Ultimately, TypePool.Resolution.Illegal#resolve( ) throws IllegalStateException, because the type description cannot be resolved. I'm not sure if the problem is in WildFly, Hibernate, or ByteBuddy. To build WildFly: ./build.sh clean install -DskipTests=true To run the test: cd testsuite/integration/basic mvn install -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase Help would be very much appreciated. Thanks, Gail [1] https://issues.jboss.org/browse/WFLY-11891 [2] https://github.com/wildfly/wildfly/pull/12180 From guillaume.smet at hibernate.org Fri Mar 22 07:04:15 2019 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Fri, 22 Mar 2019 12:04:15 +0100 Subject: [hibernate-dev] Hibernate ORM 5.4.2.Final released Message-ID: Hi, We just released Hibernate ORM 5.4.2.Final. More information here: http://in.relation.to/2019/03/22/hibernate-orm-542-final-out/ . Have a nice day. -- Guillaume From guillaume.smet at gmail.com Fri Mar 22 07:49:59 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 22 Mar 2019 12:49:59 +0100 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: References: Message-ID: Hi Gail, Do we have any idea of what this class is supposed to be: org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 ? Scott, any idea? Because it doesn't ring a bell on my side. I suspect it's a class we shouldn't access or touch. And we should probably add a condition somewhere to avoid doing so. If you can give me the Hibernate call which initiates the error, that would be nice. And stupid question: we did not have any enhancement test in WildFly before that? -- Guillaume On Fri, Mar 22, 2019 at 7:59 AM Gail Badner wrote: > Scott added bytecode enhancement to some WildFly tests for WFLY-11891 [1], > which are failing. > > Here is Scott's PR with the updated tests: [2] > > When I stepped into > > org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase, > I can see that they are failing in ByteBuddy code. > > I see that: > > - enhancement of > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets > skipped several times in a row; > - enhancement of some other classes get skipped; > - before trying to enhance > > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, an > exception is thrown. > > Unfortunately, I'm having trouble getting a good stacktrace to show what > happens in ByteBuddy code. > > Here is what I'm seeing: > > > net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") > /* class name differs from run to run */ > > > calls net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( " > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") > > calls net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate( > classLoader, > "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5" > ) > > calls > > classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"), > which returns null; > > (I don't actually see a class file with this name) > > > returns new TypePool.Resolution.Illegal( > > > "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class" > > ) > > returns TypePool.Resolution.Illegal > > > Ultimately, TypePool.Resolution.Illegal#resolve( ) throws > IllegalStateException, because the type description cannot be resolved. > > I'm not sure if the problem is in WildFly, Hibernate, or ByteBuddy. > > To build WildFly: > ./build.sh clean install -DskipTests=true > > To run the test: > cd testsuite/integration/basic > mvn install > > -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase > > Help would be very much appreciated. > > Thanks, > Gail > > [1] https://issues.jboss.org/browse/WFLY-11891 > [2] https://github.com/wildfly/wildfly/pull/12180 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From smarlow at redhat.com Fri Mar 22 09:11:50 2019 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 22 Mar 2019 09:11:50 -0400 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: References: Message-ID: <780f30b5-d59c-ce5c-ffc0-848b81f1a3d5@redhat.com> On 3/22/19 7:49 AM, Guillaume Smet wrote: > Hi Gail, > > Do we have any idea of what this class is supposed to be: > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 ? This is a unit test class that is not an entity class, but instead it happens to be an EJB stateless session bean. In the exception call stack [1], the class that ByteBuddy complains about is a WildFly class (not even a test class), you can see that in the exception message SerializationProxyHackImplementation [2]. > Scott, any idea? I was not really aware that classes like SerializationProxyHackImplementation [2] , would also be handled by org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() but I guess that makes sense, as application classloaders versus application module classloaders, are not distinguished internally in WF. I'm also not sure of how Javassist handles ignoring the SerializationProxyHackImplementation [2] class but Javassist does work fine (as long as you work around the other issue, which is that Javassist can only be selected via system property setting but not persistence.xml setting, also mentioned in WFLY-11891 [3]). > > Because it doesn't ring a bell on my side. > > I suspect it's a class we shouldn't access or touch. And we should probably > add a condition somewhere to avoid doing so. Agreed. > > If you can give me the Hibernate call which initiates the error, that would > be nice. [1] shows the exception call stack (look for "org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.lambda$enhance$0(EnhancerImpl.java:137)" > > And stupid question: we did not have any enhancement test in WildFly before > that? > No, sadly, this is the first time we updated the WildFly unit tests to try Javassist + ByteBuddy enhancement. Its a very light test with little verification, basically we just modified some existing tests to include: hibernate.enhancer.enableDirtyTracking=true hibernate.enhancer.enableLazyInitialization=true hibernate.enhancer.enableAssociationManagement=true And one test was also modified to specify hibernate.bytecode.provider=javassist, which is ignored (only the system property works, via standalone.sh -Dhibernate.bytecode.provider=javassist). The problem is also mentioned in WFLY-11891 [3]. In WF, we also have a mock persistence provider test that ensures that persistence providers can enhance classes as per the JPA container contract. Scott [1] https://issues.jboss.org/browse/WFLY-11891?focusedCommentId=13711809&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13711809 [2] java.lang.IllegalStateException: Cannot resolve type description for org.jboss.as.ejb3.SerializationProxyHackImplementation [3] https://issues.jboss.org/browse/WFLY-11891 From smarlow at redhat.com Fri Mar 22 09:24:21 2019 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 22 Mar 2019 09:24:21 -0400 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: <780f30b5-d59c-ce5c-ffc0-848b81f1a3d5@redhat.com> References: <780f30b5-d59c-ce5c-ffc0-848b81f1a3d5@redhat.com> Message-ID: <3d0e458d-f515-f7c6-0a36-cbaadccd3318@redhat.com> On 3/22/19 9:11 AM, Scott Marlow wrote: > > > On 3/22/19 7:49 AM, Guillaume Smet wrote: >> Hi Gail, >> >> Do we have any idea of what this class is supposed to be: >> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 ? > > This is a unit test class that is not an entity class, but instead it > happens to be an EJB stateless session bean.? In the exception call > stack [1], the class that ByteBuddy complains about is a WildFly class > (not even a test class), you can see that in the exception message > SerializationProxyHackImplementation [2]. > >> Scott, any idea? > > I was not really aware that classes like > SerializationProxyHackImplementation [2] , would also be handled by > org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() > but I guess that makes sense, as application classloaders versus > application module classloaders, are not distinguished internally in WF. I meant that class file transformers will be called for both application classes and WF classes as well. > > I'm also not sure of how Javassist handles ignoring the > SerializationProxyHackImplementation [2] class but Javassist does work > fine (as long as you work around the other issue, which is that > Javassist can only be selected via system property setting but not > persistence.xml setting, also mentioned in WFLY-11891 [3]). > >> >> Because it doesn't ring a bell on my side. >> >> I suspect it's a class we shouldn't access or touch. And we should >> probably >> add a condition somewhere to avoid doing so. > > Agreed. > >> >> If you can give me the Hibernate call which initiates the error, that >> would >> be nice. > > [1] shows the exception call stack (look for > "org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.lambda$enhance$0(EnhancerImpl.java:137)" > > > >> >> And stupid question: we did not have any enhancement test in WildFly >> before >> that? >> > > No, sadly, this is the first time we updated the WildFly unit tests to > try Javassist + ByteBuddy enhancement.? Its a very light test with > little verification, basically we just modified some existing tests to > include: > > hibernate.enhancer.enableDirtyTracking=true > hibernate.enhancer.enableLazyInitialization=true > hibernate.enhancer.enableAssociationManagement=true > > And one test was also modified to specify > hibernate.bytecode.provider=javassist, which is ignored (only the system > property works, via standalone.sh > -Dhibernate.bytecode.provider=javassist).? The problem is also mentioned > in WFLY-11891 [3]. > > In WF, we also have a mock persistence provider test that ensures that > persistence providers can enhance classes as per the JPA container > contract. > > Scott > > [1] > https://issues.jboss.org/browse/WFLY-11891?focusedCommentId=13711809&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13711809 > > > [2] java.lang.IllegalStateException: Cannot resolve type description for > org.jboss.as.ejb3.SerializationProxyHackImplementation > > [3] https://issues.jboss.org/browse/WFLY-11891 From yoann at hibernate.org Fri Mar 22 09:36:06 2019 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 22 Mar 2019 14:36:06 +0100 Subject: [hibernate-dev] Hibernate Search 6.0.0.Alpha3 released Message-ID: Hello, We just published Hibernate Search 6.0.0.Alpha3, the third release for the still-in-development 6.0 branch. This release mainly adds support for more field types and predicates, and brings more consistent and less verbose APIs. This version is an early technology preview, so be sure to read about it on our blog before you try it out: http://in.relation.to/2019/03/22/hibernate-search-6-0-0-Alpha3/ Cheers, Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From smarlow at redhat.com Fri Mar 22 10:08:09 2019 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 22 Mar 2019 10:08:09 -0400 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: <3d0e458d-f515-f7c6-0a36-cbaadccd3318@redhat.com> References: <780f30b5-d59c-ce5c-ffc0-848b81f1a3d5@redhat.com> <3d0e458d-f515-f7c6-0a36-cbaadccd3318@redhat.com> Message-ID: <65694da9-32e9-b0d4-6051-3059e4050456@redhat.com> On 3/22/19 9:24 AM, Scott Marlow wrote: > > > On 3/22/19 9:11 AM, Scott Marlow wrote: >> >> >> On 3/22/19 7:49 AM, Guillaume Smet wrote: >>> Hi Gail, >>> >>> Do we have any idea of what this class is supposed to be: >>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 >>> ? >> >> This is a unit test class that is not an entity class, but instead it >> happens to be an EJB stateless session bean.? In the exception call >> stack [1], the class that ByteBuddy complains about is a WildFly class >> (not even a test class), you can see that in the exception message >> SerializationProxyHackImplementation [2]. >> >>> Scott, any idea? >> >> I was not really aware that classes like >> SerializationProxyHackImplementation [2] , would also be handled by >> org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() >> but I guess that makes sense, as application classloaders versus >> application module classloaders, are not distinguished internally in WF. > > I meant that class file transformers will be called for both application > classes and WF classes as well. I'm going to see if I can hack around this failure in WF code, so that WF doesn't call into Hibernate to transform the org.jboss.as.ejb3.SerializationProxyHackImplementation class. > >> >> I'm also not sure of how Javassist handles ignoring the >> SerializationProxyHackImplementation [2] class but Javassist does work >> fine (as long as you work around the other issue, which is that >> Javassist can only be selected via system property setting but not >> persistence.xml setting, also mentioned in WFLY-11891 [3]). >> >>> >>> Because it doesn't ring a bell on my side. >>> >>> I suspect it's a class we shouldn't access or touch. And we should >>> probably >>> add a condition somewhere to avoid doing so. >> >> Agreed. >> >>> >>> If you can give me the Hibernate call which initiates the error, that >>> would >>> be nice. >> >> [1] shows the exception call stack (look for >> "org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.lambda$enhance$0(EnhancerImpl.java:137)" >> >> >> >>> >>> And stupid question: we did not have any enhancement test in WildFly >>> before >>> that? >>> >> >> No, sadly, this is the first time we updated the WildFly unit tests to >> try Javassist + ByteBuddy enhancement.? Its a very light test with >> little verification, basically we just modified some existing tests to >> include: >> >> hibernate.enhancer.enableDirtyTracking=true >> hibernate.enhancer.enableLazyInitialization=true >> hibernate.enhancer.enableAssociationManagement=true >> >> And one test was also modified to specify >> hibernate.bytecode.provider=javassist, which is ignored (only the >> system property works, via standalone.sh >> -Dhibernate.bytecode.provider=javassist).? The problem is also >> mentioned in WFLY-11891 [3]. >> >> In WF, we also have a mock persistence provider test that ensures that >> persistence providers can enhance classes as per the JPA container >> contract. >> >> Scott >> >> [1] >> https://issues.jboss.org/browse/WFLY-11891?focusedCommentId=13711809&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13711809 >> >> >> [2] java.lang.IllegalStateException: Cannot resolve type description >> for org.jboss.as.ejb3.SerializationProxyHackImplementation >> >> [3] https://issues.jboss.org/browse/WFLY-11891 From smarlow at redhat.com Fri Mar 22 10:22:34 2019 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 22 Mar 2019 10:22:34 -0400 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: <65694da9-32e9-b0d4-6051-3059e4050456@redhat.com> References: <780f30b5-d59c-ce5c-ffc0-848b81f1a3d5@redhat.com> <3d0e458d-f515-f7c6-0a36-cbaadccd3318@redhat.com> <65694da9-32e9-b0d4-6051-3059e4050456@redhat.com> Message-ID: <3c3bf2ab-34e9-1088-af16-61e95973cc84@redhat.com> On 3/22/19 10:08 AM, Scott Marlow wrote: > > > On 3/22/19 9:24 AM, Scott Marlow wrote: >> >> >> On 3/22/19 9:11 AM, Scott Marlow wrote: >>> >>> >>> On 3/22/19 7:49 AM, Guillaume Smet wrote: >>>> Hi Gail, >>>> >>>> Do we have any idea of what this class is supposed to be: >>>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 >>>> ? >>> >>> This is a unit test class that is not an entity class, but instead it >>> happens to be an EJB stateless session bean.? In the exception call >>> stack [1], the class that ByteBuddy complains about is a WildFly >>> class (not even a test class), you can see that in the exception >>> message SerializationProxyHackImplementation [2]. >>> >>>> Scott, any idea? >>> >>> I was not really aware that classes like >>> SerializationProxyHackImplementation [2] , would also be handled by >>> org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() >>> but I guess that makes sense, as application classloaders versus >>> application module classloaders, are not distinguished internally in WF. >> >> I meant that class file transformers will be called for both >> application classes and WF classes as well. > > I'm going to see if I can hack around this failure in WF code, so that > WF doesn't call into Hibernate to transform the > org.jboss.as.ejb3.SerializationProxyHackImplementation class. I tried changing org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() to filter out any non-application classes but that didn't help as DelegatingClassFileTransformer.transform() doesn't get called to transform the SerializationProxyHackImplementation [2] class. It might be that the application classes are getting injected with a classloader that references the SerializationProxyHackImplementation [2] class. IMO, this probably should be fixed in Hibernate ORM or ByteBuddy. > >> >>> >>> I'm also not sure of how Javassist handles ignoring the >>> SerializationProxyHackImplementation [2] class but Javassist does >>> work fine (as long as you work around the other issue, which is that >>> Javassist can only be selected via system property setting but not >>> persistence.xml setting, also mentioned in WFLY-11891 [3]). >>> >>>> >>>> Because it doesn't ring a bell on my side. >>>> >>>> I suspect it's a class we shouldn't access or touch. And we should >>>> probably >>>> add a condition somewhere to avoid doing so. >>> >>> Agreed. >>> >>>> >>>> If you can give me the Hibernate call which initiates the error, >>>> that would >>>> be nice. >>> >>> [1] shows the exception call stack (look for >>> "org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.lambda$enhance$0(EnhancerImpl.java:137)" >>> >>> >>> >>>> >>>> And stupid question: we did not have any enhancement test in WildFly >>>> before >>>> that? >>>> >>> >>> No, sadly, this is the first time we updated the WildFly unit tests >>> to try Javassist + ByteBuddy enhancement.? Its a very light test with >>> little verification, basically we just modified some existing tests >>> to include: >>> >>> hibernate.enhancer.enableDirtyTracking=true >>> hibernate.enhancer.enableLazyInitialization=true >>> hibernate.enhancer.enableAssociationManagement=true >>> >>> And one test was also modified to specify >>> hibernate.bytecode.provider=javassist, which is ignored (only the >>> system property works, via standalone.sh >>> -Dhibernate.bytecode.provider=javassist).? The problem is also >>> mentioned in WFLY-11891 [3]. >>> >>> In WF, we also have a mock persistence provider test that ensures >>> that persistence providers can enhance classes as per the JPA >>> container contract. >>> >>> Scott >>> >>> [1] >>> https://issues.jboss.org/browse/WFLY-11891?focusedCommentId=13711809&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13711809 >>> >>> >>> [2] java.lang.IllegalStateException: Cannot resolve type description >>> for org.jboss.as.ejb3.SerializationProxyHackImplementation >>> >>> [3] https://issues.jboss.org/browse/WFLY-11891 From gbadner at redhat.com Fri Mar 22 13:53:43 2019 From: gbadner at redhat.com (Gail Badner) Date: Fri, 22 Mar 2019 10:53:43 -0700 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: <3c3bf2ab-34e9-1088-af16-61e95973cc84@redhat.com> References: <780f30b5-d59c-ce5c-ffc0-848b81f1a3d5@redhat.com> <3d0e458d-f515-f7c6-0a36-cbaadccd3318@redhat.com> <65694da9-32e9-b0d4-6051-3059e4050456@redhat.com> <3c3bf2ab-34e9-1088-af16-61e95973cc84@redhat.com> Message-ID: I just wanted to clarify that sometimes I was seeing problems with SerializationProxyHackImplementation. When debugging, I usually saw a failure on SLSBPersistenceContexts$$$viewX, where (IIRC) X was between 1 and 9. On Fri, Mar 22, 2019 at 7:22 AM Scott Marlow wrote: > > > On 3/22/19 10:08 AM, Scott Marlow wrote: > > > > > > On 3/22/19 9:24 AM, Scott Marlow wrote: > >> > >> > >> On 3/22/19 9:11 AM, Scott Marlow wrote: > >>> > >>> > >>> On 3/22/19 7:49 AM, Guillaume Smet wrote: > >>>> Hi Gail, > >>>> > >>>> Do we have any idea of what this class is supposed to be: > >>>> > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 > >>>> ? > >>> > >>> This is a unit test class that is not an entity class, but instead it > >>> happens to be an EJB stateless session bean. In the exception call > >>> stack [1], the class that ByteBuddy complains about is a WildFly > >>> class (not even a test class), you can see that in the exception > >>> message SerializationProxyHackImplementation [2]. > >>> > >>>> Scott, any idea? > >>> > >>> I was not really aware that classes like > >>> SerializationProxyHackImplementation [2] , would also be handled by > >>> > org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() > > >>> but I guess that makes sense, as application classloaders versus > >>> application module classloaders, are not distinguished internally in > WF. > >> > >> I meant that class file transformers will be called for both > >> application classes and WF classes as well. > > > > I'm going to see if I can hack around this failure in WF code, so that > > WF doesn't call into Hibernate to transform the > > org.jboss.as.ejb3.SerializationProxyHackImplementation class. > > I tried changing > org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() > > to filter out any non-application classes but that didn't help as > DelegatingClassFileTransformer.transform() doesn't get called to > transform the SerializationProxyHackImplementation [2] class. > > It might be that the application classes are getting injected with a > classloader that references the SerializationProxyHackImplementation [2] > class. > > IMO, this probably should be fixed in Hibernate ORM or ByteBuddy. > > > > >> > >>> > >>> I'm also not sure of how Javassist handles ignoring the > >>> SerializationProxyHackImplementation [2] class but Javassist does > >>> work fine (as long as you work around the other issue, which is that > >>> Javassist can only be selected via system property setting but not > >>> persistence.xml setting, also mentioned in WFLY-11891 [3]). > >>> > >>>> > >>>> Because it doesn't ring a bell on my side. > >>>> > >>>> I suspect it's a class we shouldn't access or touch. And we should > >>>> probably > >>>> add a condition somewhere to avoid doing so. > >>> > >>> Agreed. > >>> > >>>> > >>>> If you can give me the Hibernate call which initiates the error, > >>>> that would > >>>> be nice. > >>> > >>> [1] shows the exception call stack (look for > >>> > "org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.lambda$enhance$0(EnhancerImpl.java:137)" > > >>> > >>> > >>> > >>>> > >>>> And stupid question: we did not have any enhancement test in WildFly > >>>> before > >>>> that? > >>>> > >>> > >>> No, sadly, this is the first time we updated the WildFly unit tests > >>> to try Javassist + ByteBuddy enhancement. Its a very light test with > >>> little verification, basically we just modified some existing tests > >>> to include: > >>> > >>> hibernate.enhancer.enableDirtyTracking=true > >>> hibernate.enhancer.enableLazyInitialization=true > >>> hibernate.enhancer.enableAssociationManagement=true > >>> > >>> And one test was also modified to specify > >>> hibernate.bytecode.provider=javassist, which is ignored (only the > >>> system property works, via standalone.sh > >>> -Dhibernate.bytecode.provider=javassist). The problem is also > >>> mentioned in WFLY-11891 [3]. > >>> > >>> In WF, we also have a mock persistence provider test that ensures > >>> that persistence providers can enhance classes as per the JPA > >>> container contract. > >>> > >>> Scott > >>> > >>> [1] > >>> > https://issues.jboss.org/browse/WFLY-11891?focusedCommentId=13711809&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13711809 > >>> > >>> > >>> [2] java.lang.IllegalStateException: Cannot resolve type description > >>> for org.jboss.as.ejb3.SerializationProxyHackImplementation > >>> > >>> [3] https://issues.jboss.org/browse/WFLY-11891 > From smarlow at redhat.com Fri Mar 22 15:34:41 2019 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 22 Mar 2019 15:34:41 -0400 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: References: <780f30b5-d59c-ce5c-ffc0-848b81f1a3d5@redhat.com> <3d0e458d-f515-f7c6-0a36-cbaadccd3318@redhat.com> <65694da9-32e9-b0d4-6051-3059e4050456@redhat.com> <3c3bf2ab-34e9-1088-af16-61e95973cc84@redhat.com> Message-ID: <7525bb8c-9c8c-1c37-0e8a-67ba6f9e155b@redhat.com> On 3/22/19 1:53 PM, Gail Badner wrote: > I just wanted to clarify that sometimes I was seeing problems with > SerializationProxyHackImplementation. When debugging, I usually saw a > failure on SLSBPersistenceContexts$$$viewX, where (IIRC) X was between 1 > and 9. I'm guessing that the SLSBPersistenceContexts$$$viewX classes are generated by the WildFly EJB container, for the (test) application EJB bean org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts. I'm not sure why the failure is varying between different classes. For the weird org.jboss.as.ejb3.SerializationProxyHackImplementation failure, SerializationProxyHackImplementation is a dynamically generated server class apparently, that comes from https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/iiop/handle/SerializationHackProxy.java#L57 Scott > > On Fri, Mar 22, 2019 at 7:22 AM Scott Marlow > wrote: > > > > On 3/22/19 10:08 AM, Scott Marlow wrote: > > > > > > On 3/22/19 9:24 AM, Scott Marlow wrote: > >> > >> > >> On 3/22/19 9:11 AM, Scott Marlow wrote: > >>> > >>> > >>> On 3/22/19 7:49 AM, Guillaume Smet wrote: > >>>> Hi Gail, > >>>> > >>>> Do we have any idea of what this class is supposed to be: > >>>> > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 > >>>> ? > >>> > >>> This is a unit test class that is not an entity class, but > instead it > >>> happens to be an EJB stateless session bean.? In the exception > call > >>> stack [1], the class that ByteBuddy complains about is a WildFly > >>> class (not even a test class), you can see that in the exception > >>> message SerializationProxyHackImplementation [2]. > >>> > >>>> Scott, any idea? > >>> > >>> I was not really aware that classes like > >>> SerializationProxyHackImplementation [2] , would also be > handled by > >>> > org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() > > >>> but I guess that makes sense, as application classloaders versus > >>> application module classloaders, are not distinguished > internally in WF. > >> > >> I meant that class file transformers will be called for both > >> application classes and WF classes as well. > > > > I'm going to see if I can hack around this failure in WF code, so > that > > WF doesn't call into Hibernate to transform the > > org.jboss.as.ejb3.SerializationProxyHackImplementation class. > > I tried changing > org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() > > to filter out any non-application classes but that didn't help as > DelegatingClassFileTransformer.transform() doesn't get called to > transform the SerializationProxyHackImplementation [2] class. > > It might be that the application classes are getting injected with a > classloader that references the SerializationProxyHackImplementation > [2] > class. > > IMO, this probably should be fixed in Hibernate ORM or ByteBuddy. > > > > >> > >>> > >>> I'm also not sure of how Javassist handles ignoring the > >>> SerializationProxyHackImplementation [2] class but Javassist does > >>> work fine (as long as you work around the other issue, which is > that > >>> Javassist can only be selected via system property setting but not > >>> persistence.xml setting, also mentioned in WFLY-11891 [3]). > >>> > >>>> > >>>> Because it doesn't ring a bell on my side. > >>>> > >>>> I suspect it's a class we shouldn't access or touch. And we > should > >>>> probably > >>>> add a condition somewhere to avoid doing so. > >>> > >>> Agreed. > >>> > >>>> > >>>> If you can give me the Hibernate call which initiates the error, > >>>> that would > >>>> be nice. > >>> > >>> [1] shows the exception call stack (look for > >>> > "org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.lambda$enhance$0(EnhancerImpl.java:137)" > > >>> > >>> > >>> > >>>> > >>>> And stupid question: we did not have any enhancement test in > WildFly > >>>> before > >>>> that? > >>>> > >>> > >>> No, sadly, this is the first time we updated the WildFly unit > tests > >>> to try Javassist + ByteBuddy enhancement.? Its a very light > test with > >>> little verification, basically we just modified some existing > tests > >>> to include: > >>> > >>> hibernate.enhancer.enableDirtyTracking=true > >>> hibernate.enhancer.enableLazyInitialization=true > >>> hibernate.enhancer.enableAssociationManagement=true > >>> > >>> And one test was also modified to specify > >>> hibernate.bytecode.provider=javassist, which is ignored (only the > >>> system property works, via standalone.sh > >>> -Dhibernate.bytecode.provider=javassist).? The problem is also > >>> mentioned in WFLY-11891 [3]. > >>> > >>> In WF, we also have a mock persistence provider test that ensures > >>> that persistence providers can enhance classes as per the JPA > >>> container contract. > >>> > >>> Scott > >>> > >>> [1] > >>> > https://issues.jboss.org/browse/WFLY-11891?focusedCommentId=13711809&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13711809 > > >>> > >>> > >>> [2] java.lang.IllegalStateException: Cannot resolve type > description > >>> for org.jboss.as.ejb3.SerializationProxyHackImplementation > >>> > >>> [3] https://issues.jboss.org/browse/WFLY-11891 > From gbadner at redhat.com Fri Mar 22 16:01:20 2019 From: gbadner at redhat.com (Gail Badner) Date: Fri, 22 Mar 2019 13:01:20 -0700 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: <7525bb8c-9c8c-1c37-0e8a-67ba6f9e155b@redhat.com> References: <780f30b5-d59c-ce5c-ffc0-848b81f1a3d5@redhat.com> <3d0e458d-f515-f7c6-0a36-cbaadccd3318@redhat.com> <65694da9-32e9-b0d4-6051-3059e4050456@redhat.com> <3c3bf2ab-34e9-1088-af16-61e95973cc84@redhat.com> <7525bb8c-9c8c-1c37-0e8a-67ba6f9e155b@redhat.com> Message-ID: Should dynamically generated classes be possible to load from a ClassLoader by a name like org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class ? On Fri, Mar 22, 2019 at 12:34 PM Scott Marlow wrote: > > On 3/22/19 1:53 PM, Gail Badner wrote: > > I just wanted to clarify that sometimes I was seeing problems with > > SerializationProxyHackImplementation. When debugging, I usually saw a > > failure on SLSBPersistenceContexts$$$viewX, where (IIRC) X was between 1 > > and 9. > > I'm guessing that the SLSBPersistenceContexts$$$viewX classes are > generated by the WildFly EJB container, for the (test) application EJB > bean org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts. > > I'm not sure why the failure is varying between different classes. For > the weird org.jboss.as.ejb3.SerializationProxyHackImplementation > failure, SerializationProxyHackImplementation is a dynamically generated > server class apparently, that comes from > > https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/iiop/handle/SerializationHackProxy.java#L57 > > Scott > > > > > On Fri, Mar 22, 2019 at 7:22 AM Scott Marlow > > wrote: > > > > > > > > On 3/22/19 10:08 AM, Scott Marlow wrote: > > > > > > > > > On 3/22/19 9:24 AM, Scott Marlow wrote: > > >> > > >> > > >> On 3/22/19 9:11 AM, Scott Marlow wrote: > > >>> > > >>> > > >>> On 3/22/19 7:49 AM, Guillaume Smet wrote: > > >>>> Hi Gail, > > >>>> > > >>>> Do we have any idea of what this class is supposed to be: > > >>>> > > > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 > > >>>> ? > > >>> > > >>> This is a unit test class that is not an entity class, but > > instead it > > >>> happens to be an EJB stateless session bean. In the exception > > call > > >>> stack [1], the class that ByteBuddy complains about is a WildFly > > >>> class (not even a test class), you can see that in the exception > > >>> message SerializationProxyHackImplementation [2]. > > >>> > > >>>> Scott, any idea? > > >>> > > >>> I was not really aware that classes like > > >>> SerializationProxyHackImplementation [2] , would also be > > handled by > > >>> > > > org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() > > > > >>> but I guess that makes sense, as application classloaders versus > > >>> application module classloaders, are not distinguished > > internally in WF. > > >> > > >> I meant that class file transformers will be called for both > > >> application classes and WF classes as well. > > > > > > I'm going to see if I can hack around this failure in WF code, so > > that > > > WF doesn't call into Hibernate to transform the > > > org.jboss.as.ejb3.SerializationProxyHackImplementation class. > > > > I tried changing > > > org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() > > > > to filter out any non-application classes but that didn't help as > > DelegatingClassFileTransformer.transform() doesn't get called to > > transform the SerializationProxyHackImplementation [2] class. > > > > It might be that the application classes are getting injected with a > > classloader that references the SerializationProxyHackImplementation > > [2] > > class. > > > > IMO, this probably should be fixed in Hibernate ORM or ByteBuddy. > > > > > > > >> > > >>> > > >>> I'm also not sure of how Javassist handles ignoring the > > >>> SerializationProxyHackImplementation [2] class but Javassist > does > > >>> work fine (as long as you work around the other issue, which is > > that > > >>> Javassist can only be selected via system property setting but > not > > >>> persistence.xml setting, also mentioned in WFLY-11891 [3]). > > >>> > > >>>> > > >>>> Because it doesn't ring a bell on my side. > > >>>> > > >>>> I suspect it's a class we shouldn't access or touch. And we > > should > > >>>> probably > > >>>> add a condition somewhere to avoid doing so. > > >>> > > >>> Agreed. > > >>> > > >>>> > > >>>> If you can give me the Hibernate call which initiates the > error, > > >>>> that would > > >>>> be nice. > > >>> > > >>> [1] shows the exception call stack (look for > > >>> > > > "org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.lambda$enhance$0(EnhancerImpl.java:137)" > > > > >>> > > >>> > > >>> > > >>>> > > >>>> And stupid question: we did not have any enhancement test in > > WildFly > > >>>> before > > >>>> that? > > >>>> > > >>> > > >>> No, sadly, this is the first time we updated the WildFly unit > > tests > > >>> to try Javassist + ByteBuddy enhancement. Its a very light > > test with > > >>> little verification, basically we just modified some existing > > tests > > >>> to include: > > >>> > > >>> hibernate.enhancer.enableDirtyTracking=true > > >>> hibernate.enhancer.enableLazyInitialization=true > > >>> hibernate.enhancer.enableAssociationManagement=true > > >>> > > >>> And one test was also modified to specify > > >>> hibernate.bytecode.provider=javassist, which is ignored (only > the > > >>> system property works, via standalone.sh > > >>> -Dhibernate.bytecode.provider=javassist). The problem is also > > >>> mentioned in WFLY-11891 [3]. > > >>> > > >>> In WF, we also have a mock persistence provider test that > ensures > > >>> that persistence providers can enhance classes as per the JPA > > >>> container contract. > > >>> > > >>> Scott > > >>> > > >>> [1] > > >>> > > > https://issues.jboss.org/browse/WFLY-11891?focusedCommentId=13711809&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13711809 > > > > >>> > > >>> > > >>> [2] java.lang.IllegalStateException: Cannot resolve type > > description > > >>> for org.jboss.as.ejb3.SerializationProxyHackImplementation > > >>> > > >>> [3] https://issues.jboss.org/browse/WFLY-11891 > > > From smarlow at redhat.com Fri Mar 22 17:47:39 2019 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 22 Mar 2019 17:47:39 -0400 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: References: <780f30b5-d59c-ce5c-ffc0-848b81f1a3d5@redhat.com> <3d0e458d-f515-f7c6-0a36-cbaadccd3318@redhat.com> <65694da9-32e9-b0d4-6051-3059e4050456@redhat.com> <3c3bf2ab-34e9-1088-af16-61e95973cc84@redhat.com> <7525bb8c-9c8c-1c37-0e8a-67ba6f9e155b@redhat.com> Message-ID: Actually, the generated SerializationProxyHackImplementation class looks to be generated with the application classloader. I assume the same is true for the $$$view5.class. On 3/22/19 4:01 PM, Gail Badner wrote: > Should dynamically generated classes be possible to load from a > ClassLoader by a name like > org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class > ? Yes, I think they should be possible to "define" them (not really loading them, since I think they are dynamically generated classes), it seems like ByteBuddy just doesn't like these generated classes for some reason (or something like that). > > On Fri, Mar 22, 2019 at 12:34 PM Scott Marlow > wrote: > > > On 3/22/19 1:53 PM, Gail Badner wrote: > > I just wanted to clarify that sometimes I was seeing problems with > > SerializationProxyHackImplementation. When debugging, I usually > saw a > > failure on SLSBPersistenceContexts$$$viewX, where (IIRC) X was > between 1 > > and 9. > > I'm guessing that the SLSBPersistenceContexts$$$viewX classes are > generated by the WildFly EJB container, for the (test) application EJB > bean org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts. > > I'm not sure why the failure is varying between different classes.? For > the weird org.jboss.as.ejb3.SerializationProxyHackImplementation > failure, SerializationProxyHackImplementation is a dynamically > generated > server class apparently, that comes from > https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/iiop/handle/SerializationHackProxy.java#L57 > > Scott > > > > > On Fri, Mar 22, 2019 at 7:22 AM Scott Marlow > > >> wrote: > > > > > > > >? ? ?On 3/22/19 10:08 AM, Scott Marlow wrote: > >? ? ? > > >? ? ? > > >? ? ? > On 3/22/19 9:24 AM, Scott Marlow wrote: > >? ? ? >> > >? ? ? >> > >? ? ? >> On 3/22/19 9:11 AM, Scott Marlow wrote: > >? ? ? >>> > >? ? ? >>> > >? ? ? >>> On 3/22/19 7:49 AM, Guillaume Smet wrote: > >? ? ? >>>> Hi Gail, > >? ? ? >>>> > >? ? ? >>>> Do we have any idea of what this class is supposed to be: > >? ? ? >>>> > > > ?org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 > >? ? ? >>>> ? > >? ? ? >>> > >? ? ? >>> This is a unit test class that is not an entity class, but > >? ? ?instead it > >? ? ? >>> happens to be an EJB stateless session bean.? In the > exception > >? ? ?call > >? ? ? >>> stack [1], the class that ByteBuddy complains about is a > WildFly > >? ? ? >>> class (not even a test class), you can see that in the > exception > >? ? ? >>> message SerializationProxyHackImplementation [2]. > >? ? ? >>> > >? ? ? >>>> Scott, any idea? > >? ? ? >>> > >? ? ? >>> I was not really aware that classes like > >? ? ? >>> SerializationProxyHackImplementation [2] , would also be > >? ? ?handled by > >? ? ? >>> > > > ?org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() > > > >? ? ? >>> but I guess that makes sense, as application > classloaders versus > >? ? ? >>> application module classloaders, are not distinguished > >? ? ?internally in WF. > >? ? ? >> > >? ? ? >> I meant that class file transformers will be called for both > >? ? ? >> application classes and WF classes as well. > >? ? ? > > >? ? ? > I'm going to see if I can hack around this failure in WF > code, so > >? ? ?that > >? ? ? > WF doesn't call into Hibernate to transform the > >? ? ? > org.jboss.as.ejb3.SerializationProxyHackImplementation class. > > > >? ? ?I tried changing > > > ?org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() > > > >? ? ?to filter out any non-application classes but that didn't help as > >? ? ?DelegatingClassFileTransformer.transform() doesn't get called to > >? ? ?transform the SerializationProxyHackImplementation [2] class. > > > >? ? ?It might be that the application classes are getting injected > with a > >? ? ?classloader that references the > SerializationProxyHackImplementation > >? ? ?[2] > >? ? ?class. > > > >? ? ?IMO, this probably should be fixed in Hibernate ORM or ByteBuddy. > > > >? ? ? > > >? ? ? >> > >? ? ? >>> > >? ? ? >>> I'm also not sure of how Javassist handles ignoring the > >? ? ? >>> SerializationProxyHackImplementation [2] class but > Javassist does > >? ? ? >>> work fine (as long as you work around the other issue, > which is > >? ? ?that > >? ? ? >>> Javassist can only be selected via system property > setting but not > >? ? ? >>> persistence.xml setting, also mentioned in WFLY-11891 [3]). > >? ? ? >>> > >? ? ? >>>> > >? ? ? >>>> Because it doesn't ring a bell on my side. > >? ? ? >>>> > >? ? ? >>>> I suspect it's a class we shouldn't access or touch. And we > >? ? ?should > >? ? ? >>>> probably > >? ? ? >>>> add a condition somewhere to avoid doing so. > >? ? ? >>> > >? ? ? >>> Agreed. > >? ? ? >>> > >? ? ? >>>> > >? ? ? >>>> If you can give me the Hibernate call which initiates > the error, > >? ? ? >>>> that would > >? ? ? >>>> be nice. > >? ? ? >>> > >? ? ? >>> [1] shows the exception call stack (look for > >? ? ? >>> > > > ?"org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.lambda$enhance$0(EnhancerImpl.java:137)" > > > >? ? ? >>> > >? ? ? >>> > >? ? ? >>> > >? ? ? >>>> > >? ? ? >>>> And stupid question: we did not have any enhancement > test in > >? ? ?WildFly > >? ? ? >>>> before > >? ? ? >>>> that? > >? ? ? >>>> > >? ? ? >>> > >? ? ? >>> No, sadly, this is the first time we updated the WildFly > unit > >? ? ?tests > >? ? ? >>> to try Javassist + ByteBuddy enhancement.? Its a very light > >? ? ?test with > >? ? ? >>> little verification, basically we just modified some > existing > >? ? ?tests > >? ? ? >>> to include: > >? ? ? >>> > >? ? ? >>> hibernate.enhancer.enableDirtyTracking=true > >? ? ? >>> hibernate.enhancer.enableLazyInitialization=true > >? ? ? >>> hibernate.enhancer.enableAssociationManagement=true > >? ? ? >>> > >? ? ? >>> And one test was also modified to specify > >? ? ? >>> hibernate.bytecode.provider=javassist, which is ignored > (only the > >? ? ? >>> system property works, via standalone.sh > >? ? ? >>> -Dhibernate.bytecode.provider=javassist).? The problem > is also > >? ? ? >>> mentioned in WFLY-11891 [3]. > >? ? ? >>> > >? ? ? >>> In WF, we also have a mock persistence provider test > that ensures > >? ? ? >>> that persistence providers can enhance classes as per > the JPA > >? ? ? >>> container contract. > >? ? ? >>> > >? ? ? >>> Scott > >? ? ? >>> > >? ? ? >>> [1] > >? ? ? >>> > > > https://issues.jboss.org/browse/WFLY-11891?focusedCommentId=13711809&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13711809 > > > >? ? ? >>> > >? ? ? >>> > >? ? ? >>> [2] java.lang.IllegalStateException: Cannot resolve type > >? ? ?description > >? ? ? >>> for org.jboss.as.ejb3.SerializationProxyHackImplementation > >? ? ? >>> > >? ? ? >>> [3] https://issues.jboss.org/browse/WFLY-11891 > > > From smarlow at redhat.com Fri Mar 22 20:09:35 2019 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 22 Mar 2019 20:09:35 -0400 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: References: <780f30b5-d59c-ce5c-ffc0-848b81f1a3d5@redhat.com> <3d0e458d-f515-f7c6-0a36-cbaadccd3318@redhat.com> <65694da9-32e9-b0d4-6051-3059e4050456@redhat.com> <3c3bf2ab-34e9-1088-af16-61e95973cc84@redhat.com> <7525bb8c-9c8c-1c37-0e8a-67ba6f9e155b@redhat.com> Message-ID: > > > > > https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/iiop/handle/SerializationHackProxy.java#L57 We should try to recreate without WildFly, perhaps hacking the SerializationHackProxy code into a Hibernate unit test or ByteBuddy test, could be our next step, make sense? Scott > From smarlow at redhat.com Mon Mar 25 12:14:01 2019 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 25 Mar 2019 12:14:01 -0400 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: References: Message-ID: <610c6898-5fa7-8df3-c56e-440b23ad605d@redhat.com> Adding Tomek + Cheng, as they have been working on the WildFly EJB layer recently, which seems to use https://github.com/jbossas/jboss-classfilewriter for generating the EJB stub classes like org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class. Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or ByteBuddy should change to handle dynamically generated classes differently. In other words, should ByteBuddy respond differently to classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") returning null or should the jboss-classfilewriter project somehow avoid this bug. Scott On 3/22/19 2:54 AM, Gail Badner wrote: > Scott added bytecode enhancement to some WildFly tests for WFLY-11891 [1], > which are failing. > > Here is Scott's PR with the updated tests: [2] > > When I stepped into > org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase, > I can see that they are failing in ByteBuddy code. > > I see that: > > - enhancement of > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets > skipped several times in a row; > - enhancement of some other classes get skipped; > - before trying to enhance > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, an > exception is thrown. > > Unfortunately, I'm having trouble getting a good stacktrace to show what > happens in ByteBuddy code. > > Here is what I'm seeing: > > net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") > /* class name differs from run to run */ > > > calls net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( " > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") > > calls net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate( > classLoader, "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5" > ) > > calls > classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"), > which returns null; > > (I don't actually see a class file with this name) > > > returns new TypePool.Resolution.Illegal( > > "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class" > > ) > > returns TypePool.Resolution.Illegal > > > Ultimately, TypePool.Resolution.Illegal#resolve( ) throws > IllegalStateException, because the type description cannot be resolved. > > I'm not sure if the problem is in WildFly, Hibernate, or ByteBuddy. > > To build WildFly: > ./build.sh clean install -DskipTests=true > > To run the test: > cd testsuite/integration/basic > mvn install > -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase > > Help would be very much appreciated. > > Thanks, > Gail > > [1] https://issues.jboss.org/browse/WFLY-11891 > [2] https://github.com/wildfly/wildfly/pull/12180 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Tue Mar 26 09:25:02 2019 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 26 Mar 2019 08:25:02 -0500 Subject: [hibernate-dev] 6.0 - multi-table mutations Message-ID: While working on 6 I discovered that we maybe do not do the best job in regards to "bulk update/delete" queries against multi-table entities (secondary tables, joined inheritance, etc). This short-coming exists in previous versions. Essentially, when a strategy is not explicitly specified we fallback to using an "id table" and performing the SQL updates or deletes using the id table as a sub-query. The problem is that for some databases this breaks when the ids are composite due to the database not having complete support for tuples. For example, H2 does not allow the sub-query for an in-predicate to return more than one column: so a query like `... where (id1, id2) in (select val1, val2 from ...)` will not work. This tuple concern is something I had not considered when I first wrote this feature. Obviously with 6 we have a chance to improve this. So I have been thinking about some ways this might be improved. The guiding principle here was to make this as implicit as possible... Because certain strategies will not work when the ids are composite, I think the first consideration is whether we want to allow the strategy to be definable per-entity. The idea would be to allow for the most efficient strategy to be used generally (whatever that might be for the given app/database) but to pick an alternative strategy in cases where that "fallback" one will not work. The Dialect should certainly play a part in this strategy selection. And lastly, we should consider whether it is beneficial to leverage these strategies when performing normal mutations (merge, persist, etc). I think really this comes down to whether we think there is a benefit to handling these via CTE if the database supports that as opposed to sending individual updates or deletes against each table. Thoughts? From smarlow at redhat.com Tue Mar 26 09:53:07 2019 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 26 Mar 2019 09:53:07 -0400 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: References: <610c6898-5fa7-8df3-c56e-440b23ad605d@redhat.com> Message-ID: <5ea21748-f59a-1d7e-b4d9-6690a9bc4fe6@redhat.com> Hi Tomek, I think the pending question now is why ByteBuddy is getting a null result from the classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") call. We have also seen failures for org.jboss.as.ejb3.SerializationProxyHackImplementation as well, which is also generated by the EJB container (see exception call stack in https://issues.jboss.org/browse/WFLY-11891). I wonder if this could be an ordering bug where classes generated via JBoss ClassFileWriter are added to the classloader list of classes, before the actual bytecode is added. Scott On 3/26/19 9:17 AM, Tomasz Adamski wrote: > Hi Scott, > > Added to my TODO. WIll try to look at it this week. > > Regards, > Tomek > > On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow > wrote: > > Adding Tomek + Cheng, as they have been working on the WildFly EJB > layer > recently, which seems to use > https://github.com/jbossas/jboss-classfilewriter for generating the EJB > stub classes like > org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class. > > Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or > ByteBuddy should change to handle dynamically generated classes > differently. > > In other words, should ByteBuddy respond differently to > classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") > > returning null or should the jboss-classfilewriter project somehow > avoid > this bug. > > Scott > > On 3/22/19 2:54 AM, Gail Badner wrote: > > Scott added bytecode enhancement to some WildFly tests for > WFLY-11891 [1], > > which are failing. > > > > Here is Scott's PR with the updated tests: [2] > > > > When I stepped into > > > org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase, > > I can see that they are failing in ByteBuddy code. > > > > I see that: > > > >? ? ?-? enhancement of > > > ?org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets > >? ? ?skipped several times in a row; > >? ? ?- enhancement of some other classes get skipped; > >? ? ?- before trying to enhance > > > ?org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, an > >? ? ?exception is thrown. > > > > Unfortunately, I'm having trouble getting a good stacktrace to > show what > > happens in ByteBuddy code. > > > > Here is what I'm seeing: > > > > > net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") > > /* class name differs from run to run */ > > > > > > calls net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( " > > > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") > > > > calls net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate( > > classLoader, > "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5" > > ) > > > > calls > > > classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"), > > which returns null; > > > > (I don't actually see a class file with this name) > > > > > > returns new TypePool.Resolution.Illegal( > > > > > "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class" > > > > ) > > > > returns TypePool.Resolution.Illegal > > > > > > Ultimately, TypePool.Resolution.Illegal#resolve( ) throws > > IllegalStateException, because the type description cannot be > resolved. > > > > I'm not sure if the problem is in WildFly, Hibernate, or ByteBuddy. > > > > To build WildFly: > > ./build.sh clean install -DskipTests=true > > > > To run the test: > > cd testsuite/integration/basic > > mvn install > > > -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase > > > > Help would be very much appreciated. > > > > Thanks, > > Gail > > > > [1] https://issues.jboss.org/browse/WFLY-11891 > > [2] https://github.com/wildfly/wildfly/pull/12180 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > -- > Regards, > Tomek From steve at hibernate.org Tue Mar 26 10:00:05 2019 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 26 Mar 2019 09:00:05 -0500 Subject: [hibernate-dev] 6.0 - multi-table mutations In-Reply-To: References: Message-ID: https://hibernate.zulipchat.com/#narrow/stream/132094-hibernate-orm-dev/topic/6.2E0.20-.20multi-table.20mutation On Tue, Mar 26, 2019 at 8:25 AM Steve Ebersole wrote: > While working on 6 I discovered that we maybe do not do the best job in > regards to "bulk update/delete" queries against multi-table entities > (secondary tables, joined inheritance, etc). This short-coming exists in > previous versions. Essentially, when a strategy is not explicitly > specified we fallback to using an "id table" and performing the SQL updates > or deletes using the id table as a sub-query. The problem is that for some > databases this breaks when the ids are composite due to the database not > having complete support for tuples. For example, H2 does not allow the > sub-query for an in-predicate to return more than one column: so a query > like `... where (id1, id2) in (select val1, val2 from ...)` will not work. > This tuple concern is something I had not considered when I first wrote > this feature. > > Obviously with 6 we have a chance to improve this. So I have been > thinking about some ways this might be improved. The guiding principle > here was to make this as implicit as possible... > > Because certain strategies will not work when the ids are composite, I > think the first consideration is whether we want to allow the strategy to > be definable per-entity. The idea would be to allow for the most efficient > strategy to be used generally (whatever that might be for the given > app/database) but to pick an alternative strategy in cases where that > "fallback" one will not work. The Dialect should certainly play a part in > this strategy selection. > > And lastly, we should consider whether it is beneficial to leverage these > strategies when performing normal mutations (merge, persist, etc). I think > really this comes down to whether we think there is a benefit to handling > these via CTE if the database supports that as opposed to sending > individual updates or deletes against each table. > > Thoughts? > From guillaume.smet at gmail.com Tue Mar 26 10:37:29 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 26 Mar 2019 15:37:29 +0100 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of our NoORM IRC meeting: 15:36 < jbott> Meeting ended Tue Mar 26 14:36:05 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:36 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-03-26-14.01.html 15:36 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-03-26-14.01.txt 15:36 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-03-26-14.01.log.html Have a nice day. -- Guillaume From sanne at hibernate.org Tue Mar 26 10:57:18 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 26 Mar 2019 14:57:18 +0000 Subject: [hibernate-dev] 6.0 - multi-table mutations In-Reply-To: References: Message-ID: Hi Steve, this does sound amazing, I think it's certainly worth trying to have the most efficient strategy chosen on a per-entity base. One question: could we benefit from "cascade delete" rules defined in the table structure? If Hibernate ORM was able parse the cascading rules from existing schemas, and possibly generate them for new schemas, you could have an entire crop of additional such optimisations. I'm not sure if I'm talking about material for ORM 7+ but if you could make sure that such future optimisations aren't ruled out that would be awesome :) Thanks, Sanne On Tue, 26 Mar 2019 at 13:25, Steve Ebersole wrote: > > While working on 6 I discovered that we maybe do not do the best job in > regards to "bulk update/delete" queries against multi-table entities > (secondary tables, joined inheritance, etc). This short-coming exists in > previous versions. Essentially, when a strategy is not explicitly > specified we fallback to using an "id table" and performing the SQL updates > or deletes using the id table as a sub-query. The problem is that for some > databases this breaks when the ids are composite due to the database not > having complete support for tuples. For example, H2 does not allow the > sub-query for an in-predicate to return more than one column: so a query > like `... where (id1, id2) in (select val1, val2 from ...)` will not work. > This tuple concern is something I had not considered when I first wrote > this feature. > > Obviously with 6 we have a chance to improve this. So I have been thinking > about some ways this might be improved. The guiding principle here was to > make this as implicit as possible... > > Because certain strategies will not work when the ids are composite, I > think the first consideration is whether we want to allow the strategy to > be definable per-entity. The idea would be to allow for the most efficient > strategy to be used generally (whatever that might be for the given > app/database) but to pick an alternative strategy in cases where that > "fallback" one will not work. The Dialect should certainly play a part in > this strategy selection. > > And lastly, we should consider whether it is beneficial to leverage these > strategies when performing normal mutations (merge, persist, etc). I think > really this comes down to whether we think there is a benefit to handling > these via CTE if the database supports that as opposed to sending > individual updates or deletes against each table. > > Thoughts? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Tue Mar 26 11:07:50 2019 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 26 Mar 2019 10:07:50 -0500 Subject: [hibernate-dev] 6.0 - multi-table mutations In-Reply-To: References: Message-ID: On Tue, Mar 26, 2019 at 9:57 AM Sanne Grinovero wrote: > One question: could we benefit from "cascade delete" rules defined in > the table structure? > If Hibernate ORM was able parse the cascading rules from existing > schemas, and possibly generate them for new schemas, you could have an > entire crop of additional such optimisations. I'm not sure if I'm > talking about material for ORM 7+ but if you could make sure that such > future optimisations aren't ruled out that would be awesome :) > Good point. We actually do already have some limited support for cascading FKs in ORM - `org.hibernate.annotations.OnDelete`. And it is exported to the database if defined. We do not (nor should we) parse this information from the existing schema. What you are asking about specifically would require us to round out that support (secondary tables at least are not yet supported) and of course to leverage that in the HQL bulk deletion handlers. Not impossible or even particularly difficult - but enough work that I'd rather that be handled somewhere post-6.0 From sanne at hibernate.org Tue Mar 26 11:17:29 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 26 Mar 2019 15:17:29 +0000 Subject: [hibernate-dev] 6.0 - multi-table mutations In-Reply-To: References: Message-ID: On Tue, 26 Mar 2019 at 15:08, Steve Ebersole wrote: > > On Tue, Mar 26, 2019 at 9:57 AM Sanne Grinovero wrote: >> >> One question: could we benefit from "cascade delete" rules defined in >> the table structure? >> >> >> If Hibernate ORM was able parse the cascading rules from existing >> schemas, and possibly generate them for new schemas, you could have an >> entire crop of additional such optimisations. I'm not sure if I'm >> talking about material for ORM 7+ but if you could make sure that such >> future optimisations aren't ruled out that would be awesome :) > > > Good point. > > We actually do already have some limited support for cascading FKs in ORM - `org.hibernate.annotations.OnDelete`. And it is exported to the database if defined. We do not (nor should we) parse this information from the existing schema. Why should we not? > > What you are asking about specifically would require us to round out that support (secondary tables at least are not yet supported) and of course to leverage that in the HQL bulk deletion handlers. Not impossible or even particularly difficult - but enough work that I'd rather that be handled somewhere post-6.0 +1 fair enough From steve at hibernate.org Tue Mar 26 11:35:16 2019 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 26 Mar 2019 10:35:16 -0500 Subject: [hibernate-dev] 6.0 - multi-table mutations In-Reply-To: References: Message-ID: On Tue, Mar 26, 2019 at 10:17 AM Sanne Grinovero wrote: > > Why should we not? > There is a very compelling reason for that. I'll have to leave it at that. From smarlow at redhat.com Tue Mar 26 12:08:14 2019 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 26 Mar 2019 12:08:14 -0400 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: <5ea21748-f59a-1d7e-b4d9-6690a9bc4fe6@redhat.com> References: <610c6898-5fa7-8df3-c56e-440b23ad605d@redhat.com> <5ea21748-f59a-1d7e-b4d9-6690a9bc4fe6@redhat.com> Message-ID: <8eb079e4-c9c8-4ab1-c875-115a873bdf44@redhat.com> Thinking more about this, I don't think that ByteBuddy should be able to do a classloader.getResource() on the class that is being defined (SLSBPersistenceContexts$$$view5.class). It might be correct for the getResource call to return null, until after the class is completely defined. Would it make sense for the above condition (cl.getResource() returning null) be detected differently in the callstack [1] and just fall through + return to the caller? Scott [1] https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd On 3/26/19 9:53 AM, Scott Marlow wrote: > Hi Tomek, > > I think the pending question now is why ByteBuddy is getting a null > result from the > classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") > call. > > We have also seen failures for > org.jboss.as.ejb3.SerializationProxyHackImplementation as well, which is > also generated by the EJB container (see exception call stack in > https://issues.jboss.org/browse/WFLY-11891). > > I wonder if this could be an ordering bug where classes generated via > JBoss ClassFileWriter are added to the classloader list of classes, > before the actual bytecode is added. > > Scott > > On 3/26/19 9:17 AM, Tomasz Adamski wrote: >> Hi Scott, >> >> Added to my TODO. WIll try to look at it this week. >> >> Regards, >> Tomek >> >> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow > > wrote: >> >> ??? Adding Tomek + Cheng, as they have been working on the WildFly EJB >> ??? layer >> ??? recently, which seems to use >> ??? https://github.com/jbossas/jboss-classfilewriter for generating >> the EJB >> ??? stub classes like >> >> org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class. >> >> >> ??? Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or >> ??? ByteBuddy should change to handle dynamically generated classes >> ??? differently. >> >> ??? In other words, should ByteBuddy respond differently to >> >> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") >> >> >> ??? returning null or should the jboss-classfilewriter project somehow >> ??? avoid >> ??? this bug. >> >> ??? Scott >> >> ??? On 3/22/19 2:54 AM, Gail Badner wrote: >> ???? > Scott added bytecode enhancement to some WildFly tests for >> ??? WFLY-11891 [1], >> ???? > which are failing. >> ???? > >> ???? > Here is Scott's PR with the updated tests: [2] >> ???? > >> ???? > When I stepped into >> ???? > >> >> org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase, >> >> ???? > I can see that they are failing in ByteBuddy code. >> ???? > >> ???? > I see that: >> ???? > >> ???? >? ? ?-? enhancement of >> ???? > >> ?org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets >> ???? >? ? ?skipped several times in a row; >> ???? >? ? ?- enhancement of some other classes get skipped; >> ???? >? ? ?- before trying to enhance >> ???? > >> ?org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, >> an >> ???? >? ? ?exception is thrown. >> ???? > >> ???? > Unfortunately, I'm having trouble getting a good stacktrace to >> ??? show what >> ???? > happens in ByteBuddy code. >> ???? > >> ???? > Here is what I'm seeing: >> ???? > >> ???? > >> >> net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") >> >> ???? > /* class name differs from run to run */ >> ???? > >> ???? > >> ???? > calls >> net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( " >> ???? > >> >> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") >> ???? > >> ???? > calls >> net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate( >> ???? > classLoader, >> >> "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5" >> ???? > ) >> ???? > >> ???? > calls >> ???? > >> >> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"), >> >> ???? > which returns null; >> ???? > >> ???? > (I don't actually see a class file with this name) >> ???? > >> ???? > >> ???? > returns new TypePool.Resolution.Illegal( >> ???? > >> ???? > >> >> "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class" >> >> ???? > >> ???? > ) >> ???? > >> ???? > returns TypePool.Resolution.Illegal >> ???? > >> ???? > >> ???? > Ultimately, TypePool.Resolution.Illegal#resolve( ) throws >> ???? > IllegalStateException, because the type description cannot be >> ??? resolved. >> ???? > >> ???? > I'm not sure if the problem is in WildFly, Hibernate, or >> ByteBuddy. >> ???? > >> ???? > To build WildFly: >> ???? > ./build.sh clean install -DskipTests=true >> ???? > >> ???? > To run the test: >> ???? > cd testsuite/integration/basic >> ???? > mvn install >> ???? > >> >> -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase >> >> ???? > >> ???? > Help would be very much appreciated. >> ???? > >> ???? > Thanks, >> ???? > Gail >> ???? > >> ???? > [1] https://issues.jboss.org/browse/WFLY-11891 >> ???? > [2] https://github.com/wildfly/wildfly/pull/12180 >> ???? > _______________________________________________ >> ???? > hibernate-dev mailing list >> ???? > hibernate-dev at lists.jboss.org >> >> ???? > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> ???? > >> >> >> >> -- >> Regards, >> Tomek From guillaume.smet at gmail.com Tue Mar 26 12:50:23 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 26 Mar 2019 17:50:23 +0100 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: <8eb079e4-c9c8-4ab1-c875-115a873bdf44@redhat.com> References: <610c6898-5fa7-8df3-c56e-440b23ad605d@redhat.com> <5ea21748-f59a-1d7e-b4d9-6690a9bc4fe6@redhat.com> <8eb079e4-c9c8-4ab1-c875-115a873bdf44@redhat.com> Message-ID: I would try changing the start of EnhancerImpl#enhance() to: ======= public byte[] enhance(String className, byte[] originalBytes) throws EnhancementException { //Classpool#describe does not accept '/' in the description name as it expects a class name. See HHH-12545 final String safeClassName = className.replace( '/', '.' ); try { final Resolution typeResolution = typePool.describe( safeClassName ); if ( !typeResolution.isResolved() ) { return null; } final TypeDescription typeDescription = typeResolution.resolve(); ======= i.e. testing the resolution of the type. That might fix it. -- Guillaume On Tue, Mar 26, 2019 at 5:39 PM Scott Marlow wrote: > Thinking more about this, I don't think that ByteBuddy should be able to > do a classloader.getResource() on the class that is being defined > (SLSBPersistenceContexts$$$view5.class). It might be correct for the > getResource call to return null, until after the class is completely > defined. > > Would it make sense for the above condition (cl.getResource() returning > null) be detected differently in the callstack [1] and just fall through > + return to the caller? > > Scott > > [1] https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd > > On 3/26/19 9:53 AM, Scott Marlow wrote: > > Hi Tomek, > > > > I think the pending question now is why ByteBuddy is getting a null > > result from the > > > classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") > > > call. > > > > We have also seen failures for > > org.jboss.as.ejb3.SerializationProxyHackImplementation as well, which is > > also generated by the EJB container (see exception call stack in > > https://issues.jboss.org/browse/WFLY-11891). > > > > I wonder if this could be an ordering bug where classes generated via > > JBoss ClassFileWriter are added to the classloader list of classes, > > before the actual bytecode is added. > > > > Scott > > > > On 3/26/19 9:17 AM, Tomasz Adamski wrote: > >> Hi Scott, > >> > >> Added to my TODO. WIll try to look at it this week. > >> > >> Regards, > >> Tomek > >> > >> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow >> > wrote: > >> > >> Adding Tomek + Cheng, as they have been working on the WildFly EJB > >> layer > >> recently, which seems to use > >> https://github.com/jbossas/jboss-classfilewriter for generating > >> the EJB > >> stub classes like > >> > >> > org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class. > > >> > >> > >> Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or > >> ByteBuddy should change to handle dynamically generated classes > >> differently. > >> > >> In other words, should ByteBuddy respond differently to > >> > >> > classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") > > >> > >> > >> returning null or should the jboss-classfilewriter project somehow > >> avoid > >> this bug. > >> > >> Scott > >> > >> On 3/22/19 2:54 AM, Gail Badner wrote: > >> > Scott added bytecode enhancement to some WildFly tests for > >> WFLY-11891 [1], > >> > which are failing. > >> > > >> > Here is Scott's PR with the updated tests: [2] > >> > > >> > When I stepped into > >> > > >> > >> > org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase, > > >> > >> > I can see that they are failing in ByteBuddy code. > >> > > >> > I see that: > >> > > >> > - enhancement of > >> > > >> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets > >> > skipped several times in a row; > >> > - enhancement of some other classes get skipped; > >> > - before trying to enhance > >> > > >> > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, > >> an > >> > exception is thrown. > >> > > >> > Unfortunately, I'm having trouble getting a good stacktrace to > >> show what > >> > happens in ByteBuddy code. > >> > > >> > Here is what I'm seeing: > >> > > >> > > >> > >> > net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") > > >> > >> > /* class name differs from run to run */ > >> > > >> > > >> > calls > >> net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( " > >> > > >> > >> > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") > >> > > >> > calls > >> net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate( > >> > classLoader, > >> > >> > "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5" > >> > ) > >> > > >> > calls > >> > > >> > >> > classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"), > > >> > >> > which returns null; > >> > > >> > (I don't actually see a class file with this name) > >> > > >> > > >> > returns new TypePool.Resolution.Illegal( > >> > > >> > > >> > >> > "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class" > > >> > >> > > >> > ) > >> > > >> > returns TypePool.Resolution.Illegal > >> > > >> > > >> > Ultimately, TypePool.Resolution.Illegal#resolve( ) throws > >> > IllegalStateException, because the type description cannot be > >> resolved. > >> > > >> > I'm not sure if the problem is in WildFly, Hibernate, or > >> ByteBuddy. > >> > > >> > To build WildFly: > >> > ./build.sh clean install -DskipTests=true > >> > > >> > To run the test: > >> > cd testsuite/integration/basic > >> > mvn install > >> > > >> > >> > -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase > > >> > >> > > >> > Help would be very much appreciated. > >> > > >> > Thanks, > >> > Gail > >> > > >> > [1] https://issues.jboss.org/browse/WFLY-11891 > >> > [2] https://github.com/wildfly/wildfly/pull/12180 > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev at lists.jboss.org > >> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > >> > >> > >> > >> -- > >> Regards, > >> Tomek > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gbadner at redhat.com Tue Mar 26 13:11:07 2019 From: gbadner at redhat.com (Gail Badner) Date: Tue, 26 Mar 2019 10:11:07 -0700 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: References: <610c6898-5fa7-8df3-c56e-440b23ad605d@redhat.com> <5ea21748-f59a-1d7e-b4d9-6690a9bc4fe6@redhat.com> <8eb079e4-c9c8-4ab1-c875-115a873bdf44@redhat.com> Message-ID: Guillaume, thanks for the suggestion. I'll give it a try... On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet wrote: > I would try changing the start of EnhancerImpl#enhance() to: > ======= > public byte[] enhance(String className, byte[] originalBytes) throws > EnhancementException { > //Classpool#describe does not accept '/' in the description name as > it expects a class name. See HHH-12545 > final String safeClassName = className.replace( '/', '.' ); > try { > final Resolution typeResolution = typePool.describe( > safeClassName ); > if ( !typeResolution.isResolved() ) { > return null; > } > > final TypeDescription typeDescription = > typeResolution.resolve(); > ======= > > i.e. testing the resolution of the type. > > That might fix it. > > -- > Guillaume > > On Tue, Mar 26, 2019 at 5:39 PM Scott Marlow wrote: > > > Thinking more about this, I don't think that ByteBuddy should be able to > > do a classloader.getResource() on the class that is being defined > > (SLSBPersistenceContexts$$$view5.class). It might be correct for the > > getResource call to return null, until after the class is completely > > defined. > > > > Would it make sense for the above condition (cl.getResource() returning > > null) be detected differently in the callstack [1] and just fall through > > + return to the caller? > > > > Scott > > > > [1] https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd > > > > On 3/26/19 9:53 AM, Scott Marlow wrote: > > > Hi Tomek, > > > > > > I think the pending question now is why ByteBuddy is getting a null > > > result from the > > > > > > classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") > > > > > call. > > > > > > We have also seen failures for > > > org.jboss.as.ejb3.SerializationProxyHackImplementation as well, which > is > > > also generated by the EJB container (see exception call stack in > > > https://issues.jboss.org/browse/WFLY-11891). > > > > > > I wonder if this could be an ordering bug where classes generated via > > > JBoss ClassFileWriter are added to the classloader list of classes, > > > before the actual bytecode is added. > > > > > > Scott > > > > > > On 3/26/19 9:17 AM, Tomasz Adamski wrote: > > >> Hi Scott, > > >> > > >> Added to my TODO. WIll try to look at it this week. > > >> > > >> Regards, > > >> Tomek > > >> > > >> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow > >> > wrote: > > >> > > >> Adding Tomek + Cheng, as they have been working on the WildFly EJB > > >> layer > > >> recently, which seems to use > > >> https://github.com/jbossas/jboss-classfilewriter for generating > > >> the EJB > > >> stub classes like > > >> > > >> > > > org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class. > > > > >> > > >> > > >> Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or > > >> ByteBuddy should change to handle dynamically generated classes > > >> differently. > > >> > > >> In other words, should ByteBuddy respond differently to > > >> > > >> > > > classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") > > > > >> > > >> > > >> returning null or should the jboss-classfilewriter project somehow > > >> avoid > > >> this bug. > > >> > > >> Scott > > >> > > >> On 3/22/19 2:54 AM, Gail Badner wrote: > > >> > Scott added bytecode enhancement to some WildFly tests for > > >> WFLY-11891 [1], > > >> > which are failing. > > >> > > > >> > Here is Scott's PR with the updated tests: [2] > > >> > > > >> > When I stepped into > > >> > > > >> > > >> > > > org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase, > > > > >> > > >> > I can see that they are failing in ByteBuddy code. > > >> > > > >> > I see that: > > >> > > > >> > - enhancement of > > >> > > > >> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets > > >> > skipped several times in a row; > > >> > - enhancement of some other classes get skipped; > > >> > - before trying to enhance > > >> > > > >> > > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, > > >> an > > >> > exception is thrown. > > >> > > > >> > Unfortunately, I'm having trouble getting a good stacktrace to > > >> show what > > >> > happens in ByteBuddy code. > > >> > > > >> > Here is what I'm seeing: > > >> > > > >> > > > >> > > >> > > > net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") > > > > >> > > >> > /* class name differs from run to run */ > > >> > > > >> > > > >> > calls > > >> net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( " > > >> > > > >> > > >> > > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") > > >> > > > >> > calls > > >> net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate( > > >> > classLoader, > > >> > > >> > > "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5" > > >> > ) > > >> > > > >> > calls > > >> > > > >> > > >> > > > classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"), > > > > >> > > >> > which returns null; > > >> > > > >> > (I don't actually see a class file with this name) > > >> > > > >> > > > >> > returns new TypePool.Resolution.Illegal( > > >> > > > >> > > > >> > > >> > > > "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class" > > > > >> > > >> > > > >> > ) > > >> > > > >> > returns TypePool.Resolution.Illegal > > >> > > > >> > > > >> > Ultimately, TypePool.Resolution.Illegal#resolve( ) throws > > >> > IllegalStateException, because the type description cannot be > > >> resolved. > > >> > > > >> > I'm not sure if the problem is in WildFly, Hibernate, or > > >> ByteBuddy. > > >> > > > >> > To build WildFly: > > >> > ./build.sh clean install -DskipTests=true > > >> > > > >> > To run the test: > > >> > cd testsuite/integration/basic > > >> > mvn install > > >> > > > >> > > >> > > > -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase > > > > >> > > >> > > > >> > Help would be very much appreciated. > > >> > > > >> > Thanks, > > >> > Gail > > >> > > > >> > [1] https://issues.jboss.org/browse/WFLY-11891 > > >> > [2] https://github.com/wildfly/wildfly/pull/12180 > > >> > _______________________________________________ > > >> > hibernate-dev mailing list > > >> > hibernate-dev at lists.jboss.org > > >> > > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> > > > >> > > >> > > >> > > >> -- > > >> Regards, > > >> Tomek > > _______________________________________________ > > 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 Thu Mar 28 02:13:11 2019 From: gbadner at redhat.com (Gail Badner) Date: Wed, 27 Mar 2019 23:13:11 -0700 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: References: <610c6898-5fa7-8df3-c56e-440b23ad605d@redhat.com> <5ea21748-f59a-1d7e-b4d9-6690a9bc4fe6@redhat.com> <8eb079e4-c9c8-4ab1-c875-115a873bdf44@redhat.com> Message-ID: Hi Guillaume, Unfortunately, it is not so easy. typeDescription is of type TypePool$Default$WithLazyResolution$LazyTypeDescription, and it doesn't get completely resolved until later. I've pushed a branch [1] that seems to work for MultiplePuTestCase. Here is the commit [2]. I haven't had a chance to try the other tests in Scott's PR. I'll give them a try tomorrow. I did not create a Hibernate issue for this yet because I'm not sure if Hibernate should be working around this issue. It's getting late for me tonight. I'll continue tomorrow. Comments are welcome. Regards, Gail [1] https://github.com/gbadner/hibernate-core/tree/WFLY-11891-5.3 [2] https://github.com/gbadner/hibernate-core/commit/ef1687807def94a4465d6cf2372f9235dc559bd1 On Tue, Mar 26, 2019 at 10:11 AM Gail Badner wrote: > Guillaume, thanks for the suggestion. I'll give it a try... > > On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet > wrote: > >> I would try changing the start of EnhancerImpl#enhance() to: >> ======= >> public byte[] enhance(String className, byte[] originalBytes) throws >> EnhancementException { >> //Classpool#describe does not accept '/' in the description name >> as >> it expects a class name. See HHH-12545 >> final String safeClassName = className.replace( '/', '.' ); >> try { >> final Resolution typeResolution = typePool.describe( >> safeClassName ); >> if ( !typeResolution.isResolved() ) { >> return null; >> } >> >> final TypeDescription typeDescription = >> typeResolution.resolve(); >> ======= >> >> i.e. testing the resolution of the type. >> >> That might fix it. >> >> -- >> Guillaume >> >> On Tue, Mar 26, 2019 at 5:39 PM Scott Marlow wrote: >> >> > Thinking more about this, I don't think that ByteBuddy should be able to >> > do a classloader.getResource() on the class that is being defined >> > (SLSBPersistenceContexts$$$view5.class). It might be correct for the >> > getResource call to return null, until after the class is completely >> > defined. >> > >> > Would it make sense for the above condition (cl.getResource() returning >> > null) be detected differently in the callstack [1] and just fall through >> > + return to the caller? >> > >> > Scott >> > >> > [1] >> https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd >> > >> > On 3/26/19 9:53 AM, Scott Marlow wrote: >> > > Hi Tomek, >> > > >> > > I think the pending question now is why ByteBuddy is getting a null >> > > result from the >> > > >> > >> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") >> > >> > > call. >> > > >> > > We have also seen failures for >> > > org.jboss.as.ejb3.SerializationProxyHackImplementation as well, which >> is >> > > also generated by the EJB container (see exception call stack in >> > > https://issues.jboss.org/browse/WFLY-11891). >> > > >> > > I wonder if this could be an ordering bug where classes generated via >> > > JBoss ClassFileWriter are added to the classloader list of classes, >> > > before the actual bytecode is added. >> > > >> > > Scott >> > > >> > > On 3/26/19 9:17 AM, Tomasz Adamski wrote: >> > >> Hi Scott, >> > >> >> > >> Added to my TODO. WIll try to look at it this week. >> > >> >> > >> Regards, >> > >> Tomek >> > >> >> > >> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow > > >> > wrote: >> > >> >> > >> Adding Tomek + Cheng, as they have been working on the WildFly >> EJB >> > >> layer >> > >> recently, which seems to use >> > >> https://github.com/jbossas/jboss-classfilewriter for generating >> > >> the EJB >> > >> stub classes like >> > >> >> > >> >> > >> org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class. >> > >> > >> >> > >> >> > >> Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or >> > >> ByteBuddy should change to handle dynamically generated classes >> > >> differently. >> > >> >> > >> In other words, should ByteBuddy respond differently to >> > >> >> > >> >> > >> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") >> > >> > >> >> > >> >> > >> returning null or should the jboss-classfilewriter project >> somehow >> > >> avoid >> > >> this bug. >> > >> >> > >> Scott >> > >> >> > >> On 3/22/19 2:54 AM, Gail Badner wrote: >> > >> > Scott added bytecode enhancement to some WildFly tests for >> > >> WFLY-11891 [1], >> > >> > which are failing. >> > >> > >> > >> > Here is Scott's PR with the updated tests: [2] >> > >> > >> > >> > When I stepped into >> > >> > >> > >> >> > >> >> > >> org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase, >> > >> > >> >> > >> > I can see that they are failing in ByteBuddy code. >> > >> > >> > >> > I see that: >> > >> > >> > >> > - enhancement of >> > >> > >> > >> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets >> > >> > skipped several times in a row; >> > >> > - enhancement of some other classes get skipped; >> > >> > - before trying to enhance >> > >> > >> > >> >> > >> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, >> > >> an >> > >> > exception is thrown. >> > >> > >> > >> > Unfortunately, I'm having trouble getting a good stacktrace to >> > >> show what >> > >> > happens in ByteBuddy code. >> > >> > >> > >> > Here is what I'm seeing: >> > >> > >> > >> > >> > >> >> > >> >> > >> net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") >> > >> > >> >> > >> > /* class name differs from run to run */ >> > >> > >> > >> > >> > >> > calls >> > >> net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( " >> > >> > >> > >> >> > >> >> > >> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") >> > >> > >> > >> > calls >> > >> net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate( >> > >> > classLoader, >> > >> >> > >> >> > >> "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5" >> > >> > ) >> > >> > >> > >> > calls >> > >> > >> > >> >> > >> >> > >> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"), >> > >> > >> >> > >> > which returns null; >> > >> > >> > >> > (I don't actually see a class file with this name) >> > >> > >> > >> > >> > >> > returns new TypePool.Resolution.Illegal( >> > >> > >> > >> > >> > >> >> > >> >> > >> "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class" >> > >> > >> >> > >> > >> > >> > ) >> > >> > >> > >> > returns TypePool.Resolution.Illegal >> > >> > >> > >> > >> > >> > Ultimately, TypePool.Resolution.Illegal#resolve( ) throws >> > >> > IllegalStateException, because the type description cannot be >> > >> resolved. >> > >> > >> > >> > I'm not sure if the problem is in WildFly, Hibernate, or >> > >> ByteBuddy. >> > >> > >> > >> > To build WildFly: >> > >> > ./build.sh clean install -DskipTests=true >> > >> > >> > >> > To run the test: >> > >> > cd testsuite/integration/basic >> > >> > mvn install >> > >> > >> > >> >> > >> >> > >> -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase >> > >> > >> >> > >> > >> > >> > Help would be very much appreciated. >> > >> > >> > >> > Thanks, >> > >> > Gail >> > >> > >> > >> > [1] https://issues.jboss.org/browse/WFLY-11891 >> > >> > [2] https://github.com/wildfly/wildfly/pull/12180 >> > >> > _______________________________________________ >> > >> > hibernate-dev mailing list >> > >> > hibernate-dev at lists.jboss.org >> > >> >> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > >> > >> >> > >> >> > >> >> > >> -- >> > >> Regards, >> > >> Tomek >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From guillaume.smet at gmail.com Thu Mar 28 13:58:13 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 28 Mar 2019 18:58:13 +0100 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: References: <610c6898-5fa7-8df3-c56e-440b23ad605d@redhat.com> <5ea21748-f59a-1d7e-b4d9-6690a9bc4fe6@redhat.com> <8eb079e4-c9c8-4ab1-c875-115a873bdf44@redhat.com> Message-ID: Hi Gail, Thanks for looking into this. Your commit is interesting as we had people in Quarkus complaining about the fact that it was not possible to chain the ORM enhancer after other enhancers as it didn't consider the provided bytes as the "source" to consider. I wonder if what you did (i.e. considering the provided bytes) should be the default behavior. On Thu, Mar 28, 2019 at 7:13 AM Gail Badner wrote: > Hi Guillaume, > > Unfortunately, it is not so easy. > > typeDescription is of type > TypePool$Default$WithLazyResolution$LazyTypeDescription, and it doesn't get > completely resolved until later. > > I've pushed a branch [1] that seems to work for MultiplePuTestCase. Here > is the commit [2]. > > I haven't had a chance to try the other tests in Scott's PR. I'll give > them a try tomorrow. > > I did not create a Hibernate issue for this yet because I'm not sure if > Hibernate should be working around this issue. > > It's getting late for me tonight. I'll continue tomorrow. > > Comments are welcome. > > Regards, > Gail > > [1] https://github.com/gbadner/hibernate-core/tree/WFLY-11891-5.3 > [2] > https://github.com/gbadner/hibernate-core/commit/ef1687807def94a4465d6cf2372f9235dc559bd1 > > On Tue, Mar 26, 2019 at 10:11 AM Gail Badner wrote: > >> Guillaume, thanks for the suggestion. I'll give it a try... >> >> On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet >> wrote: >> >>> I would try changing the start of EnhancerImpl#enhance() to: >>> ======= >>> public byte[] enhance(String className, byte[] originalBytes) throws >>> EnhancementException { >>> //Classpool#describe does not accept '/' in the description name >>> as >>> it expects a class name. See HHH-12545 >>> final String safeClassName = className.replace( '/', '.' ); >>> try { >>> final Resolution typeResolution = typePool.describe( >>> safeClassName ); >>> if ( !typeResolution.isResolved() ) { >>> return null; >>> } >>> >>> final TypeDescription typeDescription = >>> typeResolution.resolve(); >>> ======= >>> >>> i.e. testing the resolution of the type. >>> >>> That might fix it. >>> >>> -- >>> Guillaume >>> >>> On Tue, Mar 26, 2019 at 5:39 PM Scott Marlow wrote: >>> >>> > Thinking more about this, I don't think that ByteBuddy should be able >>> to >>> > do a classloader.getResource() on the class that is being defined >>> > (SLSBPersistenceContexts$$$view5.class). It might be correct for the >>> > getResource call to return null, until after the class is completely >>> > defined. >>> > >>> > Would it make sense for the above condition (cl.getResource() returning >>> > null) be detected differently in the callstack [1] and just fall >>> through >>> > + return to the caller? >>> > >>> > Scott >>> > >>> > [1] >>> https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd >>> > >>> > On 3/26/19 9:53 AM, Scott Marlow wrote: >>> > > Hi Tomek, >>> > > >>> > > I think the pending question now is why ByteBuddy is getting a null >>> > > result from the >>> > > >>> > >>> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") >>> > >>> > > call. >>> > > >>> > > We have also seen failures for >>> > > org.jboss.as.ejb3.SerializationProxyHackImplementation as well, >>> which is >>> > > also generated by the EJB container (see exception call stack in >>> > > https://issues.jboss.org/browse/WFLY-11891). >>> > > >>> > > I wonder if this could be an ordering bug where classes generated via >>> > > JBoss ClassFileWriter are added to the classloader list of classes, >>> > > before the actual bytecode is added. >>> > > >>> > > Scott >>> > > >>> > > On 3/26/19 9:17 AM, Tomasz Adamski wrote: >>> > >> Hi Scott, >>> > >> >>> > >> Added to my TODO. WIll try to look at it this week. >>> > >> >>> > >> Regards, >>> > >> Tomek >>> > >> >>> > >> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow >> > >> > wrote: >>> > >> >>> > >> Adding Tomek + Cheng, as they have been working on the WildFly >>> EJB >>> > >> layer >>> > >> recently, which seems to use >>> > >> https://github.com/jbossas/jboss-classfilewriter for generating >>> > >> the EJB >>> > >> stub classes like >>> > >> >>> > >> >>> > >>> org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class. >>> > >>> > >> >>> > >> >>> > >> Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) >>> or >>> > >> ByteBuddy should change to handle dynamically generated classes >>> > >> differently. >>> > >> >>> > >> In other words, should ByteBuddy respond differently to >>> > >> >>> > >> >>> > >>> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") >>> > >>> > >> >>> > >> >>> > >> returning null or should the jboss-classfilewriter project >>> somehow >>> > >> avoid >>> > >> this bug. >>> > >> >>> > >> Scott >>> > >> >>> > >> On 3/22/19 2:54 AM, Gail Badner wrote: >>> > >> > Scott added bytecode enhancement to some WildFly tests for >>> > >> WFLY-11891 [1], >>> > >> > which are failing. >>> > >> > >>> > >> > Here is Scott's PR with the updated tests: [2] >>> > >> > >>> > >> > When I stepped into >>> > >> > >>> > >> >>> > >> >>> > >>> org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase, >>> > >>> > >> >>> > >> > I can see that they are failing in ByteBuddy code. >>> > >> > >>> > >> > I see that: >>> > >> > >>> > >> > - enhancement of >>> > >> > >>> > >> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts >>> gets >>> > >> > skipped several times in a row; >>> > >> > - enhancement of some other classes get skipped; >>> > >> > - before trying to enhance >>> > >> > >>> > >> >>> > >>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, >>> > >> an >>> > >> > exception is thrown. >>> > >> > >>> > >> > Unfortunately, I'm having trouble getting a good stacktrace >>> to >>> > >> show what >>> > >> > happens in ByteBuddy code. >>> > >> > >>> > >> > Here is what I'm seeing: >>> > >> > >>> > >> > >>> > >> >>> > >> >>> > >>> net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") >>> > >>> > >> >>> > >> > /* class name differs from run to run */ >>> > >> > >>> > >> > >>> > >> > calls >>> > >> net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( " >>> > >> > >>> > >> >>> > >> >>> > >>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") >>> > >> > >>> > >> > calls >>> > >> net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate( >>> > >> > classLoader, >>> > >> >>> > >> >>> > >>> "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5" >>> > >> > ) >>> > >> > >>> > >> > calls >>> > >> > >>> > >> >>> > >> >>> > >>> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"), >>> > >>> > >> >>> > >> > which returns null; >>> > >> > >>> > >> > (I don't actually see a class file with this name) >>> > >> > >>> > >> > >>> > >> > returns new TypePool.Resolution.Illegal( >>> > >> > >>> > >> > >>> > >> >>> > >> >>> > >>> "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class" >>> > >>> > >> >>> > >> > >>> > >> > ) >>> > >> > >>> > >> > returns TypePool.Resolution.Illegal >>> > >> > >>> > >> > >>> > >> > Ultimately, TypePool.Resolution.Illegal#resolve( ) throws >>> > >> > IllegalStateException, because the type description cannot be >>> > >> resolved. >>> > >> > >>> > >> > I'm not sure if the problem is in WildFly, Hibernate, or >>> > >> ByteBuddy. >>> > >> > >>> > >> > To build WildFly: >>> > >> > ./build.sh clean install -DskipTests=true >>> > >> > >>> > >> > To run the test: >>> > >> > cd testsuite/integration/basic >>> > >> > mvn install >>> > >> > >>> > >> >>> > >> >>> > >>> -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase >>> > >>> > >> >>> > >> > >>> > >> > Help would be very much appreciated. >>> > >> > >>> > >> > Thanks, >>> > >> > Gail >>> > >> > >>> > >> > [1] https://issues.jboss.org/browse/WFLY-11891 >>> > >> > [2] https://github.com/wildfly/wildfly/pull/12180 >>> > >> > _______________________________________________ >>> > >> > hibernate-dev mailing list >>> > >> > hibernate-dev at lists.jboss.org >>> > >> >>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >> > >>> > >> >>> > >> >>> > >> >>> > >> -- >>> > >> Regards, >>> > >> Tomek >>> > _______________________________________________ >>> > 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 Thu Mar 28 16:49:11 2019 From: gbadner at redhat.com (Gail Badner) Date: Thu, 28 Mar 2019 13:49:11 -0700 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: References: <610c6898-5fa7-8df3-c56e-440b23ad605d@redhat.com> <5ea21748-f59a-1d7e-b4d9-6690a9bc4fe6@redhat.com> <8eb079e4-c9c8-4ab1-c875-115a873bdf44@redhat.com> Message-ID: Hi Guillaume, I've confirmed that my fix gets the WildFly tests to pass. I've created https://hibernate.atlassian.net/browse/HHH-13343. I'm not sure I understand what you are suggesting by "default behavior". My proposed fix implements a ClassFileLocator checks if the bytecode Hibernate is attempting to enhance is the provided bytecode (by default). Are you suggesting that ByteBuddy should provide a ClassFileLocator implementation that does this? I'm getting a master PR set up. The tricky bit is to come up with a Hibernate unit test that can reproduce this. Scott suggested trying to enhance byte code that has already been enhanced, since the enhanced bytecode would not be available from the ClassLoader. I'm giving this a try. I will (hopefully) have a PR for master branch shortly. Regards, Gail On Thu, Mar 28, 2019 at 10:58 AM Guillaume Smet wrote: > Hi Gail, > > Thanks for looking into this. > > Your commit is interesting as we had people in Quarkus complaining about > the fact that it was not possible to chain the ORM enhancer after other > enhancers as it didn't consider the provided bytes as the "source" to > consider. > > I wonder if what you did (i.e. considering the provided bytes) should be > the default behavior. > > On Thu, Mar 28, 2019 at 7:13 AM Gail Badner wrote: > >> Hi Guillaume, >> >> Unfortunately, it is not so easy. >> >> typeDescription is of type >> TypePool$Default$WithLazyResolution$LazyTypeDescription, and it doesn't get >> completely resolved until later. >> >> I've pushed a branch [1] that seems to work for MultiplePuTestCase. Here >> is the commit [2]. >> >> I haven't had a chance to try the other tests in Scott's PR. I'll give >> them a try tomorrow. >> >> I did not create a Hibernate issue for this yet because I'm not sure if >> Hibernate should be working around this issue. >> >> It's getting late for me tonight. I'll continue tomorrow. >> >> Comments are welcome. >> >> Regards, >> Gail >> >> [1] https://github.com/gbadner/hibernate-core/tree/WFLY-11891-5.3 >> [2] >> https://github.com/gbadner/hibernate-core/commit/ef1687807def94a4465d6cf2372f9235dc559bd1 >> >> On Tue, Mar 26, 2019 at 10:11 AM Gail Badner wrote: >> >>> Guillaume, thanks for the suggestion. I'll give it a try... >>> >>> On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet >>> wrote: >>> >>>> I would try changing the start of EnhancerImpl#enhance() to: >>>> ======= >>>> public byte[] enhance(String className, byte[] originalBytes) throws >>>> EnhancementException { >>>> //Classpool#describe does not accept '/' in the description >>>> name as >>>> it expects a class name. See HHH-12545 >>>> final String safeClassName = className.replace( '/', '.' ); >>>> try { >>>> final Resolution typeResolution = typePool.describe( >>>> safeClassName ); >>>> if ( !typeResolution.isResolved() ) { >>>> return null; >>>> } >>>> >>>> final TypeDescription typeDescription = >>>> typeResolution.resolve(); >>>> ======= >>>> >>>> i.e. testing the resolution of the type. >>>> >>>> That might fix it. >>>> >>>> -- >>>> Guillaume >>>> >>>> On Tue, Mar 26, 2019 at 5:39 PM Scott Marlow >>>> wrote: >>>> >>>> > Thinking more about this, I don't think that ByteBuddy should be able >>>> to >>>> > do a classloader.getResource() on the class that is being defined >>>> > (SLSBPersistenceContexts$$$view5.class). It might be correct for the >>>> > getResource call to return null, until after the class is completely >>>> > defined. >>>> > >>>> > Would it make sense for the above condition (cl.getResource() >>>> returning >>>> > null) be detected differently in the callstack [1] and just fall >>>> through >>>> > + return to the caller? >>>> > >>>> > Scott >>>> > >>>> > [1] >>>> https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd >>>> > >>>> > On 3/26/19 9:53 AM, Scott Marlow wrote: >>>> > > Hi Tomek, >>>> > > >>>> > > I think the pending question now is why ByteBuddy is getting a null >>>> > > result from the >>>> > > >>>> > >>>> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") >>>> > >>>> > > call. >>>> > > >>>> > > We have also seen failures for >>>> > > org.jboss.as.ejb3.SerializationProxyHackImplementation as well, >>>> which is >>>> > > also generated by the EJB container (see exception call stack in >>>> > > https://issues.jboss.org/browse/WFLY-11891). >>>> > > >>>> > > I wonder if this could be an ordering bug where classes generated >>>> via >>>> > > JBoss ClassFileWriter are added to the classloader list of classes, >>>> > > before the actual bytecode is added. >>>> > > >>>> > > Scott >>>> > > >>>> > > On 3/26/19 9:17 AM, Tomasz Adamski wrote: >>>> > >> Hi Scott, >>>> > >> >>>> > >> Added to my TODO. WIll try to look at it this week. >>>> > >> >>>> > >> Regards, >>>> > >> Tomek >>>> > >> >>>> > >> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow >>> > >> > wrote: >>>> > >> >>>> > >> Adding Tomek + Cheng, as they have been working on the WildFly >>>> EJB >>>> > >> layer >>>> > >> recently, which seems to use >>>> > >> https://github.com/jbossas/jboss-classfilewriter for >>>> generating >>>> > >> the EJB >>>> > >> stub classes like >>>> > >> >>>> > >> >>>> > >>>> org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class. >>>> > >>>> > >> >>>> > >> >>>> > >> Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) >>>> or >>>> > >> ByteBuddy should change to handle dynamically generated classes >>>> > >> differently. >>>> > >> >>>> > >> In other words, should ByteBuddy respond differently to >>>> > >> >>>> > >> >>>> > >>>> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") >>>> > >>>> > >> >>>> > >> >>>> > >> returning null or should the jboss-classfilewriter project >>>> somehow >>>> > >> avoid >>>> > >> this bug. >>>> > >> >>>> > >> Scott >>>> > >> >>>> > >> On 3/22/19 2:54 AM, Gail Badner wrote: >>>> > >> > Scott added bytecode enhancement to some WildFly tests for >>>> > >> WFLY-11891 [1], >>>> > >> > which are failing. >>>> > >> > >>>> > >> > Here is Scott's PR with the updated tests: [2] >>>> > >> > >>>> > >> > When I stepped into >>>> > >> > >>>> > >> >>>> > >> >>>> > >>>> org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase, >>>> > >>>> > >> >>>> > >> > I can see that they are failing in ByteBuddy code. >>>> > >> > >>>> > >> > I see that: >>>> > >> > >>>> > >> > - enhancement of >>>> > >> > >>>> > >> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts >>>> gets >>>> > >> > skipped several times in a row; >>>> > >> > - enhancement of some other classes get skipped; >>>> > >> > - before trying to enhance >>>> > >> > >>>> > >> >>>> > >>>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, >>>> > >> an >>>> > >> > exception is thrown. >>>> > >> > >>>> > >> > Unfortunately, I'm having trouble getting a good stacktrace >>>> to >>>> > >> show what >>>> > >> > happens in ByteBuddy code. >>>> > >> > >>>> > >> > Here is what I'm seeing: >>>> > >> > >>>> > >> > >>>> > >> >>>> > >> >>>> > >>>> net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") >>>> > >>>> > >> >>>> > >> > /* class name differs from run to run */ >>>> > >> > >>>> > >> > >>>> > >> > calls >>>> > >> net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( " >>>> > >> > >>>> > >> >>>> > >> >>>> > >>>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") >>>> > >> > >>>> > >> > calls >>>> > >> net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate( >>>> > >> > classLoader, >>>> > >> >>>> > >> >>>> > >>>> "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5" >>>> > >> > ) >>>> > >> > >>>> > >> > calls >>>> > >> > >>>> > >> >>>> > >> >>>> > >>>> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"), >>>> > >>>> > >> >>>> > >> > which returns null; >>>> > >> > >>>> > >> > (I don't actually see a class file with this name) >>>> > >> > >>>> > >> > >>>> > >> > returns new TypePool.Resolution.Illegal( >>>> > >> > >>>> > >> > >>>> > >> >>>> > >> >>>> > >>>> "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class" >>>> > >>>> > >> >>>> > >> > >>>> > >> > ) >>>> > >> > >>>> > >> > returns TypePool.Resolution.Illegal >>>> > >> > >>>> > >> > >>>> > >> > Ultimately, TypePool.Resolution.Illegal#resolve( ) throws >>>> > >> > IllegalStateException, because the type description cannot >>>> be >>>> > >> resolved. >>>> > >> > >>>> > >> > I'm not sure if the problem is in WildFly, Hibernate, or >>>> > >> ByteBuddy. >>>> > >> > >>>> > >> > To build WildFly: >>>> > >> > ./build.sh clean install -DskipTests=true >>>> > >> > >>>> > >> > To run the test: >>>> > >> > cd testsuite/integration/basic >>>> > >> > mvn install >>>> > >> > >>>> > >> >>>> > >> >>>> > >>>> -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase >>>> > >>>> > >> >>>> > >> > >>>> > >> > Help would be very much appreciated. >>>> > >> > >>>> > >> > Thanks, >>>> > >> > Gail >>>> > >> > >>>> > >> > [1] https://issues.jboss.org/browse/WFLY-11891 >>>> > >> > [2] https://github.com/wildfly/wildfly/pull/12180 >>>> > >> > _______________________________________________ >>>> > >> > hibernate-dev mailing list >>>> > >> > hibernate-dev at lists.jboss.org >>>> > >> >>>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >> > >>>> > >> >>>> > >> >>>> > >> >>>> > >> -- >>>> > >> Regards, >>>> > >> Tomek >>>> > _______________________________________________ >>>> > 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 Thu Mar 28 17:39:58 2019 From: gbadner at redhat.com (Gail Badner) Date: Thu, 28 Mar 2019 14:39:58 -0700 Subject: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing In-Reply-To: References: <610c6898-5fa7-8df3-c56e-440b23ad605d@redhat.com> <5ea21748-f59a-1d7e-b4d9-6690a9bc4fe6@redhat.com> <8eb079e4-c9c8-4ab1-c875-115a873bdf44@redhat.com> Message-ID: PR: https://github.com/hibernate/hibernate-orm/pull/2825 On Thu, Mar 28, 2019 at 1:49 PM Gail Badner wrote: > Hi Guillaume, > > I've confirmed that my fix gets the WildFly tests to pass. I've created > https://hibernate.atlassian.net/browse/HHH-13343. > > I'm not sure I understand what you are suggesting by "default behavior". > > My proposed fix implements a ClassFileLocator checks if the bytecode > Hibernate is attempting to enhance is the provided bytecode (by default). > > Are you suggesting that ByteBuddy should provide a ClassFileLocator > implementation that does this? > > I'm getting a master PR set up. The tricky bit is to come up with a > Hibernate unit test that can reproduce this. Scott suggested trying to > enhance byte code that has already been enhanced, since the enhanced > bytecode would not be available from the ClassLoader. I'm giving this a > try. > > I will (hopefully) have a PR for master branch shortly. > > Regards, > Gail > > On Thu, Mar 28, 2019 at 10:58 AM Guillaume Smet > wrote: > >> Hi Gail, >> >> Thanks for looking into this. >> >> Your commit is interesting as we had people in Quarkus complaining about >> the fact that it was not possible to chain the ORM enhancer after other >> enhancers as it didn't consider the provided bytes as the "source" to >> consider. >> >> I wonder if what you did (i.e. considering the provided bytes) should be >> the default behavior. >> >> On Thu, Mar 28, 2019 at 7:13 AM Gail Badner wrote: >> >>> Hi Guillaume, >>> >>> Unfortunately, it is not so easy. >>> >>> typeDescription is of type >>> TypePool$Default$WithLazyResolution$LazyTypeDescription, and it doesn't get >>> completely resolved until later. >>> >>> I've pushed a branch [1] that seems to work for MultiplePuTestCase. Here >>> is the commit [2]. >>> >>> I haven't had a chance to try the other tests in Scott's PR. I'll give >>> them a try tomorrow. >>> >>> I did not create a Hibernate issue for this yet because I'm not sure if >>> Hibernate should be working around this issue. >>> >>> It's getting late for me tonight. I'll continue tomorrow. >>> >>> Comments are welcome. >>> >>> Regards, >>> Gail >>> >>> [1] https://github.com/gbadner/hibernate-core/tree/WFLY-11891-5.3 >>> [2] >>> https://github.com/gbadner/hibernate-core/commit/ef1687807def94a4465d6cf2372f9235dc559bd1 >>> >>> On Tue, Mar 26, 2019 at 10:11 AM Gail Badner wrote: >>> >>>> Guillaume, thanks for the suggestion. I'll give it a try... >>>> >>>> On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet < >>>> guillaume.smet at gmail.com> wrote: >>>> >>>>> I would try changing the start of EnhancerImpl#enhance() to: >>>>> ======= >>>>> public byte[] enhance(String className, byte[] originalBytes) >>>>> throws >>>>> EnhancementException { >>>>> //Classpool#describe does not accept '/' in the description >>>>> name as >>>>> it expects a class name. See HHH-12545 >>>>> final String safeClassName = className.replace( '/', '.' ); >>>>> try { >>>>> final Resolution typeResolution = typePool.describe( >>>>> safeClassName ); >>>>> if ( !typeResolution.isResolved() ) { >>>>> return null; >>>>> } >>>>> >>>>> final TypeDescription typeDescription = >>>>> typeResolution.resolve(); >>>>> ======= >>>>> >>>>> i.e. testing the resolution of the type. >>>>> >>>>> That might fix it. >>>>> >>>>> -- >>>>> Guillaume >>>>> >>>>> On Tue, Mar 26, 2019 at 5:39 PM Scott Marlow >>>>> wrote: >>>>> >>>>> > Thinking more about this, I don't think that ByteBuddy should be >>>>> able to >>>>> > do a classloader.getResource() on the class that is being defined >>>>> > (SLSBPersistenceContexts$$$view5.class). It might be correct for the >>>>> > getResource call to return null, until after the class is completely >>>>> > defined. >>>>> > >>>>> > Would it make sense for the above condition (cl.getResource() >>>>> returning >>>>> > null) be detected differently in the callstack [1] and just fall >>>>> through >>>>> > + return to the caller? >>>>> > >>>>> > Scott >>>>> > >>>>> > [1] >>>>> https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd >>>>> > >>>>> > On 3/26/19 9:53 AM, Scott Marlow wrote: >>>>> > > Hi Tomek, >>>>> > > >>>>> > > I think the pending question now is why ByteBuddy is getting a null >>>>> > > result from the >>>>> > > >>>>> > >>>>> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") >>>>> > >>>>> > > call. >>>>> > > >>>>> > > We have also seen failures for >>>>> > > org.jboss.as.ejb3.SerializationProxyHackImplementation as well, >>>>> which is >>>>> > > also generated by the EJB container (see exception call stack in >>>>> > > https://issues.jboss.org/browse/WFLY-11891). >>>>> > > >>>>> > > I wonder if this could be an ordering bug where classes generated >>>>> via >>>>> > > JBoss ClassFileWriter are added to the classloader list of classes, >>>>> > > before the actual bytecode is added. >>>>> > > >>>>> > > Scott >>>>> > > >>>>> > > On 3/26/19 9:17 AM, Tomasz Adamski wrote: >>>>> > >> Hi Scott, >>>>> > >> >>>>> > >> Added to my TODO. WIll try to look at it this week. >>>>> > >> >>>>> > >> Regards, >>>>> > >> Tomek >>>>> > >> >>>>> > >> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow >>>> > >> > wrote: >>>>> > >> >>>>> > >> Adding Tomek + Cheng, as they have been working on the >>>>> WildFly EJB >>>>> > >> layer >>>>> > >> recently, which seems to use >>>>> > >> https://github.com/jbossas/jboss-classfilewriter for >>>>> generating >>>>> > >> the EJB >>>>> > >> stub classes like >>>>> > >> >>>>> > >> >>>>> > >>>>> org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class. >>>>> > >>>>> > >> >>>>> > >> >>>>> > >> Perhaps Tomek or Cheng, can answer whether WildFly (EJB >>>>> layer) or >>>>> > >> ByteBuddy should change to handle dynamically generated >>>>> classes >>>>> > >> differently. >>>>> > >> >>>>> > >> In other words, should ByteBuddy respond differently to >>>>> > >> >>>>> > >> >>>>> > >>>>> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class") >>>>> > >>>>> > >> >>>>> > >> >>>>> > >> returning null or should the jboss-classfilewriter project >>>>> somehow >>>>> > >> avoid >>>>> > >> this bug. >>>>> > >> >>>>> > >> Scott >>>>> > >> >>>>> > >> On 3/22/19 2:54 AM, Gail Badner wrote: >>>>> > >> > Scott added bytecode enhancement to some WildFly tests for >>>>> > >> WFLY-11891 [1], >>>>> > >> > which are failing. >>>>> > >> > >>>>> > >> > Here is Scott's PR with the updated tests: [2] >>>>> > >> > >>>>> > >> > When I stepped into >>>>> > >> > >>>>> > >> >>>>> > >> >>>>> > >>>>> org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase, >>>>> > >>>>> > >> >>>>> > >> > I can see that they are failing in ByteBuddy code. >>>>> > >> > >>>>> > >> > I see that: >>>>> > >> > >>>>> > >> > - enhancement of >>>>> > >> > >>>>> > >> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts >>>>> gets >>>>> > >> > skipped several times in a row; >>>>> > >> > - enhancement of some other classes get skipped; >>>>> > >> > - before trying to enhance >>>>> > >> > >>>>> > >> >>>>> > >>>>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, >>>>> > >> an >>>>> > >> > exception is thrown. >>>>> > >> > >>>>> > >> > Unfortunately, I'm having trouble getting a good >>>>> stacktrace to >>>>> > >> show what >>>>> > >> > happens in ByteBuddy code. >>>>> > >> > >>>>> > >> > Here is what I'm seeing: >>>>> > >> > >>>>> > >> > >>>>> > >> >>>>> > >> >>>>> > >>>>> net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") >>>>> > >>>>> > >> >>>>> > >> > /* class name differs from run to run */ >>>>> > >> > >>>>> > >> > >>>>> > >> > calls >>>>> > >> net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( " >>>>> > >> > >>>>> > >> >>>>> > >> >>>>> > >>>>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") >>>>> > >> > >>>>> > >> > calls >>>>> > >> net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate( >>>>> > >> > classLoader, >>>>> > >> >>>>> > >> >>>>> > >>>>> "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5" >>>>> > >> > ) >>>>> > >> > >>>>> > >> > calls >>>>> > >> > >>>>> > >> >>>>> > >> >>>>> > >>>>> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"), >>>>> > >>>>> > >> >>>>> > >> > which returns null; >>>>> > >> > >>>>> > >> > (I don't actually see a class file with this name) >>>>> > >> > >>>>> > >> > >>>>> > >> > returns new TypePool.Resolution.Illegal( >>>>> > >> > >>>>> > >> > >>>>> > >> >>>>> > >> >>>>> > >>>>> "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class" >>>>> > >>>>> > >> >>>>> > >> > >>>>> > >> > ) >>>>> > >> > >>>>> > >> > returns TypePool.Resolution.Illegal >>>>> > >> > >>>>> > >> > >>>>> > >> > Ultimately, TypePool.Resolution.Illegal#resolve( ) throws >>>>> > >> > IllegalStateException, because the type description cannot >>>>> be >>>>> > >> resolved. >>>>> > >> > >>>>> > >> > I'm not sure if the problem is in WildFly, Hibernate, or >>>>> > >> ByteBuddy. >>>>> > >> > >>>>> > >> > To build WildFly: >>>>> > >> > ./build.sh clean install -DskipTests=true >>>>> > >> > >>>>> > >> > To run the test: >>>>> > >> > cd testsuite/integration/basic >>>>> > >> > mvn install >>>>> > >> > >>>>> > >> >>>>> > >> >>>>> > >>>>> -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase >>>>> > >>>>> > >> >>>>> > >> > >>>>> > >> > Help would be very much appreciated. >>>>> > >> > >>>>> > >> > Thanks, >>>>> > >> > Gail >>>>> > >> > >>>>> > >> > [1] https://issues.jboss.org/browse/WFLY-11891 >>>>> > >> > [2] https://github.com/wildfly/wildfly/pull/12180 >>>>> > >> > _______________________________________________ >>>>> > >> > hibernate-dev mailing list >>>>> > >> > hibernate-dev at lists.jboss.org >>>>> > >> >>>>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> > >> > >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> -- >>>>> > >> Regards, >>>>> > >> Tomek >>>>> > _______________________________________________ >>>>> > 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 rory.odonnell at oracle.com Fri Mar 29 07:11:44 2019 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 29 Mar 2019 11:11:44 +0000 Subject: [hibernate-dev] JDK 13 - Early Access build 14 is available Message-ID: <82e60d6b-e8ab-9943-6894-30d21ec859c6@oracle.com> Hi Sanne, *OpenJDK builds *- JDK 13 - Early Access build 14 is available at http://jdk.java.net/13/ * These early-access, open-source builds are provided under the GNU General Public License, version?2, with the Classpath Exception . * Changes in this build * Release notes [1] * JDK 13 Schedule proposal accepted [2] o 2019/06/13 Rampdown Phase One o 2019/07/18 Rampdown Phase Two o 2019/08/08 Initial Release Candidate o 2019/08/22 Final Release Candidate o 2019/09/17 General Availability *jpackage EA * * This is an early access build of JEP 343: Packaging Tool , aimed at testing a prototype implementation of jpackage, which is a new tool for packaging self-contained Java applications along with a Java Runtime Environment. * Build 30 is now available http://jdk.java.net/jpackage/ * Please send feedback via e-mail to core-libs-dev at openjdk.java.net *Quality Outreach report for **March 2019* * The report for March 2019 is available here * Thanks to all those contributed ! *Recent Blog:* A new (Japanese) era for Java! Rgds,Rory [1] http://jdk.java.net/13/release-notes [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002736.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland