Sanne, I might still be missing something. Artificer's war does not include any Hibernate ORM, Hibernate Search, or Tika jars. For Wildfly 8.2, the war's jboss-deployment-structure.xml includes: <module name="org.hibernate.search.orm" /> (includes tika-parsers-1.6.jar) <module name="org.apache.tika" slot="1.6"/> (Also using the org.hibernate module, but that's implicitly added by Wildfly.) I understand what you're saying about the ORM classloader, but the above still didn't work. I'm admittedly a little fuzzy on WF module classloading, but I'm wondering if that's not actually making its way into the ORM classloader, even though my war is the persistence unit. However: What *does* work is adding '<module name="org.apache.tika" slot="1.6"/>' directly in org.hibernate.search.engine's module.xml. Apologies if 1.) I'm missing something and/or 2.) that's expected. I can certainly tweak org.hibernate.search.engine's module.xml with our installer, but that's obviously less than desirable. Any idea what we might be missing that would allow us to get that to work from the app itself? Thanks for the help! ----- Original Message ----- > 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: Friday, May 29, 2015 11:00:12 AM > Subject: Re: HSearch + Tika bridge using Wildfly modules > > Hi Brett, > we don't include all existing analysers and extensions within the > WildFly modules. In particular the Apache Tika libraries have a huge > amount of dependencies, you should choose the ones you need depending > on what kind of media you intend to parse. > > Include any extension in your "application", we use the Hibernate ORM > classloader to lookup for extensions so these should be discoverable > if they are visible to the same classloader having your entities and > other extensions. > > Sanne > > On 29 May 2015 at 15:28, Brett Meyer <brmeyer(a)redhat.com&gt; wrote: > > Hey Sanne! Artificer has '<module name="org.hibernate.search.orm" > > services="export" />' defined in its jboss-deployment-structure > > dependencies. But, when we try to use it, the following happens. > > > > Caused by: java.lang.ClassNotFoundException: org.apache.tika.parser.Parser > > from [Module "org.hibernate.search.engine:main" from local module loader > > @6cf76647 (finder: local module finder @665bf734 (roots: > > /home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules,/home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules/system/layers/base))] > > > > One of our entities uses the built-in TikaBridge. I figured the search.orm > > module would bring the necessary Tika jars in with it. Is there something > > else we need to add? >

Sanne, right, I tried that as well -- makes sense in theory. jboss-deployment-structure: <module name="org.hibernate.search.orm" services="export" /> <module name="org.apache.tika" slot="1.6" export="true" /> However, I still hit the same error. The *only* way I can get it to work is to directly add the Tika module to org.hibernate.search.engine's module.xml. Think there could be a larger classloading issue?

This is even more worrisome for EAP 6.4, where there is no Tika module. I'll need to include the jars in our war, and have Search pick those up.

----- Original Message ----- > 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: Monday, June 1, 2015 10:58:44 AM > Subject: Re: HSearch + Tika bridge using Wildfly modules > > Hi Brett, > with that configuration, your application is depending on the Tika > module but since module dependencies are not transitive, and Hibernate > ORM (and thus Search) depend on your WAR, they don't get access to the > Tika dependencies. > > I see two options: > - you have your deployment-structure declare that you export the Tika module > - we patch the hibernate-search-engine module to depend on an > optional tika module (w/o including it) > > I think we should do both, the first to get you going until our > improved modules are available, and the second as it's correct to > state that we optionally benefit from it. > > https://hibernate.atlassian.net/browse/HSEARCH-1883 > Is there some way I could easily fetch your definition of the tika > modules to include that in our integration tests? > > Thanks, > Sanne > > On 30 May 2015 at 04:36, Brett Meyer <brmeyer(a)redhat.com&gt; wrote: > > Sanne, I might still be missing something. Artificer's war does not > > include any Hibernate ORM, Hibernate Search, or Tika jars. For Wildfly > > 8.2, the war's jboss-deployment-structure.xml includes: > > > > <module name="org.hibernate.search.orm" /> (includes tika-parsers-1.6.jar) > > <module name="org.apache.tika" slot="1.6"/> > > (Also using the org.hibernate module, but that's implicitly added by > > Wildfly.) > > > > I understand what you're saying about the ORM classloader, but the above > > still didn't work. I'm admittedly a little fuzzy on WF module > > classloading, but I'm wondering if that's not actually making its way into > > the ORM classloader, even though my war is the persistence unit. > > > > However: > > > > What *does* work is adding '<module name="org.apache.tika" slot="1.6"/>' > > directly in org.hibernate.search.engine's module.xml. > > > > Apologies if 1.) I'm missing something and/or 2.) that's expected. I can > > certainly tweak org.hibernate.search.engine's module.xml with our > > installer, but that's obviously less than desirable. Any idea what we > > might be missing that would allow us to get that to work from the app > > itself? > > > > Thanks for the help! > > > > ----- Original Message ----- > >> 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: Friday, May 29, 2015 11:00:12 AM > >> Subject: Re: HSearch + Tika bridge using Wildfly modules > >> > >> Hi Brett, > >> we don't include all existing analysers and extensions within the > >> WildFly modules. In particular the Apache Tika libraries have a huge > >> amount of dependencies, you should choose the ones you need depending > >> on what kind of media you intend to parse. > >> > >> Include any extension in your "application", we use the Hibernate ORM > >> classloader to lookup for extensions so these should be discoverable > >> if they are visible to the same classloader having your entities and > >> other extensions. > >> > >> Sanne > >> > >> On 29 May 2015 at 15:28, Brett Meyer <brmeyer(a)redhat.com&gt; wrote: > >> > Hey Sanne! Artificer has '<module name="org.hibernate.search.orm" > >> > services="export" />' defined in its jboss-deployment-structure > >> > dependencies. But, when we try to use it, the following happens. > >> > > >> > Caused by: java.lang.ClassNotFoundException: > >> > org.apache.tika.parser.Parser > >> > from [Module "org.hibernate.search.engine:main" from local module loader > >> > @6cf76647 (finder: local module finder @665bf734 (roots: > >> > /home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules,/home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules/system/layers/base))] > >> > > >> > One of our entities uses the built-in TikaBridge. I figured the > >> > search.orm > >> > module would bring the necessary Tika jars in with it. Is there > >> > something > >> > else we need to add? > >> >

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

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!