[hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules

[Gunnar Morling]

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 <smarlow at redhat.com>:
> On Wed, Jan 11, 2017 at 5:52 AM, Sanne Grinovero <sanne at 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 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