Ah, yes the concern is about ... the use use of SolrCore in plugin init
methods before the SolrCore itself is fully initialized.
: We could either add a status to the core and have each high-level core
: method check this status before running (which would also allow to have
: cores logically stopped -or marked under reload/backup/etc) or heavily
: insist that using the core before 'init' has been called would lead to
: unpredictable results.
Let me propose a completely new appraoch then ...
Currently, the usage of SolrConfig.Initializable works like this...
factory = solrConfig.newInstance(className)
if (factory instanceof SolrConfig.Initializable) {
((SolrConfig.Initializable)factory).init(solrConfig, args);
} else {
log.warning("DEPRECATE");
factory.init(args);
}
what if we eliminate the SolrConfig.Initializable interface completely,
and introduce a new interface...
public interface SolrCoreAware {
public void tellAboutCore(SolrCore c);
}
...the semantics being that once a SolrCore is finished initializing
itself, and is completely ready to be used, the last phase of
it's initialization is to loop over all of the SolrCoreAware instances it
knows about, and call that.tellAboutCore(this). From a plugin's
perspective, init(...) will still always be called before it's every asked
to to any work, but in addition it would be garunteed that if it
implements SolrCoreAware, tellAboutCore would be called after init(...)
but before it's asked to do any real work.
Keeping track of all the plugins to "tell" about the SolrCore later would
be trivial ... SolrConfig.newInstance could do it, and SOlrCore could get
the info later.
OOOOHHHHHH... even better, SolrConfig could be changed to implement
SolrCoreAware, and all of the hard work could be implmented with the
addition below to SolrConfig (and all SolrCore has to do is call
solrConfig.tellAboutCore(this)) ...
private List<SolrCoreAware> needToTell = new List()
private SolrCore core = null;
public tellAboutCore(SolrCore c) {
core = c;
foreach (SolrCoreAware plugin : neeedToTell) {
plugin.tellAboutCore(core);
}
needToTell = null;
}
public Object newInstance(String cname, String... subpackages) {
Object that = super.newInstance(cname, subpackages);
if (that instanceof SolrCoreAware) {
if (null == core) {
needToTell.add(that);
} else {
that.tellAboutCore(core);
}
}
return that;
}
: > > Any reason to (re)introduce SolrCore.Initializable instead of
: > constructors
: > > that can take a SolrCore as a parameter?
: > If we can manage legacy code effectively the constructor approach seems
: > cleaner in the long run. But i'm not sure how that would work. Also,
i would prefer we avoid any work towards expecting plugin constructors
to take in a SolrCore as a param...
1) It still wouldn't address the issue of plugins attempting to use the
core they have access to before it's fully initialized
2) interfaces and abstract classes can't enforce any contract on
constructors, that's why we've always use default constructors and had
init(...) methods in the APIs ... it allows for compile time checking that
the Plugins will work (they have to go out of their way to write a plugin
without a default constructor to break things at runtime)
-Hoss
