First cut at the basics, putting up a preliminary version for comments.
The general approach here is that, for any lazy cores, keep a separate list of SolrCoreDescriptors. When we get a core, if it's not already loaded, look in this separate list and create it at that point.
Note a bunch of things:
1> many of the changes in CoreContainer are that I factored out creating cores from local files and Zookeeper into two methods, I was having a hard time keeping the zk and non-zk bits separate.
2> There are some TODOs and EOEs that I have to take out.
3> I'm not all that happy with the tests, especially making new config directories just for this case with tests. But I was going a bit crazy yesterday trying to use the "usual" methods for writing tests, but as far as I can tell, there are built-in assumptions in things like TestHarness that don't work well with different cores. Any suggestions?
4> All test pass. I fired up an example in our standard multicore system, and it's actually kinda cool. The admin console doesn't show the lazy core, but I can index to it with post.jar, then the admin screen shows it and I can query it. I can shut down and restart and the first query on the lazy core then returns results, even though it again isn't in the admin screen.
5> I haven't tested this all that thoroughly, this is preliminary for comments. This is part of
6> Next up is
SOLR-1028, limiting the number of cores that can be loaded simultaneously.
7> I'm quite sure I'll screw up the reference counting and/or there are nooks and crannies that I don't even know exist. Please let me know of any off the tops of your heads!
8> All tests pass. Can I ship it now? <G>