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 "Ryan McKinley (JIRA)" <ji...@apache.org> on 2007/11/18 20:57:43 UTC
[jira] Created: (SOLR-414) Coherent plugin initialization strategy
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
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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549653 ]
Hoss Man commented on SOLR-414:
-------------------------------
Henri: this comment concerns me...
> May I kindly suggest that if you -Hoss & Ryan- feel we can't close the
> topic yet, we at least commit it with an in-flux state?
...as far as i can tell Ryan already commited all of the SolrCoreAware and ResourceLoader stuff back on Nov24 ... is there more to this issue that you feel is missing and still needs committed?
And just to clarify one thing...
> Hoss,
> Are you suggesting dropping SolrCoreAware and replace it with IndexSchemaAware ?
No, SolrCoreAware should serve a valuable purpose for plugins that historicaly might have accessed one of the singletons from an init() method -- i was just suggesting that an IndexSchemaAware API might (someday) be handy analysis type plugins that want an equally tight "call back" coupling with the IndexSchema when it's initialized.
> 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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544600 ]
Ryan McKinley commented on SOLR-414:
------------------------------------
>
> it hadn't occurred to be that ResourceLoader could be a super class of Config ... i was assuming it would just be an object SolrConfig (or the SolrCore) held on to, and we'd deprecate those methods in Config. is there an advantage i'm not thinking of to having it be superclass?
>
The only reason it is a super class is for easy API compatibility. Perhaps a better way is to have an independent ResourceLoader and add @deprecated getters to Config.java:
@Deprecated
public String getConfigDir()
{
return loader.getConfigDir()
}
> In theory "ResourceLoader" can be a very constrained interface for the plugins themselves that has no Solr dependencies...
>
I like that. I'll put the 'ResourceLoader' class in o.a.s.util
> 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
>
>
> 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.
[jira] Resolved: (SOLR-414) Coherent plugin initialization strategy
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley resolved SOLR-414.
--------------------------------
Resolution: Fixed
I added some docs to the wiki and will resolve this issue. If we need to relax the constraints later, lets do that in a new issue
> 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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Koji Sekiguchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546526 ]
Koji Sekiguchi commented on SOLR-414:
-------------------------------------
Ryan,
On SOLR-319, I'd like SynonymFilterFactory to implement SolrCoreAware so that it can use "fieldType" instead of "tokenFactory" to analyze synonyms.txt as Hoss suggested on that ticket. But due to above constraint, I got the following exception:
FATAL: org.apache.solr.common.SolrException: Invalid 'Aware' object: org.apache.solr.analysis.SynonymFilterFactory@1e328e0 -- org.apache.solr.util.plugin.SolrCoreAware must be an instance of: [org.apache.solr.request.SolrRequestHandler] [org.apache.solr.request.QueryResponseWriter] [org.apache.solr.handler.component.SearchComponent]
at org.apache.solr.core.SolrResourceLoader.assertAwareCompatibility(SolrResourceLoader.java:341)
at org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:227)
at org.apache.solr.util.plugin.AbstractPluginLoader.create(AbstractPluginLoader.java:83)
at org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
at org.apache.solr.schema.IndexSchema.readAnalyzer(IndexSchema.java:652)
at org.apache.solr.schema.IndexSchema.access$000(IndexSchema.java:57)
at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:338)
at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:356)
at org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:365)
at org.apache.solr.schema.IndexSchema.<init>(IndexSchema.java:73)
at org.apache.solr.core.SolrCore.<init>(SolrCore.java:286)
at org.apache.solr.core.SolrCore.getSolrCore(SolrCore.java:254)
at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:68)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221)
at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:302)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:78)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3635)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4222)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:448)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
Can the constraint be revised?
> 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.
[jira] Updated: (SOLR-414) Coherent plugin initialization strategy
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-414:
-------------------------------
Attachment: SOLR-414-Initialization.patch
sorry - I uploaded the wrong one
> 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
>
>
> 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.
[jira] Updated: (SOLR-414) Coherent plugin initialization strategy
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-414:
-------------------------------
Attachment: SOLR-414-Initialization.patch
Updated patch to reflect ideas discussed in:
http://www.nabble.com/Initializing---break-init%28%29-API-compatibility--tf4808463.html
This sticks with 1.2 init APIs and abandons the previous ThreadLocal approach. Instead, this
1. Adds two interfaces: ResourceLoaderAware, SolrCoreAware
2. The ResourceLoader keeps track of "Aware" instances until it is told to "Inform" them
> 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
>
>
> 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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Henri Biestro (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548338 ]
Henri Biestro commented on SOLR-414:
------------------------------------
Simple contract is good.
>> since we are (back to) using Solr core objects before the core is fully initialized.
> not true. inform( SolrCore ) is the last thing that happens in the init process.
You are right; and this removes the cyclic and out-of-order dependency potential problems.
Taking the example of using a field type in a token filter, the filter is (might be) made aware of the core before the field type but this is a non-issue since we are not actually using either of them before they are both informed.
> 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.
[jira] Issue Comment Edited: (SOLR-414) Coherent plugin
initialization strategy
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544592 ]
Hoss Man commented on SOLR-414:
-------------------------------
it hadn't occurred to be that ResourceLoader could be a super class of Config ... i was assuming it would just be an object SolrConfig (or the SolrCore) held on to, and we'd deprecate those methods in Config. is there an advantage i'm not thinking of to having it be superclass?
In theory "ResourceLoader" can be a very constrained interface for the plugins themselves that has no Solr dependencies...
public interface ResourceLoader {
/* a way to instantiate objects using an appropriate classloader */
public Object newInstance(String classname, String... subpackages);
/* a way to open config files, may check multiple directories in a set order */
public InputStream openResource(String name);
// ... getLines probably makes sense too.
}
...and Solr has a concrete SolrResourceLoader class that knows about the instanceDir, config dir, default packages for plugins, etc....
> 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
>
>
> 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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548501 ]
Hoss Man commented on SOLR-414:
-------------------------------
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.
[jira] Updated: (SOLR-414) Coherent plugin initialization strategy
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-414:
-------------------------------
Attachment: SOLR-414-Initialization.patch
sorry, last patch was missing new files
> 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
>
>
> 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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546772 ]
Ryan McKinley commented on SOLR-414:
------------------------------------
I am ok with relaxing the constraints.
As implemented, we could change the contract to say "anything instantiated through the SolrResourceLoader that implements SolrCoreAware/ResourceLoaderAware will be informed" -- Alternatively we could add TokenFilterFactory.class and TokenizerFactory.class to the list of valid components.
Hoss do you have thoughts on this?
> 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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Henri Biestro (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544834 ]
Henri Biestro commented on SOLR-414:
------------------------------------
Looks good to me; got a solr-350 + 409 patch (414 pre-integrated) ready to upload as soon as this gets committed.
> 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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (SOLR-414) Coherent plugin initialization strategy
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-414:
-------------------------------
Attachment: SOLR-414-Initialization.patch
This patch maintains 1.2 API compatibility and gives access to core/config via ThreadLocal.
> 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
>
>
> 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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548311 ]
Ryan McKinley commented on SOLR-414:
------------------------------------
I lean towards the simple contract: "if the SolrResourceLoader create the object, implementations of ResourceLoaderAware/SolrCoreAware will be informed about the ResourceLoader/SolrCore"
>
> since we are (back to) using Solr core objects before the core is fully initialized.
>
not true. inform( SolrCore ) is the last thing that happens in the init process.
> 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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Henri Biestro (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548659 ]
Henri Biestro commented on SOLR-414:
------------------------------------
Hoss,
Are you suggesting dropping SolrCoreAware and replace it with IndexSchemaAware ?
I'm under the impression that SolrCoreAware is not needed (and might not even be desirable) with ResourceLoaderAware & IndexSchemaAware available.
May I kindly suggest that if you -Hoss & Ryan- feel we can't close the topic yet, we at least commit it with an in-flux state?
> 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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Koji Sekiguchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548929 ]
Koji Sekiguchi commented on SOLR-414:
-------------------------------------
Ryan,
I'm happy with hoss' last comment regarding SOLR-319. So I don't need to implement SolrCoreAware (and IndexSchemaAware) any more in SOLR-319.
Thank you for your consideration.
> 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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Henri Biestro (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548304 ]
Henri Biestro commented on SOLR-414:
------------------------------------
Seems to me that relaxing by class will end up being very user-unfriendly if it is not easy to add a class to the list of "really" aware classes (would even seem counter-effective).
There are 2 approaches, one is to be explicit, the other is to relax the whole constraint and let the interface trigger the behavior.
On the explicit side, one solution could be an attribute in the schema (or alternatively a static block to register the class).
On the implicit side, relaxing by "interface" (versus per concrete instance) is almost a full-loop on the subject with the twist that we succeeded preserving the init signatures.
We might then want to reintroduce the solr-399 dependency graph feature since we are (back to) using Solr core objects before the core is fully initialized.
Thoughts ?
> 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.
[jira] Updated: (SOLR-414) Coherent plugin initialization strategy
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-414:
-------------------------------
Attachment: SOLR-414-Initialization.patch
Here is an updated patch that:
1. Makes ResourceLoader an independent interface and extracts SolrResourceLoader from Config (leaving depricated methods)
2. Adds valid class checking for "aware" registration. This is a simple check made to limit the scope of who can implement SolrCoreAware/ResourceLoaderAware if we want, we could easily remove this constraint:
{code:java}
awareCompatibility.put(
SolrCoreAware.class, new Class[] {
SolrRequestHandler.class,
QueryResponseWriter.class,
SearchComponent.class
}
);
awareCompatibility.put(
ResourceLoaderAware.class, new Class[] {
TokenFilterFactory.class,
TokenizerFactory.class,
FieldType.class
}
);
{code}
If things look good to you all, I will clean up some javadocs and the 'plugin' wiki page and commit.
> 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.
[jira] Commented: (SOLR-414) Coherent plugin initialization
strategy
Posted by "Henri Biestro (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543516 ]
Henri Biestro commented on SOLR-414:
------------------------------------
org.apache.solr.util.plugin.DeprecatedPluginUtils seems to be missing from patch.
> 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
>
>
> 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.