[wildfly-dev] private packaging Javassist jar in Hibernate ORM, so applications can have their own Javassist jar...

Scott Marlow smarlow at redhat.com
Fri Feb 19 12:41:35 EST 2016


On 02/18/2016 06:11 AM, Sanne Grinovero wrote:
> It seems we're discussing this issue in multiple places,
> so to let you all know I'll repeat it hare:

I don't really like discussing the same issue on multiple lists but I 
thought it made sense to ask here for further input (especially since I 
would like to create a PR for the updated ORM that solves this problem 
and having some buy in now that the PR will get merged, is helpful). :)

> I think shading is a really really bad idea :)
>
> Could we try to have the enhanced entities to not need Javassist in in
> their *direct* classloader; we can still have a normal Javassist as a
> module dependency of Hibernate?
> That would require to just make sure the generated bytecode doesn't
> directly refer to Javassist types but uses an indirection controlled
> by Hibernate code.. which in turn can use Javassist or even
> alternatives in future, if we'd like to experiment.
>
> I'm not familiar enough with Javassist to know if that's an option
> as-is but we can either improve Javassist to allow such a thing or use
> some alternatives, like Gunnar and Hardy also suggested on the
> hibernate-dev mailing list.
>
> To summarize, I agree with Stuart and would hope that Scott's branch
> can be improved by minimizing the amount of Javassist code which
> actually needs to be copied by using some simple delegation to
> Hibernte types, which in turn can use a private, non-shaded Javassist
> taking advantage of the isolation provided by JBoss Modules.

 From a timing point of view, it seems to me that it will likely take a 
while before a future release of Hibernate ORM addresses this.  If I am 
wrong about that, great.  But, I think that leaves the following options 
for WildFly 10.1.0 and the proposed pr [1]:

A. Remove the private API label from the WildFly javassist static module 
so that Hibernate native applications can depend on Javassist without 
fear that their application may fail to deploy in the future because of 
the Javassist dependency.

B.  Stick with the current [1] hack of exporting the Javassist 
dependency to applications that have a dependency on the Hibernate ORM 
module.

Scott

[1] https://github.com/wildfly/wildfly/pull/8474 which has a sad "fix 
me" label.


More information about the wildfly-dev mailing list