[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548925 ]
Ryan McKinley commented on SOLR-414: ------------------------------------ Koji, are you able to get what you need working with hoss' suggestion? If so, I am tempted to sit on this for a while and see how it feels as we try new things. I am not against removing the artificial constraint, but I agree with the idea that keeping it gives us more wiggle room in the future. I suppose we could do an IndexSchemaAware interface, but I am not sure how much that gains. I think the nice thing about the SolrCoreAware interface is that the class declares what its dependencies are. This makes it possible for most analyzers/fields/tokenizers/etc to have no dependencies, a few to need ResourceLoader and a couple to need SolrCore/IndexSchema. In my opinion, since the class defines its dependencies, it is not a problem to give it access to SolrCore. Obviously it would not work outside solr, but the classes that don't depend on core could. But, unless there is a real need, we can always relax the constraint in the future. > 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.