[hibernate-dev] HSearch + Tika bridge using Wildfly modules

[Sanne Grinovero]

Hi Brett,
thanks for the stacktrace, that clarified a lot: looks like a problem
with our classloader strategy after all.

In BridgeFactory.doExtractType:592 we invoke "Class#newInstance()";
the Class itself is already found but then it fails to initialize it
as this isn't happening within the ORM classloader which we normally
use to create extension points via reflection.

I've created HSEARCH-1885 for this, I think I have enough elements to
try reproduce it in our tests.. if not I'll ask your help!

While I'll want to add a test for this, I'm not sure this still
applies to latest versions. If it's not too complex to try switching
versions, could you try that? You should upgrade anyway ;)

Thanks,
Sanne

On 2 June 2015 at 03:27, Brett Meyer <brmeyer at redhat.com> wrote:
>> 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!