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

[Sanne Grinovero]

On 2 June 2015 at 09:48, Sanne Grinovero <sanne at hibernate.org> wrote:
> 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 ;)

Actually: while I still think you should upgrade, it looks like the
issue would apply on latest as well.

Sanne

>
> 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!