Following Steve's suggestions I thought I had a reasonable and clean plan, but it's not working in practice.
Turns out that even after me cleaning up all references to "org.javassist:main", it's still been forced on the classpath by hard-coded rules in the JPADependencyProcessor, so conflicting with the right version: - https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/jpa/subsystem/src/main/java/org/jboss/as/jpa/processor/JPADependencyProcessor.java#L95 Is there any way I can prevent this injection from happening? Can I override this JPADependencyProcessor? Thanks, Sanne On 11 January 2017 at 19:42, Scott Marlow <smar...@redhat.com> wrote: > I'm not really sure but did notice that HikariCP [1] shaded the > Javassist runtime classes in 2015 and still seems to be shading > Javassist. > > Good point about about the compatibility impact, as build time > instrumentation with the non-shaded Javassist will produce a Java > archive that doesn't work with the shaded Javassist. The application > will get a CNFE exception unless they add a dependency on the unshaded > Javassist classes. I would expect the same problem when we change > from using Javassist to using Byte Buddy. > > [1] > https://github.com/brettwooldridge/HikariCP/search?utf8=%E2%9C%93&q=javassist > > On Wed, Jan 11, 2017 at 11:48 AM, Emmanuel Bernard > <emman...@hibernate.org> wrote: >> The one small issue is that if the user enhanced the classes at build time >> (i,e. not via the ClassTransformer), then shading in a newer version of >> Wildfly means that the same app using the later version will fail unless you >> rebuild the app. >> BTW is Javassist Shadable, some of these libs can’t due to string >> referencing classnames and other fun tricks like that. >> >> Emmanuel >> >>> On 11 Jan 2017, at 17:35, Scott Marlow <smar...@redhat.com> wrote: >>> >>> On Wed, Jan 11, 2017 at 11:19 AM, Steve Ebersole <st...@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 <smar...@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@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
