It would surprise me. We delegate to the ORM classloader, and
it's
well tested to load dependencies from the user module. My experience
with the jboss-deployment-structure XML file is more limited, I'd
rather suspect the dependency definition is not done correctly?
For example, I remember some users to mention on the forums that you'd
need to specify <sub-deployment> elements carefully depending on your
exact deployment structure:
https://developer.jboss.org/thread/248888?tstart=0#917815
But if you have just a WAR, I wouldn't expect that.. happy to help
debugging it? Could you share the exact stacktrace, or even better do
you have test?
Right, since this is a WAR and not an EAR, the sub-deployment discussion wouldn't be
applicable.
Stack:
https://gist.github.com/brmeyer/5bb39097d76d2e45d856
An isolated test case might be a bit tricky. But, I'm more than happy to package up
this specific WAR and demo what happens...
That's what we normally expect people to do, also the reason why
we
didn't have this optional dependency.
If I do not deploy the Tika module and instead explicitly include tika-core and
tika-parser JARs in my WAR, the same error occurs. Ditto if my specific JAR *provides*
the Tika dependencies. If what you're saying is true, where Search is leaning on the
WAR and Hibernate's classloaders, I'd assume one of those two would work, right?
Thanks!