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.
#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? #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. - we should hide Javassist & Byte Buddy from being exposed to the application - make Byte Buddy an option: I guess improve the JipiJapa itegration to support it and move it into its own private module. ## 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? 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
