I agree that the core being accessible whilst not being fully initialized is not very "comfortable". 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. The former could also close the potential SolrCore.getSolrCore() issue (which exists today anyway) since the status could be checked there as well. Could such a modification be folded in solr-281 or is this a bad idea? I can give it a shot if you want. Henri
ryantxu wrote: > >>> 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 > > -- View this message in context: http://www.nabble.com/SolrConfig.Initializable-tf4665036.html#a13339931 Sent from the Solr - Dev mailing list archive at Nabble.com.
