: I don't follow i) -- my complaint about the multiple init() interfaces is that
: it just feels wierd to have:
:
: void init( Map<String,String> args )
: *and*
: void init( ResourceFinder finder )
:
: when what you really want is:
:
: void init( ResourceFinder finder, Map<String,String> args )
I disagree. even if we didn't care about backwards comptibility, (and i'm
not saying we shouldn't -- it's important, but even if it wasn't) the two
method approach allows a plugin to be more explicit about it's
dependencies and what it cares about. if every Analysis factory
implements *must* implement an init(ResourceFinder,Map<String,String>)
method, then you have no way of knowing which factories actually *want* to
be able to find other resources ... the ability to use/test a factory in
isoltion goes away --- even in hte most trivial case.
i agree that it seems wrong to have two different "init" methods with
different params, both of which get called -- but that's why i didn't
orriginally advocate calling the new method "init". I suggested something
like "tellAboutFoo" ... i said in that thread something like "i
don't really care what the name of the new method is" but that was
probably a bad thing to say: names carry context and suggest meaning...
what we are really talking about here is "setter" methods declared by a
marker interface for plugins that care about a property and want someone
to set it for them after they are "init'ed" and before they are used...
public interface Foo extends NamedListInitializedPlugin {
//...some additional methods besides init(NamedList) ...
}
public interface Bar extends MapInitializedPlugin {
//...some additional methods besides init(Map) ...
}
public interface SolrCoreAware {
public void setCore(SolrCore); // .. maybe throws InitException???
}
public class SimpleFoo implements Foo {
public init(NamedList { ... }
// ...methods to meet Foo contract
}
public class ComplexFoo implements Foo, SolrCoreAware {
public init(NamedList) { ... }
public setCore(SolrCore) { ... }
// ...methods to meet Foo contract
}
...the only thing slightly non-standard about calling these methods
"setters" is that they aren't expected to jsut be "POJO" style setters ...
the expectation is that the class will do some work when they are called
-- hence my "tell" (or maybe "notify" or "inform" is a better verb)
suggestion.
: To sum up, I see two directions:
:
: 1. Keep existing init() apis. Add more init() functions that pass in SolrCore
: or a ResourceFinder.
:
: 2. Keep existing init() apis, but advertise they will change in the future.
: As a stop-gap measure make the parameters that will be available in the future
: available through ThreadLocal. (SOLR-414)
:
: I vote for #2 because after the 2.0 release, we will have a clean API with all
: init options available in a single place. I am ok with #1 also.
i vote for #1, but as i said: the new methods shouldn't be named "init"
since that will clearly confuse people about the semantics. this also has
the nice property that 1 year from now when we decide there's another
(new) important object we'd like plugins to have access to (if they want
it) before they are asked to do work we don't have to jump through all the
hoops of changing the init() signature again.
-Hoss
