2:53 p.m.
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
2:58 p.m.
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> 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
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:01 p.m.
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.
On Wed, Feb 3, 2016 at 7:58 AM Steve Ebersole <steve(a)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> 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
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
4:11 p.m.
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
4:24 p.m.
Perhaps check if the Classfilewriter is any better in this concern — it might not need any
own classes in proxies.
* https://github.com/jbossas/jboss-classfilewriter
<https://github.com/jbossas/jboss-classfilewriter>
(Weld now uses this — it’s part of WildFly)
But this means you would have to write a new Hibernate proxier.
(if you don’t have it already)
On 03 Feb 2016, at 16:11, Scott Marlow <smarlow(a)redhat.com>
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.
3:44 p.m.
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
3:02 p.m.
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 <smarlow(a)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
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:55 p.m.
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 <smarlow(a)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
> 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
4:08 p.m.
Hi,
If the user has used bytecode enhancement, the generated transformed entity
classes depend on Javassist too,
and that's even more complicated because it requires the client to
regenerate those classes if we drop support for Javassist.
Vlad
On Wed, Feb 3, 2016 at 4:55 PM, Emmanuel Bernard <emmanuel(a)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.
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 <smarlow(a)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
> > 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
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:09 p.m.
On 3 February 2016 at 14:55, Emmanuel Bernard <emmanuel(a)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 <smarlow(a)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
> > 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
4:27 p.m.
On 02/03/2016 10:09 AM, Sanne Grinovero wrote:
On 3 February 2016 at 14:55, Emmanuel Bernard
<emmanuel(a)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.
The user application code, does need javassist. Look at
https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e which is an
example of user code needing 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.
I think that I responded to your previous comments on my WildFly pull
request being wrong, since I exported the Javassist classes with
Hibernate ORM (so that Hibernate native applications would not get a
CNFE). I suspect that the details are too long to read or perhaps I was
not clear on that thread. But, my pull request was pretty much shot
down so far because Hibernate applications should not be required to
have Javassist on the application classpath, as that could conflict with
applications that want their own copy of Javassist.
For the record, people should be able to use JPA in WildFly without
being able to see any org.hibernate class too.
Are you saying that only JPA applications that contain a reference to a
org.hibernate class should have the Hibernate classes on the application
classpath? Or that the Hibernate runtime should not ever expect to find
Hibernate classes on the application classpath?
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 <smarlow(a)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
>>> 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
4:42 p.m.
On Wed, 2016-02-03 at 15:09 +0000, Sanne Grinovero wrote:
For the record, people should be able to use JPA in WildFly without
being able to see any org.hibernate class too.
The background of the request/issue was a ClassNotFoundException when
using the bundled Hibernate in an application leveraging the "native
Hibernate" API (not using JPA).
When using JPA, the issue did not occur.
This may suggest a solution?
4:52 p.m.
On 02/03/2016 10:42 AM, Stephen Fikes wrote:
On Wed, 2016-02-03 at 15:09 +0000, Sanne Grinovero wrote:
> For the record, people should be able to use JPA in WildFly without
> being able to see any org.hibernate class too.
The background of the request/issue was a ClassNotFoundException when
using the bundled Hibernate in an application leveraging the "native
Hibernate" API (not using JPA).
When using JPA, the issue did not occur.
This may suggest a solution?
The WildFly/AS7 JPA container/deployer automatically adds the Hibernate
ORM module to the application classpath. However, this doesn't help
Hibernate native applications.
With OSGi, there is no automatic solution, applications are expected to
add Javassist to the application classpath.
In other environments, Hibernate applications also need Javassist on the
classpath but the other environments are more likely to add Hibernate +
Javassist jars to their global classpath.
No silver bullet here.
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:04 p.m.
On 02/03/2016 10:52 AM, Scott Marlow wrote:
On 02/03/2016 10:42 AM, Stephen Fikes wrote:
> On Wed, 2016-02-03 at 15:09 +0000, Sanne Grinovero wrote:
>> For the record, people should be able to use JPA in WildFly without
>> being able to see any org.hibernate class too.
>
> The background of the request/issue was a ClassNotFoundException when
> using the bundled Hibernate in an application leveraging the "native
> Hibernate" API (not using JPA).
>
> When using JPA, the issue did not occur.
>
> This may suggest a solution?
The WildFly/AS7 JPA container/deployer automatically adds the Hibernate
ORM module to the application classpath. However, this doesn't help
Hibernate native applications.
The WildFly/AS7 JPA container/deployer also adds the Javassist module to
the application classpath as well.
With OSGi, there is no automatic solution, applications are expected to
add Javassist to the application classpath.
In other environments, Hibernate applications also need Javassist on the
classpath but the other environments are more likely to add Hibernate +
Javassist jars to their global classpath.
No silver bullet here.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)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
8:07 p.m.
https://hibernate.atlassian.net/browse/HHH-10536 is for tracking this.
Please revise as it makes sense.
In the related WildFly dev discussion about $subject, Stuart asked if we
would have two separate Hibernate ORM jars (one that depends on the
shaded Javassist and one that depends on regular Javassist). That seems
like a separate concern but perhaps others will feel stronger about it.
Also, in the WildFly discussion, I asked whether it makes a difference
to Hibernate, whether the javassist.util.proxy classes that we want to
shade, are in the javassist.jar or a new javassist-runtime.jar? If we
shade all of the classes in a javassist-runtime.jar, that might be a
better long term contract, then if we shaded the javassist.util.proxy
classes which could be renamed over time. Does it make a difference
whether we shade the javassist.util.proxy or entire javassist-runtime.jar?
Thanks,
Scott
1:15 p.m.
Hi,
I'd like to propose an alternative approach for proxy generation which
would avoid version issues with Javassist.
The idea is to generate proxies which are fully "self-contained", i.e.
their byte code contains no references to a library such as Javassist,
but instead invocations of a either a custom method handler contract
we define ourselves or something unproblematic such as
java.lang.reflect.InvocationHandler.
Such code generation could be done "by hand" using ASM, but there is a
handy library named ByteBuddy [1] which essentially provides a nice
DSL for creating types at runtime (it sits on top of ASM itself). It
makes it very easy to create proxy classes which call out to an
instance of InvocationHandler when the proxied methods are called.
Note that it enables the usage of InvocationHandler not only for
interfaces (such as the original usage in the JDK) but also for class
proxies.
The code generated for proxies does not contain any references to
ButeBuddy's API, i.e. after creation they are usable without ByteBuddy
being available (*). That way ByteBuddy should not have to be exposed
to user deployments, unlike with the current Javassist solution. It'd
only be a tool used *internally* within Hibernate.
I've pushed a very rough draft of that approach to my fork of ORM at
https://github.com/hibernate/hibernate-orm/commit/0b1739059b74aaab7d3aa91....
It's not complete and some tests fail. I'd need to look into these in
more depth, but I don't think they represent general problems. But
this sketch might be good enough already to be dropped into WildFly
and run some tests.
Any feedback welcome.
Cheers,
--Gunnar
[1] bytebuddy.net/
(*) I could serialize a generated proxy to disk and re-read+execute it
subsequently from another application without ByteBuddy on the
classpath
2016-02-16 20:07 GMT+01:00 Scott Marlow <smarlow(a)redhat.com>:
https://hibernate.atlassian.net/browse/HHH-10536 is for tracking
this.
Please revise as it makes sense.
In the related WildFly dev discussion about $subject, Stuart asked if we
would have two separate Hibernate ORM jars (one that depends on the
shaded Javassist and one that depends on regular Javassist). That seems
like a separate concern but perhaps others will feel stronger about it.
Also, in the WildFly discussion, I asked whether it makes a difference
to Hibernate, whether the javassist.util.proxy classes that we want to
shade, are in the javassist.jar or a new javassist-runtime.jar? If we
shade all of the classes in a javassist-runtime.jar, that might be a
better long term contract, then if we shaded the javassist.util.proxy
classes which could be renamed over time. Does it make a difference
whether we shade the javassist.util.proxy or entire javassist-runtime.jar?
Thanks,
Scott
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:20 p.m.
+1
Avoiding a runtime dependency seems far better than shading. Maybe the same
could be done with Javassist?
On Wed, 17 Feb 2016 12:15 Gunnar Morling <gunnar(a)hibernate.org> wrote:
Hi,
I'd like to propose an alternative approach for proxy generation which
would avoid version issues with Javassist.
The idea is to generate proxies which are fully "self-contained", i.e.
their byte code contains no references to a library such as Javassist,
but instead invocations of a either a custom method handler contract
we define ourselves or something unproblematic such as
java.lang.reflect.InvocationHandler.
Such code generation could be done "by hand" using ASM, but there is a
handy library named ByteBuddy [1] which essentially provides a nice
DSL for creating types at runtime (it sits on top of ASM itself). It
makes it very easy to create proxy classes which call out to an
instance of InvocationHandler when the proxied methods are called.
Note that it enables the usage of InvocationHandler not only for
interfaces (such as the original usage in the JDK) but also for class
proxies.
The code generated for proxies does not contain any references to
ButeBuddy's API, i.e. after creation they are usable without ByteBuddy
being available (*). That way ByteBuddy should not have to be exposed
to user deployments, unlike with the current Javassist solution. It'd
only be a tool used *internally* within Hibernate.
I've pushed a very rough draft of that approach to my fork of ORM at
https://github.com/hibernate/hibernate-orm/commit/0b1739059b74aaab7d3aa91...
.
It's not complete and some tests fail. I'd need to look into these in
more depth, but I don't think they represent general problems. But
this sketch might be good enough already to be dropped into WildFly
and run some tests.
Any feedback welcome.
Cheers,
--Gunnar
[1] bytebuddy.net/
(*) I could serialize a generated proxy to disk and re-read+execute it
subsequently from another application without ByteBuddy on the
classpath
2016-02-16 20:07 GMT+01:00 Scott Marlow <smarlow(a)redhat.com>:
> https://hibernate.atlassian.net/browse/HHH-10536 is for tracking this.
> Please revise as it makes sense.
>
> In the related WildFly dev discussion about $subject, Stuart asked if we
> would have two separate Hibernate ORM jars (one that depends on the
> shaded Javassist and one that depends on regular Javassist). That seems
> like a separate concern but perhaps others will feel stronger about it.
>
> Also, in the WildFly discussion, I asked whether it makes a difference
> to Hibernate, whether the javassist.util.proxy classes that we want to
> shade, are in the javassist.jar or a new javassist-runtime.jar? If we
> shade all of the classes in a javassist-runtime.jar, that might be a
> better long term contract, then if we shaded the javassist.util.proxy
> classes which could be renamed over time. Does it make a difference
> whether we shade the javassist.util.proxy or entire
javassist-runtime.jar?
>
> Thanks,
> Scott
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)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
2:45 p.m.
Hi,
I'd like to propose an alternative approach for proxy generation
which
would avoid version issues with Javassist.
The idea is to generate proxies which are fully "self-contained", i.e.
their byte code contains no references to a library such as Javassist,
but instead invocations of a either a custom method handler contract
we define ourselves or something unproblematic such as
java.lang.reflect.InvocationHandler.
+1 Great idea. I used ByteBuddy as well a bit and I think it is a good library.
--Hardy
2991
days inactive
3005
days old
17 comments
9 participants
participants (9)
-
Ales Justin -
Emmanuel Bernard -
Gunnar Morling -
Hardy Ferentschik -
Sanne Grinovero -
Scott Marlow -
Stephen Fikes -
Steve Ebersole -
Vlad Mihalcea