3

As part of a web application i need to parse textual content of different incoming files. This should be quite simple using tika-parsers, but as soon as i try to deploy my webapp on Wildfly (tested V.8.2.1 and V.10.0.0.RC4) i run into problems.

This is my maven dependency in a very basic webapp:

<groupId>org.apache.tika</groupId>
<artifactId>tika-parsers</artifactId>
<version>1.11</version>

This is the error i get during deployment (manual deployment or using arquillian for testing):

Caused by: java.lang.Exception: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"backend-test.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"backend-test.war\".WeldStartService: Failed to start service
    Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000071: Managed bean with a parameterized bean class must be @Dependent: class org.apache.cxf.jaxrs.provider.SourceProvider"}}

I assume there is a dependency conflict, but have no clue on how to avoid it. beans.xml? jboss-deployment-structure.xml? Disable any wildfly modules?

Regards, Philipp

Philipp
  • 4,180
  • 7
  • 27
  • 41

2 Answers2

4

If anybody is still looking for this, you can just add this lines to your pom.xml:

<dependency>
    <groupId>org.apache.tika</groupId>
    <artifactId>tika-parsers</artifactId>
    <version>1.13</version>
    <exclusions>
        <exclusion>
            <groupId>org.apache.cxf</groupId>
            <artifactId>*</artifactId>
        </exclusion>
    </exclusions>
</dependency>
Paul Roub
  • 36,322
  • 27
  • 84
  • 93
Paulo Vilela
  • 41
  • 2
  • This solved it for me (although my dependency was actually "org.apache.tika:tika-java7:1.22"). I have not tried the other answer because this one seemed simpler. – SJuan76 Apr 29 '20 at 11:53
2

Besides the fact that Tika dumps a gigantic pile of questionable dependencies with a further mountain of very unwelcome transitive dependencies onto your runtime classpath, you are running into this issue:

http://weld.cdi-spec.org/documentation/#4

https://issues.jboss.org/browse/CDI-377

Basically it is an incompatibility issue in CDI 1.1 that has been resolved in CDI 1.2; manually updating Weld to version 2.3.x in Wildfly may take the problem away entirely.

Barring doing a manual upgrade, you can make the problem go away by declaring a META-INF/jboss-all.xml file with the following content. Assuming you have a war, the precise path is webapp/META-INF/jboss-all.xml.

<jboss xmlns="urn:jboss:1.0">
    <weld xmlns="urn:jboss:weld:1.0" require-bean-descriptor="true"/>
</jboss>

And make sure to define a WEB-INF/beans.xml file (again: assuming a war) in your own modules that need CDI support. This forces Weld to only try to configure modules which have a beans.xml file as part of them, which CXF will not.

Besides all that I would really investigate the dependency tree and see what is pulled in through Tika; for example you will find that the javax.inject API is put on the compile scope and thus deployed with your application, something you really do not want.

Gimby
  • 5,095
  • 2
  • 35
  • 47
  • 1
    Thanks! Adding the jboss-all.xml fixed the deploymen tissue! – Philipp Dec 22 '15 at 19:28
  • Argh! Now that the deployment is working, tika is giving me no content for e.g. pdf or office files. I think it is falling back to use the EmptyParser... I assume this is a side affect, as it show the same effect as when i was excluding an xcf dependency in my pom. – Philipp Dec 23 '15 at 08:55
  • @Philipp Sorry to hear that. But that's a different question. – Gimby Dec 23 '15 at 08:56