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

[Scott Marlow]

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 at redhat.com>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?

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 at redhat.com>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
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>