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.
On Wed, Feb 3, 2016 at 7:58 AM Steve Ebersole <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> 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 >> 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
