On 3 February 2016 at 14:55, Emmanuel Bernard <emman...@hibernate.org> wrote: > 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.
I get that. But *which classpath* matters. Classes are owned by a specific classloader, and the instrumented code can depend on javassist w/o this requiring the whole of the user code's classloader to include javassist. So I'm not saying that I definitely know how to solve it, but I think it should be possible.. details matter and I don't have them. For the record, people should be able to use JPA in WildFly without being able to see any org.hibernate class too. Sanne > > 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
