Hi,
2016-10-27 0:44 GMT+02:00 Scott Marlow <smar...@redhat.com>:
> Just to be clear, Jipijapa doesn't use Javassist at all.
Ok. What is the reason then that it is declaring this module dependency?
> For JPA
> deployments that are using Hibernate, the (WildFly) JPA container is
> exporting the org.javassist:module to the application deployment
> classloader, so that the Javassist proxy runtime classes can be
> referenced by application classes that are rewritten by ORM.
Couldn't this be achieved by having the ORM module re-export the Javassist
module it depends on (in the module.xml of ORM, that is)?
<module name="org.javassist" export="true"/>
That way JipiJapa would make no assumption about Javassist at all, it'd be
left to the ORM module as added by JipiJapa to the deployment.
> If we
> were to use ByteBuddy, there are no runtime proxy classes needed on
> the application classpath.
>
> There is currently no way to tell the JPA container how to export a
> different Javassist module to the application deployment. The best
> solution is for the JPA container to stop exporting Javassist to the
> application classpath, which means an ORM change to that effect
> (either shadow the Javassist runtime proxy classes or something like
> that, or try using ByteBuddy instead).
>
> If we were to add a configuration hint for the JPA compiler to inject
> a different version of javassist, I don't have confidence that the
> code change would be merged, since we really want a better fix.
>
> On Wed, Oct 26, 2016 at 5:19 PM, Sanne Grinovero <sa...@hibernate.org>
> wrote:
> > Hi all,
> >
> > there's a conflict in the Javassist versions of the WildFly modules of
> > Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not
> > familiar with this functionality.
> >
> > The module declares *both*:
> > - a dependency to the WildFly provided Javassist: <module
> > name="org.javassist"/>
> > - inclusion of Hibernate's own version of Javassist: <resource-root
> > path="javassist-3.20.0-GA.jar"/>
> >
> > Having both is causing trouble as they are both visible to the
> > Hibernate classloader; however I couldn't score a quick win with the
> > testsuiste by disabling either (all tests using these modules in the
> > Hibernate Search testsuite fail).
> >
> > I suspect the problem is that JipiJapa also depends on the <module
> > name="org.javassist"/>, while ORM obviously needs the more recent
> > version of it.
> >
> > I'm not familiar with what JipiJapa's business around Javassist; could
> > we keep the two clearly separated?
> >
> > Especially if we want to make Byte Buddy a viable alternative, I
> > suspect the solution is that JipiJapa should not depend on Javassist
> > directly, but invoke a generic instrumentation SPI on Hibernate; also
> > with JipiJapa not able to see Javassist at all, we'd be in control of
> > the one and only Javassist version visible to ORM: the one we compile
> > and test with.
> >
> > Thanks,
> > Sanne
> > _______________________________________________
> > 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
