[hibernate-dev] HHH-11155 : problems updating lazy properties in lazy groups
Static update strings appear to cover only the following situations: 1) there are no uninitialized properties (so all updateable attributes should be updated); 2) all lazy properties are uninitialized (so only non-lazy, updateable attributes should be updated). As of 5.1, we have "lazy groups". It is possible some lazy groups are initialized, and some are uninitialized. We have a couple of alternatives for dealing with the various combinations: For example, if there are are 3 lazy groups: lazyGroup1, lazyGroup2, lazyGroup3. 1) Generate SQL update strings for all possible combinations of initialized lazy groups: SQL update strings are already generated for the following combinations: * lazyGroup1: uninitialized; lazyGroup2: uninitialized; lazyGroup3: uninitialized * lazyGroup1: initialized; lazyGroup2: initialized; lazyGroup3: initialized SQL update strings for the following combinations need to be generated to fix the bug: * lazyGroup1: initialized; lazyGroup2: uninitialized; lazyGroup3: uninitialized * lazyGroup1: uninitialized; lazyGroup2: initialized; lazyGroup3: uninitialized * lazyGroup1: uninitialized; lazyGroup2: uninitialized; lazyGroup3: initialized * lazyGroup1: initialized; lazyGroup2: initialized; lazyGroup3: uninitialized * lazyGroup1: initialized; lazyGroup2: uninitialized; lazyGroup3: initialized * lazyGroup1: uninitialized; lazyGroup2: initialized; lazyGroup3: initialized The update strings could be stored in a Map with key containing the names (or indexes?) of the corresponding initialized lazy groups. 2) Generate dynamic update strings when there is at least 1 uninitialized group, or when there are more than N lazy groups. What should N be? Comments or suggestions? A related bug is that calling a setter on a lazy property only initializes that one lazy property. It should also initialize other properties in the same lazy group. This one is pretty easy to fix. Thanks, Gail ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Starting 5.2.4 release
Please do not push anything to master branch. Thanks, Andrea ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate ORM 5.2.4.Final has been released
For details: http://in.relation.to/2016/10/26/hibernate-orm-524-final-release/ ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly
Hi all, there's a conflict in the Javassist versions of the WildFly modules of Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not familiar with this functionality. The module declares *both*: - a dependency to the WildFly provided Javassist: - inclusion of Hibernate's own version of Javassist: Having both is causing trouble as they are both visible to the Hibernate classloader; however I couldn't score a quick win with the testsuiste by disabling either (all tests using these modules in the Hibernate Search testsuite fail). I suspect the problem is that JipiJapa also depends on the , while ORM obviously needs the more recent version of it. I'm not familiar with what JipiJapa's business around Javassist; could we keep the two clearly separated? Especially if we want to make Byte Buddy a viable alternative, I suspect the solution is that JipiJapa should not depend on Javassist directly, but invoke a generic instrumentation SPI on Hibernate; also with JipiJapa not able to see Javassist at all, we'd be in control of the one and only Javassist version visible to ORM: the one we compile and test with. Thanks, Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly
Would be interesting to know why JipiJapa is depending on it. In a quick search I couldn't spot any actual usages. JPADependencyProcessor adds a dependency to "org.javassist", maybe that could be avoided by having the ORM module re-export the version of JipiJipa it is using? For that he module ZIP would have to contain a module for the new JipiJapa version and ORM's module.xml would depend on it and re-export it. --Gunnar 2016-10-26 23:19 GMT+02:00 Sanne Grinovero : > Hi all, > > there's a conflict in the Javassist versions of the WildFly modules of > Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not > familiar with this functionality. > > The module declares *both*: > - a dependency to the WildFly provided Javassist: name="org.javassist"/> > - inclusion of Hibernate's own version of Javassist: path="javassist-3.20.0-GA.jar"/> > > Having both is causing trouble as they are both visible to the > Hibernate classloader; however I couldn't score a quick win with the > testsuiste by disabling either (all tests using these modules in the > Hibernate Search testsuite fail). > > I suspect the problem is that JipiJapa also depends on the name="org.javassist"/>, while ORM obviously needs the more recent > version of it. > > I'm not familiar with what JipiJapa's business around Javassist; could > we keep the two clearly separated? > > Especially if we want to make Byte Buddy a viable alternative, I > suspect the solution is that JipiJapa should not depend on Javassist > directly, but invoke a generic instrumentation SPI on Hibernate; also > with JipiJapa not able to see Javassist at all, we'd be in control of > the one and only Javassist version visible to ORM: the one we compile > and test with. > > Thanks, > Sanne > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly
Just to be clear, Jipijapa doesn't use Javassist at all. For JPA deployments that are using Hibernate, the (WildFly) JPA container is exporting the org.javassist:module to the application deployment classloader, so that the Javassist proxy runtime classes can be referenced by application classes that are rewritten by ORM. If we were to use ByteBuddy, there are no runtime proxy classes needed on the application classpath. There is currently no way to tell the JPA container how to export a different Javassist module to the application deployment. The best solution is for the JPA container to stop exporting Javassist to the application classpath, which means an ORM change to that effect (either shadow the Javassist runtime proxy classes or something like that, or try using ByteBuddy instead). If we were to add a configuration hint for the JPA compiler to inject a different version of javassist, I don't have confidence that the code change would be merged, since we really want a better fix. On Wed, Oct 26, 2016 at 5:19 PM, Sanne Grinovero wrote: > Hi all, > > there's a conflict in the Javassist versions of the WildFly modules of > Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not > familiar with this functionality. > > The module declares *both*: > - a dependency to the WildFly provided Javassist: name="org.javassist"/> > - inclusion of Hibernate's own version of Javassist: path="javassist-3.20.0-GA.jar"/> > > Having both is causing trouble as they are both visible to the > Hibernate classloader; however I couldn't score a quick win with the > testsuiste by disabling either (all tests using these modules in the > Hibernate Search testsuite fail). > > I suspect the problem is that JipiJapa also depends on the name="org.javassist"/>, while ORM obviously needs the more recent > version of it. > > I'm not familiar with what JipiJapa's business around Javassist; could > we keep the two clearly separated? > > Especially if we want to make Byte Buddy a viable alternative, I > suspect the solution is that JipiJapa should not depend on Javassist > directly, but invoke a generic instrumentation SPI on Hibernate; also > with JipiJapa not able to see Javassist at all, we'd be in control of > the one and only Javassist version visible to ORM: the one we compile > and test with. > > Thanks, > Sanne > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly
Hi, 2016-10-27 0:44 GMT+02:00 Scott Marlow : > Just to be clear, Jipijapa doesn't use Javassist at all. Ok. What is the reason then that it is declaring this module dependency? > For JPA > deployments that are using Hibernate, the (WildFly) JPA container is > exporting the org.javassist:module to the application deployment > classloader, so that the Javassist proxy runtime classes can be > referenced by application classes that are rewritten by ORM. Couldn't this be achieved by having the ORM module re-export the Javassist module it depends on (in the module.xml of ORM, that is)? That way JipiJapa would make no assumption about Javassist at all, it'd be left to the ORM module as added by JipiJapa to the deployment. > If we > were to use ByteBuddy, there are no runtime proxy classes needed on > the application classpath. > > There is currently no way to tell the JPA container how to export a > different Javassist module to the application deployment. The best > solution is for the JPA container to stop exporting Javassist to the > application classpath, which means an ORM change to that effect > (either shadow the Javassist runtime proxy classes or something like > that, or try using ByteBuddy instead). > > If we were to add a configuration hint for the JPA compiler to inject > a different version of javassist, I don't have confidence that the > code change would be merged, since we really want a better fix. > > On Wed, Oct 26, 2016 at 5:19 PM, Sanne Grinovero > wrote: > > Hi all, > > > > there's a conflict in the Javassist versions of the WildFly modules of > > Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not > > familiar with this functionality. > > > > The module declares *both*: > > - a dependency to the WildFly provided Javassist: > name="org.javassist"/> > > - inclusion of Hibernate's own version of Javassist: > path="javassist-3.20.0-GA.jar"/> > > > > Having both is causing trouble as they are both visible to the > > Hibernate classloader; however I couldn't score a quick win with the > > testsuiste by disabling either (all tests using these modules in the > > Hibernate Search testsuite fail). > > > > I suspect the problem is that JipiJapa also depends on the > name="org.javassist"/>, while ORM obviously needs the more recent > > version of it. > > > > I'm not familiar with what JipiJapa's business around Javassist; could > > we keep the two clearly separated? > > > > Especially if we want to make Byte Buddy a viable alternative, I > > suspect the solution is that JipiJapa should not depend on Javassist > > directly, but invoke a generic instrumentation SPI on Hibernate; also > > with JipiJapa not able to see Javassist at all, we'd be in control of > > the one and only Javassist version visible to ORM: the one we compile > > and test with. > > > > Thanks, > > Sanne > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly
On Wed, Oct 26, 2016 at 6:58 PM, Gunnar Morling wrote: > Hi, > > 2016-10-27 0:44 GMT+02:00 Scott Marlow : >> >> Just to be clear, Jipijapa doesn't use Javassist at all. > > > Ok. What is the reason then that it is declaring this module dependency? No reason, looks like an unneeded dependency that could be removed. > >> >> For JPA >> deployments that are using Hibernate, the (WildFly) JPA container is >> exporting the org.javassist:module to the application deployment >> classloader, so that the Javassist proxy runtime classes can be >> referenced by application classes that are rewritten by ORM. > > > Couldn't this be achieved by having the ORM module re-export the Javassist > module it depends on (in the module.xml of ORM, that is)? > > > > That way JipiJapa would make no assumption about Javassist at all, it'd be > left to the ORM module as added by JipiJapa to the deployment. I agree. We created a pull request (Pull request link is https://github.com/wildfly/wildfly/pull/8474) for that previously but it didn't get merged because ORM shouldn't require the application classpath to contain Javassist classes, as that could conflict with the application also wanting to include a different version of Javassist for the application to use. Is the ORM testsuite building the WildFly app server from source? if yes, perhaps we could build WildFly with the newer Javassist: ./build.sh clean install -Dversion.org.javassist=3.20.0-GA Other option would be to use ByteBuddy to generate proxies instead of Javassist to eliminate the application dependency on the Javassist runtime classes. > >> >> If we >> were to use ByteBuddy, there are no runtime proxy classes needed on >> the application classpath. >> >> There is currently no way to tell the JPA container how to export a >> different Javassist module to the application deployment. The best >> solution is for the JPA container to stop exporting Javassist to the >> application classpath, which means an ORM change to that effect >> (either shadow the Javassist runtime proxy classes or something like >> that, or try using ByteBuddy instead). >> >> If we were to add a configuration hint for the JPA compiler to inject >> a different version of javassist, I don't have confidence that the >> code change would be merged, since we really want a better fix. >> >> On Wed, Oct 26, 2016 at 5:19 PM, Sanne Grinovero >> wrote: >> > Hi all, >> > >> > there's a conflict in the Javassist versions of the WildFly modules of >> > Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not >> > familiar with this functionality. >> > >> > The module declares *both*: >> > - a dependency to the WildFly provided Javassist: > > name="org.javassist"/> >> > - inclusion of Hibernate's own version of Javassist: > > path="javassist-3.20.0-GA.jar"/> >> > >> > Having both is causing trouble as they are both visible to the >> > Hibernate classloader; however I couldn't score a quick win with the >> > testsuiste by disabling either (all tests using these modules in the >> > Hibernate Search testsuite fail). >> > >> > I suspect the problem is that JipiJapa also depends on the > > name="org.javassist"/>, while ORM obviously needs the more recent >> > version of it. >> > >> > I'm not familiar with what JipiJapa's business around Javassist; could >> > we keep the two clearly separated? >> > >> > Especially if we want to make Byte Buddy a viable alternative, I >> > suspect the solution is that JipiJapa should not depend on Javassist >> > directly, but invoke a generic instrumentation SPI on Hibernate; also >> > with JipiJapa not able to see Javassist at all, we'd be in control of >> > the one and only Javassist version visible to ORM: the one we compile >> > and test with. >> > >> > Thanks, >> > Sanne >> > ___ >> > hibernate-dev mailing list >> > hibernate-dev@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly
On Wed, Oct 26, 2016 at 8:33 PM Scott Marlow wrote: > On Wed, Oct 26, 2016 at 6:58 PM, Gunnar Morling > wrote: > > Couldn't this be achieved by having the ORM module re-export the > Javassist > > module it depends on (in the module.xml of ORM, that is)? > > > > > > > > That way JipiJapa would make no assumption about Javassist at all, it'd > be > > left to the ORM module as added by JipiJapa to the deployment. > > I agree. > > We created a pull request (Pull request link is > https://github.com/wildfly/wildfly/pull/8474) for that previously but > it didn't get merged because ORM shouldn't require the application > classpath to contain Javassist classes, as that could conflict with > the application also wanting to include a different version of > Javassist for the application to use. > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module (the WF module) export Javassist. Not the application. Is the ORM testsuite building the WildFly app server from source? Good god no :) > Other option would be to use ByteBuddy to generate proxies instead of > Javassist to eliminate the application dependency on the Javassist > runtime classes. > Rafael Winterhalter is actually pretty far along on defining support for Byte Buddy in Hibernate[1]. So that might soon be an option. [1] https://hibernate.atlassian.net/browse/HHH-11152 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly
> Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module (the WF module) export Javassist. Not the application. > I agree, that is what our WF pull request did, which I think is an incremental improvement but that wasn't approved for the reason I gave. >> Is the ORM testsuite building the WildFly app server from source? > > > Good god no :) > > >> >> Other option would be to use ByteBuddy to generate proxies instead of >> Javassist to eliminate the application dependency on the Javassist >> runtime classes. > > > > Rafael Winterhalter is actually pretty far along on defining support for Byte Buddy in Hibernate[1]. So that might soon be an option. > > [1] https://hibernate.atlassian.net/browse/HHH-11152 > +100 :) ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
