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
