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