[wildfly-dev] Could WildFly automatically detect Hibernate native applications and auto add Hibernate dependencies to the application classpath...

[Scott Marlow]

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 at redhat.com>
<smarlow at redhat.com> 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 at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170329/55664c64/attachment-0001.html