Major Description
Classes that implements the ZipContainerDetector interface are loaded via the ServiceLoader in the DefaultZipContainerDetector (in parsers-zip-commons).
In an OSGi enviroment the current behaviour is (default constructor) to only load classes that a found by the DefaultZipContainerDetector classloader, however this will miss ZipContainerDetector classes such as the OPCPackageDetector.java in the tika-parser-microsoft-module.
The DefaultZipConatinerDetector has constructor to pass a ServiceLoader, which in principle could allow loading of dynamic services. However, this constructor will load the services only on initialization, which does comply with the dynamic natur of an OSGi enviroment where services can come and go dynamically.
Linked to this issue is pull-request that attempts solve this issue following a similar strategy of service loading as implemented in the DefaultDetector and DefaultParser.
Attachments
Issue Links
- links to