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