<div dir="ltr"><div dir="auto"><div bgcolor="#FFFFFF">I wonder if it would be possible to integrate the jboss-deployment-structure.xml module exclusion checking, into our modular classloader, so that we could do the exclude when Hibernate ORM exports Javassist? Then, I think that Hibernate ORM could safely export the Javassist module dependency to the application deployment. The next best thing, might be some way to fail the deployment if the application jboss-deployment-structure.xml tries to exclude javassist. </div><div bgcolor="#FFFFFF">
<br>
<div class="gmail-m_-3197033220577042185m_9060982997921627553moz-cite-prefix">On 03/28/2017 01:59 PM, Sanne Grinovero
wrote:<br>
</div>
<blockquote type="cite">
<pre>Thanks Scott for reviving the subject.
Let me remind that an application wishing to use `org.hibernate:main`
without Javassist won't work.. so I don't see why "being able to
exclude it" is a realistic use case.</pre>
</blockquote>
<br>
True, users should
use the same version of Javassist (with Hibernate), that we include with WildFly (IMO), however, it is still possible that a user could do try to do that.<br>
<br><blockquote type="cite"><pre>On the other hand, moving the "automatic inclusion" currently handled
by the JPA subsystem into an explicit dependency of the ORM module
allows us to finally get rid of this need for Javassist in the near
future.</pre>
</blockquote>
<blockquote type="cite"><pre>Thanks,
Sanne
On 28 March 2017 at 17:32, Scott Marlow <a class="gmail-m_-3197033220577042185m_9060982997921627553moz-txt-link-rfc2396E" href="mailto:smarlow@redhat.com" target="_blank"><smarlow@redhat.com></a> wrote:
</pre>
<blockquote type="cite">
<pre>Hibernate native applications that are deployed on WildFly, need the
application classpath to include org.hibernate:main + org.javassist:main
static modules. We proposed via WFLY-459 [1], that the Hibernate ORM
module should export the javassist module but that is not overrideable
by applications (since module exclusions are ignored for export=true
modules).
Another approach could be adding a (tattletale like?) deployment unit
processor to WildFly, that could scan through application classes,
without loading them, to check for references to certain Hibernate
classes, like "org.hibernate.Session". Would that introduce too much
overhead to deployment? If we did this scanning, we would have to scan
through all application classes to verify that the application doesn't
already depend on a Hibernate static module or include its own copy of
Hibernate classes.
Perhaps an alternative could be a wildflySomething.xml way to indicate
that a deployment is a Hibernate native application and that
Hibernate/Javassist dependencies should be auto added.
What do you think?
Scott
[1] <a class="gmail-m_-3197033220577042185m_9060982997921627553moz-txt-link-freetext" href="https://issues.jboss.org/browse/WFLY-459" target="_blank">https://issues.jboss.org/brows<wbr>e/WFLY-459</a>
______________________________<wbr>_________________
wildfly-dev mailing list
<a class="gmail-m_-3197033220577042185m_9060982997921627553moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>
<a class="gmail-m_-3197033220577042185m_9060982997921627553moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/wildfly-dev</a>
</pre>
</blockquote>
</blockquote>
<br>
</div></div>
</div>