On Wed, Jan 11, 2017 at 5:52 AM, Sanne Grinovero <sanne(a)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-modu...
[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