[
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
