[
https://issues.apache.org/jira/browse/STANBOL-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13618683#comment-13618683
]
Rupert Westenthaler commented on STANBOL-1012:
----------------------------------------------
Revision http://svn.apache.org/r1463103 provides a first implementation:
(1) The AbstractAnalyzerFoctoryActivator uses the Solr SPIClassIterator to load
instances from the provided ClassLoader. Note that only factories noted in
<code>META-INF/serivces</code> files embedded within the current module will be
found and registered. This means that this code needs typically be used in the
Bundle Activator for all modules providing Solr analyzer factories. Because of
this subclasses of this where added as BundleActivator to all
commons.solr.extra.** modules
* A AbstractAnalysisFactory instance is registered as OSGI service with
CharFilterFactory, TokenizerFactory or TokenFilterFactory as service class.
* The property "org.apache.lucene.analysis.factory.name" is set to the
lower case version of the factories simple name after cutting the suffix (e.g.
"icu" for "ICUTokenizerFactory").
* The "org.apache.lucene.util.Version" property is set to the name of the
Version returned by the #getLuceneMatchVersion() method. As this method
typically will return NULL this property will typically not present
* The "service.ranking" will be set to <code>0-bundleId</code>: This
ensures that a Factory provided by a Bundle with an lower ID will have a higher
ranking
(2) The new OsgiSolrResourceLoader (extends SolrResourceLoader) overrides the
findClass Method so that it looks in the OSGI serviceRegistry for
AbstractAnalysisFactory instances not found by the parent implementation. For
that it uses the similar regex (and code) to extract the factory name and
creates an OSGI filter based on the 'org.apache.lucene.analysis.factory.name'
property. NOTE: that if the service is found it does not use the registerd
service instance, but returns service#getClass(). Solr will create a new
instance of that class! This means that the Services registered with the OSGI
service registry are not directly used!
(3) The SolrServerAdapter was changed to no longer use
CoreContainer#createCore(..), but to create the SolrCore itself. This is
required for being able to use the OsgiSolrResourceLoader. The code used for
the creation is based on the CoreContainer#createFromLocal(..) but does not use
the schema.xml cache and does not support Solr Core properties.
* Most important this breaks the creation of a core if ZKController
(ZooKeeper) is present. To also support this kind of cores one would need to
check for CoreContainer#isZooKeeperAware(), create an OsgiZkSolrResourceLoader
and than adapt the code to initialize the core similar to
Corecontainer#createFromZk(..). If some could provide an UnitTest that test
with ZooKeeper it would be great. But without having a test case I prefer to
exclude support for ZooKeeper.
> Register Solr AnlyzerFactories as OSGI services and provide OSGI enabled
> SolrResourceLoader
> -------------------------------------------------------------------------------------------
>
> Key: STANBOL-1012
> URL: https://issues.apache.org/jira/browse/STANBOL-1012
> Project: Stanbol
> Issue Type: Sub-task
> Components: Commons
> Reporter: Rupert Westenthaler
> Assignee: Rupert Westenthaler
>
> Starting with Solr 4 an SPI like mechanism is used to locate Analyzers
> Factories. This means that "META-INF/services" are used to locate
> CharFilterFactory, TokenizerFactory and TokenFilterFactory instances.
> This prevents the separation of optional Analyzers in their own modules, as
> "META-INF/services" files can only be loaded from the current bundle (the
> o.a.stanbol.commons.solr.core module).
> To keep the possibility to provide own modules for optional Analyzer
> Factories it is necessary to replace the SPI infrastructure with one that is
> 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.
--
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
