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.
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