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

Wed Jan 11 10:43:52 EST 2017

On 11 January 2017 at 14:59, Scott Marlow <smarlow at redhat.com> wrote:
> 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.

Like I replied to Gunnar, that's a different problem. Sorry all for
the confusion!

In this case it's Hibernate ORM which is being fed two different
versions of Javassist simultaneously; clearly that's our fault. The
application classpath is not affected.

> 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.

I'm not trying to use Javassist. If only the flags to disable it would
work I'd be happy to disable it ;-)

>> #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.

Thanks! Sure I'd be happy to contribute these to WildFly, but knowing
which dependency is needed - or MIGHT be needed in certain
configurations - requires in depth knowledge of the module one wants
to cleanup.
I just have the *impression* that some of these dependencies are no
longer needed, but going back and forth between projects at different
releases - and supposed to support various other versions - doesn't
make it easy.

So I suspect that if the adaptor code itself was bundled directly with
the consuming JPA implementor, this would come more natural? Just an
idea.

See the problem is Hibernate Search needs to test with latest ORM way
more regularly, so I can't wait for PRs to be included in WildFly,
even less so if they are on hold because of even slower EAP cycles.

>
>>  - 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.

What I mean is that JipiJapa is currently triggering enhancement via
Javassist; it's not giving me an option to use Byte Buddy instead.

So since the sources for that are in yet another project, it looks
like I'd need 6 months to finish my ORM upgrade in Search. Luckily
I'll aim for a different solution ;)

>> ## 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