2:29 p.m.
On 02/11/2016 02:59 PM, Fernando Nasser wrote:
On 2016-02-11 2:55 PM, Stuart Douglas wrote:
>
>
> On Fri, 12 Feb 2016 at 06:42 James Perkins
> <<mailto:jperkins@redhat.com>jperkins@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?
The Javassist module is marked as private api, so applications are
discouraged from depending on it. They certainly can but they get a
warning that the dependency might go away in the future (which means the
app might not deploy in the future).
It does put the onus on the user but we already end up having to specify
a few things for hibernate anyway.
For native Hibernate api applications, they currently have to add a
dependency on Javassist. For EE JPA container managed applications, we
automatically add a dependency on Javassist for them.
Fernando
>
> Stuart
>
>
> On Thu, Feb 11, 2016 at 8:03 AM, Scott Marlow
> <<mailto:smarlow@redhat.com>smarlow@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev