I can't help but wonder if it would make more sense to replace this with
something like "SolrCore.Initializable" ... you can get a SolrConfig from
a SolrCore, but you can't get a SolrCore from a SolrConfig.
yes, that sounds like a good idea.
The one (potential) issue is that the core may not be fully initialized
when it is passed to an SolrCore.Initializable()
that makes for an awkward contract since some calls have undefined
results depending on where in the initialization process it is. Maybe
this is not a big problem, but something to consider.
>
> 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,
we need to be careful not to call SolrCore.getSolrCore() because that
could send things into an initialization loop.
ryan
