Problem
In Karaf, the tika:parse operation returns empty content regardless of input, with no exception and no warning. The camel-tika feature installs and the route runs end-to-end, but nothing is ever extracted from the document.
Root cause
Camel's TikaProducer builds a new AutoDetectParser(TikaConfig). AutoDetectParser discovers org.apache.tika.parser.Parser implementations through the JDK ServiceLoader (META-INF/services/org.apache.tika.parser.Parser), which does not cross OSGi bundle boundaries. The parser implementations live in separate bundles (tika-parser-html-module, tika-parser-text-module, …) that the tika-core bundle's classloader cannot see, so AutoDetectParser finds no parser and falls back to EmptyParser → empty output.
Verified in a Pax Exam container: the route logs
Will parse: <html>...The quick brown fox...</html>
Parsed:
Adding the Karaf spifly feature to camel-tika alone does not fix it — the Tika parser-module bundles also need SPI-Provider wiring for SPIFly to register them.
Scope
This is a Karaf-specific OSGi integration gap in the camel-tika feature, separate from #713 (which only fixed the missing juniversalchardet transitive bundle so the parser modules resolve). The itest added in #716 deliberately does not assert on extracted content for this reason.
Possible directions
- Wrap the
tika-parser-* module bundles with the appropriate SPI-Provider / Require-Capability osgi.serviceloader clauses and add spifly to the feature so AutoDetectParser's ServiceLoader.load is mediated by SPIFly.
- Or provide an OSGi-aware
TikaConfig/parser wiring in camel-core-osgi / the camel-tika packaging.
Once resolved, the camel-tika itest can be tightened to assert on the extracted text.
Problem
In Karaf, the
tika:parseoperation returns empty content regardless of input, with no exception and no warning. Thecamel-tikafeature installs and the route runs end-to-end, but nothing is ever extracted from the document.Root cause
Camel's
TikaProducerbuilds anew AutoDetectParser(TikaConfig).AutoDetectParserdiscoversorg.apache.tika.parser.Parserimplementations through the JDKServiceLoader(META-INF/services/org.apache.tika.parser.Parser), which does not cross OSGi bundle boundaries. The parser implementations live in separate bundles (tika-parser-html-module,tika-parser-text-module, …) that thetika-corebundle's classloader cannot see, soAutoDetectParserfinds no parser and falls back toEmptyParser→ empty output.Verified in a Pax Exam container: the route logs
Adding the Karaf
spiflyfeature tocamel-tikaalone does not fix it — the Tika parser-module bundles also need SPI-Provider wiring for SPIFly to register them.Scope
This is a Karaf-specific OSGi integration gap in the
camel-tikafeature, separate from #713 (which only fixed the missingjuniversalchardettransitive bundle so the parser modules resolve). The itest added in #716 deliberately does not assert on extracted content for this reason.Possible directions
tika-parser-*module bundles with the appropriateSPI-Provider/Require-Capability osgi.serviceloaderclauses and addspiflyto the feature soAutoDetectParser'sServiceLoader.loadis mediated by SPIFly.TikaConfig/parser wiring incamel-core-osgi/ thecamel-tikapackaging.Once resolved, the
camel-tikaitest can be tightened to assert on the extracted text.