On 02/03/2016 10:11 AM, Scott Marlow wrote: > > On 02/03/2016 09:01 AM, Steve Ebersole wrote: >> I should point out... The big drawback with that (and with cloning in >> general since its the Javassist package renaming that is important in >> both) is that its no longer a simple matter update (bug-fixes, etc) >> Javassist usage in Hibernate. Its certainly no longer simple as in >> drop-in the replacement from upstream. > > True, many users like to workaround Javassist issues by dropping a > different Javassist version in.
My vote is to change Hibernate to include its own Hibernate-Javassist (shaded or whatever repackaging tricks are needed) jar. Some recent cases that I have heard of users needing to use a different version of Javassist with Hibernate were: A. On certain application servers that included an older Javassist jar that an upgraded Hibernate ORM release was not compatible with the older Javassist jar. With a shaded Hibernate-javassist jar, we wouldn't have any conflicts between the Hibernate use of Javassist and the javassist.jar file (since users would have a separate global hibernate-javassist jar). B. Users needing to use some later release of Javassist to address a bug that they experienced with Hibernate's use of Javassist. I think that these users will need to upgrade to a later version of Hibernate to use the newer Javassist. Scott > >> >> On Wed, Feb 3, 2016 at 7:58 AM Steve Ebersole <st...@hibernate.org >> <mailto:st...@hibernate.org>> wrote: >> >> Just as a suggestion, we do not need to go to a "full on" clone for >> your (1). A fat-jar, shaded-jar, <your favorite plugin here> should >> also do the trick. >> >> >> On Wed, Feb 3, 2016 at 7:54 AM Scott Marlow <smar...@redhat.com >> <mailto:smar...@redhat.com>> wrote: >> >> As modular classloading environments become more popular (e.g. >> WildFly, >> OSGi, Openjdk Jigsaw), it is more important that applications can >> include their own version of Javassist classes. This is not >> possible if >> the application classpath also needs to include the Hibernate >> (needed) >> version of Javassist. >> >> My question is how would/should this be accomplished? Some >> proposals >> are below: >> >> 1. Clone the Javassist runtime classes into Hibernate ORM and >> maintain >> them as a fork. I don't think this is practical but still wanted to >> mention it as a possible solution. >> >> 2. Stop using the parts of the Javassist api that generate bytecode >> that depends on the Javassist runtime classes. I have no idea >> how hard >> this would be. >> >> I don't think we have a jira for this yet, although we have >> talked about >> it occasionally for years. >> >> Any volunteers to help? >> >> Scott >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org <mailto: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
