Sorry for not responding back earlier, I went ahead and created a ticket here:
https://issues.apache.org/jira/browse/SOLR-7613 It does look somewhat trivial if you just update the current loading mechanism as Chris describes, I can provide a patch for that if you want. Though, if you want to go the refactoring route I can leave it to Alan to take a crack at it. Thanks, -Steve On Fri, May 29, 2015 at 3:29 AM, Alan Woodward <a...@flax.co.uk> wrote: > Yeah, you could do it like that. But looking at it further, I think > solrcore.properties is actually being loaded in entirely the wrong place - > it should be done by whatever is creating the CoreDescriptor, and then > passed in as a Properties object to the CD constructor. At the moment, you > can't refer to a property defined in solrcore.properties within your > core.properties file. > > I'll open a JIRA if Steve hasn't already done so > > Alan Woodward > www.flax.co.uk > > > On 28 May 2015, at 17:57, Chris Hostetter wrote: > > > > > : 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. > > > > But they do have access to the CoreContainer which is passed to the > > CoreDescriptor constructor -- it has all the ZK access you'd need at the > > time when loadExtraProperties() is called. > > > > correct? > > > > as fleshed out in my last emil... > > > > : > 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. > > > > > > -Hoss > > http://www.lucidworks.com/ > >
