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
