the setDirFactory method seems a little troubling - why do we do that instead of making it part of the constructor? What if you don't set it?
Are you asking about SolrIndexWriter.setDirectoryFactory ?
it's private, and called from the (static) SolrIndexWriter.create – which as of this patch is the only way to get a new SolrIndexWRiter.
I had to move it out of the SolrIndexWriter constructor, because we need to be able to pass the resulting directory to super() while also releasing the directory if the constructor throws an exception – this isn't possible within java's "calls to super(...) must be the first line of the constructor" constraints, so the static factory method was needed instead.
The dir factory should and will be closed by the DefaultSolrCoreState when it's ref count hits 0 - you don't actually want to close it when closing a core.
But the update handler is the only thing keeping track of the SolrCoreState – if the SolrCore has no UpdateHanlder (ie: because it failed to initialize) then something needs to close the DirectoryFactory that SolrCore.initDirectoryFactory() already created.
(Go ahead and try to comment out that "HACK" directoryFactory.close() in the patch – you'll see TestBadConfig.testUpdateLogButNoVersionField start failing. I added that call to ensure that the DirectoryFactory gets closed if any exceptions are thrown between a (successsful) call to initDirectoryFactory() ~L641 of SolrCore and (a success of failure of) createUpdateHandler() ~L707. Don't get me wrong, it definitely feels like a hack (hence the comment) but something needs to account for this situation – and i wasn't comfortably completely re-writing/re-ordering the logic in the SolrCore constructor.