Re: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications...
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 <steve(a)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 <smarlow(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>