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

[Brett Meyer]

Sanne, Artificer leans entirely on the ORM/Search modules available in Wildfly and EAP.  I can probably upgrade Search upstream, but I'd still need a workaround for EAP 6.4.  It sounds like using a Tika module and having Search's module explicitly import it is the only option, right?

----- Original Message -----
> From: "Sanne Grinovero" <sanne at hibernate.org>
> To: "Brett Meyer" <brmeyer at redhat.com>
> Cc: "Hibernate.org" <hibernate-dev at lists.jboss.org>
> 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 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!
>