You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2007/12/05 02:53:43 UTC

[jira] Issue Comment Edited: (SOLR-414) Coherent plugin initialization strategy

    [ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548501 ] 

hossman edited comment on SOLR-414 at 12/4/07 5:52 PM:
--------------------------------------------------------

sorry i'm rejoining the party so late (i've been sick)

just to clarify: one of the reasons analysis factories weren't on the SolrCoreAwareable list was to keep schema related things isolated from the core (it helps reduce complex dependencies, and leaves us more options for refactoring things later)

In the case of SOLR-319 there's really no reason why the entire SolrCore is needed right? -- just the IndexSchema.  perhaps there should be an IndexSchemaAware interface?

FWIW: rereading my earlier comments in SOLR-319, i think the best thing to do (for now at least) is to go with the simplest approach that achieves the goal: do what was done in the orriginal path, and just refer to the tokenizer factory class directly (which can be instantiated using the ResourceLoader) instead of refering to a fieldType name like i suggested.  

...I'll put that last part in that issues as well.

(NOTE: comment edited to fix issue number because i'm an idiot)

      was (Author: hossman):
    sorry i'm rejoining the party so late (i've been sick)

just to clarify: one of the reasons analysis factories weren't on the SolrCoreAwareable list was to keep schema related things isolated from the core (it helps reduce complex dependencies, and leaves us more options for refactoring things later)

In the case of SOLR-414 there's really no reason why the entire SolrCore is needed right? -- just the IndexSchema.  perhaps there should be an IndexSchemaAware interface?

FWIW: rereading my earlier comments in SOLR-414, i think the best thing to do (for now at least) is to go with the simplest approach that achieves the goal: do what was done in the orriginal path, and just refer to the tokenizer factory class directly (which can be instantiated using the ResourceLoader) instead of refering to a fieldType name like i suggested.  

...I'll put that last part in that issues as well.
  
> Coherent plugin initialization strategy
> ---------------------------------------
>
>                 Key: SOLR-414
>                 URL: https://issues.apache.org/jira/browse/SOLR-414
>             Project: Solr
>          Issue Type: Improvement
>    Affects Versions: 1.3
>            Reporter: Ryan McKinley
>            Assignee: Ryan McKinley
>             Fix For: 1.3
>
>         Attachments: SOLR-414-Initialization.patch, SOLR-414-Initialization.patch, SOLR-414-Initialization.patch, SOLR-414-Initialization.patch, SOLR-414-Initialization.patch
>
>
> We currently load many plugins with a Map or NamedList -- since SOLR-215, the current core is not available through SolrCore.getSolrCore() and may need to be used for initialization.
> Ideally, we could change the init() methods from:
> {panel}void init( final Map<String,String> args );{panel}
> to
> {panel}void init( final SolrCore core, final Map<String,String> args );{panel}
> Without breaking existing APIs, this change is difficult (some ugly options exist).  This patch offers a solution to keep existing 1.2 APIs, and allow access to the SolrConfig and SolrCore though ThreadLocal.  This should be removed in a future release.
> {panel}
>   DeprecatedPluginUtils.getCurrentCore();
>   DeprecatedPluginUtils.getCurrentConfig();
> {panel}
> This patch removes the SolrConfig.Initalizable that was introduced in SOLR-215.
> For background, see:
> http://www.nabble.com/Initializing---break-init%28%29-API-compatibility--tf4808463.html
> See also: SOLR-260, SOLR-215,  SOLR-399

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.