Didn't we want to migrate off of Javassist for ORM 6, going for ByteBuddy exclusively? https://hibernate.atlassian.net/browse/HHH-11253 discusses that.
2017-01-11 15:59 GMT+01:00 Scott Marlow <smar...@redhat.com>: > On Wed, Jan 11, 2017 at 5:52 AM, Sanne Grinovero <sa...@hibernate.org> wrote: >> Hi all, >> I'm finding several issues around this subject. While I tried several >> workarounds, I'd like us to agree on a strategy to address the root >> problem which is that Hibernate ORM might not necessarily want to use >> the Javassist version provided by WildFly, yet this is currently being >> forced on us. > > We talked about this not long ago and possible solutions, the only > agreed on solution was to eliminate the ORM requirement for Javassist > classes to be on the application classpath, by switching to ByteBuddy. > > Could you could use one of the previously suggested solutions in your > testing? For example, your application could use a shaded Javassist > jar, that doesn't interfere with the ORM Javassist. > >> >> #Manifestation >> The problem manifests itself as a ClassCastException on casting the >> enhanced entity to a Javassist Proxy: it has been enhanced by a >> different Javassist instance than the one being used by ORM during >> runtime. >> >> #Need more tests >> First of, let me clarify that these issues are highlighted only the >> Hibernate Search testsuite, as we're trying to use these modules. >> Apparently the two tests we have in ORM to cover for the modules were >> not enough to highlight this problem.. we'll need to expand them. >> >> #The problem: duplicate dependency >> The WildFly modules include the Javassist version which ORM is using >> during the build, but also depends on the one provided by WildFly: >> >> - >> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-orm-modules/src/main/modules/org/hibernate/core/module.xml#L12-L31 >> >> [There seems to be a comment about this but I guess we forgot to >> actually comment out the next line] >> >> #Which one? >> So I tried to comment out the reference to the WildFly module, but >> that gets me in more trouble as the JipiJapa integration will (my >> guess) use the "WildFly edition" of Javassist. >> Doing the opposite actually seems to work fine, but I guess there are >> reasons for ORM to have upgraded Javassist? >> >> #Failed workarounds >> I tried to disable class enhancement by setting either (and both!) of: >> - jboss.as.jpa.classtransformer = false >> - hibernate.ejb.use_class_enhancer = false >> I found these on the WildFly JPA Wiki [1], but it looks like they are >> not effective? > > I believe that ORM is always rewriting entity classes by default. Is > the default ORM entity enhancement, occurring when the entity classes > are mapped (eagerly)? That could be the only reason that I can think > of why, setting "jboss.as.jpa.classtransformer=false" wouldn't help. > If that is not the case, let me know. > >> >> #Viable workaround >> Removing the new Javassist version from the ORM module fixed my >> problems, but I'm not comfortable with this unless someone could >> confirm the version upgrade can wait, at least for the purpose of what >> we package in these modules? >> >> #Better fix >> I suspect the better solution would be for ORM to fully re-package the >> JipiJapa integration, so that we're able to be in control of version >> upgrade needs without having to wait for WildFly release cycles and >> other planets to align. >> >> #Wishlist: Modules refactoring >> Another reason for which I'd like ORM to "own" these modules, is that >> we could evolve them better. For example: >> - it seems the JipiJapa integration is having loads of dependencies >> which I suspect it doesn't really need. > > Why don't you contribute code changes instead to WildFly? I did > create a pull request for https://issues.jboss.org/browse/WFLY-5773 > that is still pending, to remove some unneeded dependencies. This > won't get merged without an EAP jira that goes with it, which I don't > plan to create, since there is no EAP need for the change. Pull > request is https://github.com/wildfly/wildfly/pull/9305. > >> - we should hide Javassist & Byte Buddy from being exposed to the >> application > > Yes, I agree. You said this before but its ORM that requires > Javassist classes to be on the application classpath. ORM does not > require the Byte Buddy classes to be on the application classpath. > >> - make Byte Buddy an option: I guess improve the JipiJapa itegration >> to support it and move it into its own private module. > > No, ORM doesn't require Byte Buddy to be on the application classpath, > which means that Byte Buddy can be what you want, a separate private > ORM module. This is a feature of WildFly modules, not JipiJapa. > >> >> ## Suggestions? >> I'm stuck again on Hibernate Search upgrading to latest ORM so I'll >> see to apply the workaround without waiting for the proper solution. >> Not sure which actions I should take on ORM? >> >> Personally I think I'd just patch the modules to use the older >> Javassist when running on WildFly; that upgrade should wait for either >> WildFly to upgrade, or use to rethink these modules. >> >> Scott, could you help me by verifying if and were I should open a JIRA >> for those properties being ignored? > > I'm surprised that setting jboss.as.jpa.classtransformer to false, > doesn't help. WildFly does have a > org.jboss.as.test.integration.jpa.mockprovider.classtransformer.ClassFileTransformerTestCase > test that ensures that jboss.as.jpa.classtransformer=true works but > doesn't verify that jboss.as.jpa.classtransformer=false also works. > This would probably help verify that it works. > > Scott >> >> Thanks, >> Sanne >> >> 1 - >> https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-Hibernateproperties >> _______________________________________________ >> 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
