I think this is an oversight, rather than intentional (at least, I certainly didn't intend to write it like this!). The problem here will be that CoreDescriptors are currently built entirely from core.properties files, and the CoreLocators that construct them don't have any access to zookeeper.
Maybe the way forward is to move properties out of CoreDescriptor and have an entirely separate CoreProperties object that is built and returned by the ConfigSetService, and that is read via the ResourceLoader. This would fit in quite nicely with the changes I put up on SOLR-7570, in that you could have properties specified on the collection config overriding properties from the configset, and then local core-specific properties overriding both. Do you want to open a JIRA bug, Steve? Alan Woodward www.flax.co.uk On 28 May 2015, at 00:58, Chris Hostetter wrote: > : I am attempting to override some properties in my solrconfig.xml file by > : specifying properties in a solrcore.properties file which is uploaded in > : Zookeeper's collections/conf directory, though when I go to create a new > : collection those properties are never loaded. One work-around is to specify > > yeah ... that's weird ... it looks like the solrcore.properties reading > logic goes out ot it's way to read from the conf/ dir of the core, rather > then using the SolrResourceLoader (which is ZK aware in cloud mode) > > I don't understand if this is intentional or some kind of weird oversight. > > The relevent method is CoreDescriptor.loadExtraProperties() By all means > please open a bug about this -- and if you're feeling up to it, tackle a > patch: IIUC CoreDescriptor.loadExtraProperties is the relevent method ... > it would need to build up the path including the core name and get the > system level resource loader (CoreContainer.getResourceLoader()) to access > it since the core doesn't exist yet so there is no core level > ResourceLoader to use. > > Hopefully some folks who are more recently familiar with the core loading > logic (like Alan & Erick) will see the Jira nad can chime in as to wether > there is some fundemental reason it has to work the way it does not, or if > this bug can be fixed. > > > : easy way of updating those properties cluster-wide, I did attempt to > : specify a request parameter of 'property.properties=solrcore.properties' in > : the collection creation request but that also fails. > > yeah, looks like regardless of the filename, that method loads it the same > way. > > > -Hoss > http://www.lucidworks.com/
