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;
}
Interesting, instances of SolrCoreAware would be queued up until the
config is told what the core is - afterwards it tells them immediately.
I like that.
The one concern is what about the potential to call
config.tellAboutCore( core0 ) then call config.tellAboutCore( core1 );
In my view, that should either
1. throw an error
or
2. tell all the SolrCoreAware components about the new core
I don't see a good use case where you would want to change the core out
from under everything it initialized. Rather, you would want to
reinitalize everything. So I would vote for #1
I like the name 'SolrCoreAware', but not wild about 'tellAboutCore'
perhaps setSolrCore( core )? maybe strange since it may not be a bean.
i would prefer we avoid any work towards expecting plugin constructors
to take in a SolrCore as a param...
agreed.
