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

[Scott Marlow]

Ahh, I was confused then, your talking about the WildFly ORM static
module definition [1], which is not controlled by the JPA container or
JipiJapa.

>>
>> 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 ;-)

There are no flags for controlling [1], if you want control, just fork
WildFly and make occasional changes to the static module definitions
that meet your testing changes.  Just keep the changes as minimal as
possible, so it is easy to sync up the (test purposes) fork.  The
painful part though might be trying to push your fork to maven, so
perhaps this is a bad idea, but still wanted to mention it, in case it
could help.

>>
>> 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'm not sure how you could dynamically update the ORM static module
definition [1].

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

ORM definitely still needs the Javassist dependency, but we should
drop ASM, as that is not needed, as well as a few others.

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

I agree, but others didn't when this came up on the JPA expert group
mailing list before.

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

I agree that you really need control over the static ORM module
definitions.  If you don't want to fork WildFly for testing, perhaps
you could modify the static orm module definition before starting the
app server, for the testing.  Sounds like a pita.

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

Its more that the WildFly JPA container, allows the persistence
provider to register a javax.persistence.spi.ClassTransformer
instance, to be called when entity class definitions are loaded, as
per the JPA requirements.  JipiJapa doesn't get involved, as there is
a standard JPA contract that ORM uses, so JipiJapa couldn't influence
use of Byte Buddy or CGLIB or Javassist...

>
> 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 ;)
:(

Scott

[1] https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml#L47