Re: [wildfly-dev] JPADependencyProcessor "infecting" classpath with the wrong Javassist version

Hi Stuart, On 15 January 2017 at 22:23, Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; wrote: > Is there any reason why we can't update to the latest version of Javassist? Sure we can update Javassist as well, as long as we pick a version which is compatible with the (slightly old) version of Hibernate ORM included in WildFly. This might require a backport of the Javassist upgrade to the older stable branch of Hibernate ORM and a new release though, so I'd treat it as an orthogonal issue especially as such a plan would require its own set of approvers. > I know this does not prevent similar issues in future, but we should > probably be using the most recent version if there is no reason not to. Right, but bear with me the "not prevent similar issues in future" is crucial to my problem here. We need to regularly test next-gen Hibernate ORM while we work on it: we want to have ci.hibernate.org run the WildFly integration tests on each commit of Hibernate ORM, so upgrading Javassist - or any other dependency - is an event which might happen multiple times a week and we don't want to wait for a WildFly release each time this is needed. It's really about controlling our own dependencies, to keep development quick and practical. > My issue with https://github.com/wildfly/wildfly/pull/8474 is that in > general we should not be using export="true", as it makes it impossible to > exclude the dependency using jboss-deployment-structure.xml. As a result I > don't really see how this PR is an improvement, as it goes from the > javassist deployment being added directly to the deployment to it being > added indirectly via an export. Interesting point, I hadn't thought about users of jboss-deployment-structure.xml. But still, anyone making use of `org.hibernate:main` (as it is today) will strictly require to have `org.javassist:main` on their classpath, so one will not want to exclude it; while people using say `org.hibernate:5.2.6.Final` will definitely not want `org.javassist:main` on their classpath as it will cause subtle problems. In short, it's not a grey area but it's very clear when it's required or not and we can automate this decision. So I think the modules definitions of each `org.hibernate:xyz` module should point to the right instance of the javassist module, rather than force the users to craft an appropriate structure xml file to amend for our bad choices? I guess it is currently important for people to be able to exclude `org.javassist` because it's being injected aggressively, for example your apps get "infected" by javassist even if you want to use a different JPA implementation which has no business at all with Javassist. On the other hand, I don't think we can support Hibernate users who simply disable the right version of javassist using the deployment structure, so if someone really wants to exclude org.javassist:main I would suggest them to edit the module file of ORM, or better yet use their own (and self-supported) ORM module. By moving it to the static definition of the module, at least I have the option to use my own set of Hibernate ORM modules and choose an updated Javassist slot. Hibernate ORM also has the option to use Byte Buddy now as an alternative to Javassist; when using the new alternative enhancer one might also want to get rid of the Javassist dependency altogether, which power users can achieve by editing their own module, or using the "next-gen" modules we regularly provide with each Hibernate release. Fixing the JPADependencyProcessor would make it easy for people to use newer modules by just layering the new edition. Thanks, Sanne > > Stuart > > On Fri, Jan 13, 2017 at 11:03 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; > wrote: >> >> Hi all, >> >> Scott sent a nice PR to Wildfly a while back to fix the problem: >> - https://github.com/wildfly/wildfly/pull/9305 >> >> It wasn't merged, I guess it's not a priority for WildFly but let me >> clarify that without such fixes it's impossible for people to use >> newer versions of Hibernate ORM on WildFly, and I suspect lots of pain >> as well for other libraries using Javassist. >> >> There's quite some people in the Hibernate community who expressed >> interest in using a not-so-stale version as the one which is typically >> available in the latest stable release of WildFly. >> >> To make this happen, all Hibernate projects are now publishing >> "WildFly modules" which can be easily downloaded as additional drop-in >> layer. >> Granted these are not for everyone but we get good feedback from the >> power users interested, and not least this allows us to develop all >> our projects while regularly testing integration with WildFly, making >> sure that the eventual integration goes smoother. >> >> The current problem is that the WildFly JPADependencyProcessor adds >> the wrong version of javassist to the deployments, and there's no way >> for us to prevent this or override this, making it impossible to use a >> recent version of Hibernate ORM as it requires a newer version. >> - >> https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af... >> >> We'd highly appreciate if that PR could be merged? Including on >> product branches please, as enforcing a dependency which is neither >> needed nor desired is going to break a long list of other frameworks >> as well. >> >> Thanks, >> Sanne >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >