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

From: "Sanne Grinovero" <sanne(a)hibernate.org&gt; To: "Brett Meyer" <brmeyer(a)redhat.com&gt; Cc: "Hibernate.org" <hibernate-dev(a)lists.jboss.org&gt; Sent: Tuesday, June 2, 2015 4:52:31 AM Subject: Re: HSearch + Tika bridge using Wildfly modules On 2 June 2015 at 09:48, Sanne Grinovero <sanne(a)hibernate.org&gt; 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(a)redhat.com&gt; 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!