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" <sa...@hibernate.org> > To: "Brett Meyer" <brme...@redhat.com> > Cc: "Hibernate.org" <hibernate-dev@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 <sa...@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 <brme...@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! > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
