[jira] [Commented] (STANBOL-1012) Register Solr AnlyzerFactories as OSGI services and provide OSGI enabled SolrResourceLoader

["Rupert Westenthaler (JIRA)" <ji...@apache.org>]

    [ 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