> > This is the right way to do properties in solrcloud > > > https://cwiki.apache.org/confluence/display/solr/Config+API#ConfigAPI-CommandsforUser-DefinedProperties
In my particular case the core won't load without some of the properties being specified. Is there a way to get those properties into ZK before you even create the new collection? It looks like you are adding properties to an already existing collection... -Steve On Fri, Jun 5, 2015 at 12:09 AM, Noble Paul <[email protected]> wrote: > 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) <[email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
