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. On 03/28/2017 01:59 PM, Sanne Grinovero wrote: 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. 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. 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. Thanks, Sanne On 28 March 2017 at 17:32, Scott Marlow <smarlow(a)redhat.com&gt; <smarlow(a)redhat.com&gt; wrote: 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] https://issues.jboss.org/browse/WFLY-459 _______________________________________________ wildfly-dev mailing listwildfly-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev