lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: Initializing - break init() API compatibility?
Date Wed, 21 Nov 2007 20:32:07 GMT

: nonsense! of course its not too late.  Its great to get feedback and new ideas
: anytime - the goal is to make sure that we like where we end up and we feel
: confident we haven't missed something.  A few loops in the middle are to be
: expected.

Agreed ... for what it's worth Henri: In my mind you and Ryan are the 
Brain Trust as far as all of hte related issues regarding the multicore, 
singletons, and init methods ball of wax ... i'm just making suggestions 
and voicing concerns.  Even if Ryan cranked out something he and I both 
thought looked perfect, i'd want to refrain from commiting until we got 
your feedback.

: I see where you're going, but I'm not sure we *want* the singletons back ;)

right ... it took me 3 or 4 reads to understand you idea, to express it in 
another way (in case there are people following along who still don't get 
it and could use an alternate explanation) ...  instead of this 
ResourceLoader class being a simple object that contains a refrence to the 
inistanceDir and plugin ClassLoader (like Config currently does) you are 
suggesting that ResourceLoader *extend* ClassLoader, and have an accessor 
for the SolrCore so that any plugin that wants the core can do it by 
casting it's ClassLoader to a ResourceLoader and calling the getCore() 
method.

This is a freaking brilliant idea! ... but i don't think we should do it.

Partly for the reason ryan already said...

: I'm reluctant to attach more data to the ResourceLoader.  One of Hoss' more
: convincing arguments (for me) is that the "Inform/Aware" interfaces makes it
: clear what components have which dependencies.  This is a big advantage for

...it would take away the compile time dependency information.

but also because the discussion so far about the "inform" style methods, 
and calling it.inform(SolrCore) only after the core is fully inited isn't 
*just* solving the problem of "where did hte singletons go?" it's also 
addressing a limitation of the current plugin APIs...

every plugin interface has essentially two methods...
    init(some args) // called once
    doWork(state)   // called many many times

even when we had a singleton SolrCore, it typically couldn't be used 
during the init method, but could be used during the doWork method ... 
which ment if you wnated to use the core for "initialization" type stuff, 
doWork had to be implemented something like...

   private SolrCore core = null;
   public doWork(State s) {
     synchronize (this) {
       if (null == core) {
          core = SolrCore.getSolrCore();
          doExtraInit();
       }
     }
     doRealWork(s)
   } 

by having an "inform" style method, and garunteeing that the "lifecycle" 
of a plugin will be...
  1) constructed
  2) inited
  3) informed of core (if implements SolrCoreAware)
  4) told to do work ... many times.
...then the inform method serves as a simple place to "finish" 
any initialization that depends on the SolrCore.




-Hoss


Mime
View raw message