[hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications...
sanne at hibernate.org
Wed Feb 3 09:02:32 EST 2016
I'm missing something here: I think there is a 3rd option which is to
not require the user's classpath to "see" the Javassist at all, even
though Hibernate uses it.
But I've said this before in other context, and yet we're back at
discussing only options 1 and 2, so I'm guessing that we either didn't
understand each other, or I'm missing some complexity in the use case
(I haven't seen the code!).
To make progress I think I could try to help out with a proposal, but
I can only do that if you could share a unit test. What do you think
Of course there's the possibility that I'd give you a solution which
is valid only in the specific use case of that single test, but at
least it might clarify to you what I have in mind..
an example worth more than a 1000 emails :)
On 3 February 2016 at 13:53, Scott Marlow <smarlow at 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?
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
More information about the hibernate-dev