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

[Fernando Nasser]

On 2016-02-11 2:55 PM, Stuart Douglas wrote:
>
>
> On Fri, 12 Feb 2016 at 06:42 James Perkins <jperkins at redhat.com 
> <mailto:jperkins at redhat.com>> wrote:
>
>     I don't recall the previous discussion, but is there a reason we
>     couldn't just use a JBoss module with a different slot?
>
>
> Nah, the issue is that these classes need to be referenced by the 
> deployment and hibernate, so whatever version hibernate uses has to be 
> the one exposed to the deployment.
Can't we require that that alternative module is specified as a 
dependency for the hibernate deployments?

It does put the onus on the user but we already end up having to specify 
a few things for hibernate anyway.

Fernando


>
> Stuart
>
>
>     On Thu, Feb 11, 2016 at 8:03 AM, Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>> wrote:
>
>         As previously discussed, Hibernate applications need access to the
>         Javassist runtime classes (see example [1] enhanced
>         application entity
>         if you didn't know this :).  A proposal was discussed on the
>         hibernate-dev mailing list that I think is the best short term
>         solution.
>           I wanted to raise this issue here also, as I would like to later
>         create a pull request to bring in a new Hibernate ORM that
>         includes this
>         change.  So, getting early feedback before we create JIRAs for
>         the work,
>         is important.
>
>         The proposal is to private package (or shade), the Javassist
>         classes, so
>         that Hibernate ORM has its own copy of the Javassist classes.  On
>         WildFly, we still would include Javassist for the other
>         components that
>         use it and for Hibernate applications that have "build-time
>         enhanced
>         entity classes" by an earlier Hibernate release.
>
>         One downside of this change is that Hibernate applications
>         cannot easily
>         switch to a different version of the Javassist classes.
>
>         Another downside is that applications that depend on an older
>         Hibernate
>         ORM version that includes "build-time enhanced entity
>         classes", will
>         need to be cracked open, to add dependencies on the Javassist
>         module
>         (since we will stop automatically adding Javassist to JPA
>         application
>         deployments).
>
>         The advantage of this change, is that Hibernate applications
>         can include
>         their own version of Javassist.
>
>         This will also have an impact on Hibernate build-time enhancing of
>         entity classes (e.g. enhanced bytecode will no longer depend
>         on the
>         public Javassist classes).
>
>         Scott
>
>         [1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>         _______________________________________________
>         wildfly-dev mailing list
>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>     -- 
>     James R. Perkins
>     JBoss by Red Hat
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160211/8b91eca8/attachment.html