Solr
  1. Solr
  2. SOLR-414

Coherent plugin initialization strategy

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 1.3
    • Component/s: None
    • Labels:
      None

      Description

      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:

      void init( final Map<String,String> args );

      to

      void init( final SolrCore core, final Map<String,String> args );

      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.

      DeprecatedPluginUtils.getCurrentCore();
      DeprecatedPluginUtils.getCurrentConfig();

      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

      1. SOLR-414-Initialization.patch
        86 kB
        Ryan McKinley
      2. SOLR-414-Initialization.patch
        63 kB
        Ryan McKinley
      3. SOLR-414-Initialization.patch
        64 kB
        Ryan McKinley
      4. SOLR-414-Initialization.patch
        52 kB
        Ryan McKinley
      5. SOLR-414-Initialization.patch
        52 kB
        Ryan McKinley

        Issue Links

          Activity

          Hide
          Ryan McKinley added a comment -

          This patch maintains 1.2 API compatibility and gives access to core/config via ThreadLocal.

          Show
          Ryan McKinley added a comment - This patch maintains 1.2 API compatibility and gives access to core/config via ThreadLocal.
          Hide
          Ryan McKinley added a comment -

          sorry, last patch was missing new files

          Show
          Ryan McKinley added a comment - sorry, last patch was missing new files
          Hide
          Henri Biestro added a comment -

          org.apache.solr.util.plugin.DeprecatedPluginUtils seems to be missing from patch.

          Show
          Henri Biestro added a comment - org.apache.solr.util.plugin.DeprecatedPluginUtils seems to be missing from patch.
          Hide
          Ryan McKinley added a comment -

          sorry - I uploaded the wrong one

          Show
          Ryan McKinley added a comment - sorry - I uploaded the wrong one
          Hide
          Ryan McKinley added a comment -

          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

          Show
          Ryan McKinley added a comment - 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
          Hide
          Hoss Man added a comment -

          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....

          Show
          Hoss Man added a comment - 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....
          Hide
          Ryan McKinley added a comment -

          >
          > 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

          Show
          Ryan McKinley added a comment - > > 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
          Hide
          Ryan McKinley added a comment -

          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:

              awareCompatibility.put( 
                SolrCoreAware.class, new Class[] {
                  SolrRequestHandler.class,
                  QueryResponseWriter.class,
                  SearchComponent.class
                }
              );
          
              awareCompatibility.put( 
                ResourceLoaderAware.class, new Class[] {
                  TokenFilterFactory.class,
                  TokenizerFactory.class,
                  FieldType.class
                }
              );
          

          If things look good to you all, I will clean up some javadocs and the 'plugin' wiki page and commit.

          Show
          Ryan McKinley added a comment - 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: awareCompatibility.put( SolrCoreAware.class, new Class [] { SolrRequestHandler.class, QueryResponseWriter.class, SearchComponent.class } ); awareCompatibility.put( ResourceLoaderAware.class, new Class [] { TokenFilterFactory.class, TokenizerFactory.class, FieldType.class } ); If things look good to you all, I will clean up some javadocs and the 'plugin' wiki page and commit.
          Hide
          Henri Biestro added a comment -

          Looks good to me; got a solr-350 + 409 patch (414 pre-integrated) ready to upload as soon as this gets committed.

          Show
          Henri Biestro added a comment - Looks good to me; got a solr-350 + 409 patch (414 pre-integrated) ready to upload as soon as this gets committed.
          Hide
          Koji Sekiguchi added a comment -

          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?

          Show
          Koji Sekiguchi added a comment - 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?
          Hide
          Ryan McKinley added a comment -

          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?

          Show
          Ryan McKinley added a comment - 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?
          Hide
          Henri Biestro added a comment -

          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 ?

          Show
          Henri Biestro added a comment - 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 ?
          Hide
          Ryan McKinley added a comment -

          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.

          Show
          Ryan McKinley added a comment - 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.
          Hide
          Henri Biestro added a comment -

          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.

          Show
          Henri Biestro added a comment - 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.
          Hide
          Hoss Man added a comment - - edited

          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)

          Show
          Hoss Man added a comment - - edited 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)
          Hide
          Henri Biestro added a comment -

          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?

          Show
          Henri Biestro added a comment - 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?
          Hide
          Ryan McKinley added a comment -

          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.

          Show
          Ryan McKinley added a comment - 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.
          Hide
          Koji Sekiguchi added a comment -

          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.

          Show
          Koji Sekiguchi added a comment - 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.
          Hide
          Ryan McKinley added a comment -

          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

          Show
          Ryan McKinley added a comment - 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
          Hide
          Hoss Man added a comment -

          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.

          Show
          Hoss Man added a comment - 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.
          Hide
          Benson Margulies added a comment -

          I don't need access to the core: I just need to establish a CloseHook(). But I don't see how to do that based on Hoss Man's suggestion.

          Show
          Benson Margulies added a comment - I don't need access to the core: I just need to establish a CloseHook(). But I don't see how to do that based on Hoss Man's suggestion.

            People

            • Assignee:
              Ryan McKinley
              Reporter:
              Ryan McKinley
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development