Replying here coz jira is down Let's get rid of solrcore.properties in cloud . We don't need it. It is not just reading that thing. We need to manage the lifecycle as well (editing, refreshing etc)
This is the right way to do properties in solrcloud https://cwiki.apache.org/confluence/display/solr/Config+API#ConfigAPI-CommandsforUser-DefinedProperties On Fri, Jun 5, 2015 at 3:25 AM, Hoss Man (JIRA) <j...@apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/SOLR-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14573660#comment-14573660 > ] > > Hoss Man commented on SOLR-7613: > -------------------------------- > > Some relevant comments on this from the original mailing list discussion... > > Hoss.. > > bq. 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. > > Alan... > > bq. 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. > > bq. 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. > > Hoss... > > bq. 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. > > Alan... > > bq. 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. > > Hoss... > > bq. but if you look at it fro ma historical context, that doesn't really > matter for the purpose that solrcore.properties was intended for -- it > predates core discover, and was only intended as a way to specify "user" > level properties that could then be substituted in the solrconfig.xml or > dih.xml or schema.xml > > bq. ie: making it possible to use a solrcore.prop value to set a core.prop > value might be a nice to have, but it's definitely not what it was intended > for, so it shouldn't really be a blocker to getting the same (original) basic > functionality working in SolrCloud. > > ---- > > Honestly, even ignoring the historical context, it seems like a chicken and > egg problem to me -- should it be possible to use a solrecore.properties > variable to set the value of another variable in core.properties? or should > it be possible to use a core.properties variable to set the value of another > variable in solrcore.properties? > > the simplest thing for people to udnerstand would probably be to just say > that they are independent, loaded seperately, and cause an error if you try > to define the same value in both (i doubt that's currently enforced, but it > probably should be) > >> solrcore.properties file should be loaded if it resides in ZooKeeper >> -------------------------------------------------------------------- >> >> Key: SOLR-7613 >> URL: https://issues.apache.org/jira/browse/SOLR-7613 >> Project: Solr >> Issue Type: Bug >> Reporter: Steve Davids >> Fix For: 5.3 >> >> >> The solrcore.properties file is used to load user defined properties for use >> primarily in the solrconfig.xml file, though this properties file will only >> load if it is resident in the core/conf directory on the physical disk, it >> will not load if it is in ZK's core/conf directory. There should be a >> mechanism to allow a core properties file to be specified in ZK and can be >> updated appropriately along with being able to reload the properties when >> the file changes (or via a core reload). > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
