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

[Scott Marlow]

On Wed, Jan 11, 2017 at 11:19 AM, Steve Ebersole <steve at hibernate.org> wrote:
> I think the best option in terms of supporting legacy ORM version users
> would be to incorporate a change in those branches to shade/shadow Javassist
> into ORM specific packages (in hibernate-core).

+1

>
> As I understand it, it is always ORM that does the enhancement, right Scott?

Yes, ORM always does the enhancement.

>
> On Wed, Jan 11, 2017 at 10:12 AM Scott Marlow <smarlow at redhat.com> wrote:
>>
>> 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
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev