[
https://issues.apache.org/jira/browse/STANBOL-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13618279#comment-13618279
]
Rupert Westenthaler commented on STANBOL-1000:
----------------------------------------------
Hi Tommaso
After the failing integration tests on Jenkins I took an other look at Solr 4
resource loading and discovered that now a SPI like mechanism is used for
Analyzers. This means that "META-INF/services" are used to locate
CharFilterFactory, TokenizerFactory and TokenFilterFactory instances.
This means that splitting up such implementations in different bundles will not
work, because "META-INF/services" files can only be loaded from the current
bundle (the o.a.stanbol.commons.solr.core module).
This is also the reason why with the seperation of the ICU analyzers to the new
module
Caused by: java.lang.ClassNotFoundException: solr.ICUTokenizerFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
[..]
appear in the log.
The only possibility I can think of is replacing the whole Infrastructure with
one compatible to OSGI. This would mean to
* write an BundleActivator for all solr modules that searches for according
"META-INF/services" and registers them with the OSGI service factory.
* replace the default ServiceLoader with an OSGI on that uses the
ServiceFactory instead of SPI to find CharFilterFactory, TokenizerFactory or
TokenFilterFactory instances based on the values configured in the schema.xml.
While those changes would allow a much better integration of Solr with OSGI
they would also require considerable changes (and extensions) to the
commons.solr.core module. Because of that I suggest to go - at least for now -
with your first solution - to define the import statements for ICU as optional.
WDYT
> Missing OSGi configuration for updated Solr commons core
> --------------------------------------------------------
>
> Key: STANBOL-1000
> URL: https://issues.apache.org/jira/browse/STANBOL-1000
> Project: Stanbol
> Issue Type: Bug
> Components: Commons
> Reporter: Tommaso Teofili
> Assignee: Tommaso Teofili
>
> When trying to run commons.solr.core bundle in a custom environment the
> following missing packages show up (apart from the optional):
> com.ibm.icu.lang -- Cannot be resolved
> com.ibm.icu.text -- Cannot be resolved
> com.ibm.icu.util -- Cannot be resolved
> com.spatial4j.core.context -- Cannot be resolved
> com.spatial4j.core.distance -- Cannot be resolved
> com.spatial4j.core.exception -- Cannot be resolved
> com.spatial4j.core.io -- Cannot be resolved
> com.spatial4j.core.shape -- Cannot be resolved
> com.sun.management -- Cannot be resolved
> org.apache.commons.cli,version=[1.2.0,2) -- Cannot be resolved
> org.apache.commons.codec.binary,version=[1.7.0,2) -- Cannot be resolved
> org.apache.commons.lang,version=[2.6.0,3) -- Cannot be resolved
> org.apache.regexp -- Cannot be resolved
> so I think that basically we should add most of them (excluding commons-xyz)
> with an optional resolution in the Import-Package directive.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
