Sanne, proxies generated by Hibernate do depend on the Javassist code at runtime. So a lazy object would CNFE if Javassist was not in the classpath.
On Wed 2016-02-03 14:02, Sanne Grinovero wrote: > Hi Scott, > 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 that? > 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 :) > > Thanks! > Sanne > > On 3 February 2016 at 13:53, 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
