Solr
  1. Solr
  2. SOLR-1335

load core properties from a properties file

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.4
    • Component/s: None
    • Labels:
      None

      Description

      There are few ways of loading properties in runtime,

      1. using env property using in the command line
      2. if you use a multicore drop it in the solr.xml

      if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
      In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.

      It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr

      I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.

      1. SOLR-1335.patch
        13 kB
        Noble Paul
      2. SOLR-1335.patch
        11 kB
        Noble Paul
      3. SOLR-1335.patch
        11 kB
        Noble Paul
      4. SOLR-1335.patch
        3 kB
        Noble Paul

        Activity

        Hide
        Noble Paul added a comment -

        hi everyone, If there are no objections I plan to commit this as soon as I write a testcase. Please comment, because this is a very visible change

        Show
        Noble Paul added a comment - hi everyone, If there are no objections I plan to commit this as soon as I write a testcase. Please comment, because this is a very visible change
        Hide
        Noble Paul added a comment -

        with a testcase

        Show
        Noble Paul added a comment - with a testcase
        Hide
        Noble Paul added a comment -

        with license headers. I plan to commit this soon

        Show
        Noble Paul added a comment - with license headers. I plan to commit this soon
        Hide
        Hoss Man added a comment -

        Noble: i'm really confused about a few things...

        1) skimming the patch to CoreContainer it looks like "solrconfig.properties" is intented to be a new hardcoded magic filename ... but with the push towards solr.xml being the one and only magic hardcoded filename wouldn't it make more sense to people specify a properties file name (or names) there? (just like they can specify individual properties)

        2) i don't really understand the way the test code is structured ... TestSolrCoreProperties extends TestCase, and contains a private inner class SolrInstance extends AbstractSolrTestCase (extends TestCase,) ... huh?

        SolrInstance's only value add on top of AbstractSolrTestCaseseems to be the creations of a new "solrcore.properties" file with some values in it ... but why not just commit an example "solrcore.properties" file directly into the test directory?

        What's the need for the inner test class? (that file creation could be in the outer setUp() method just as easily) and how does the test actaully verify that a property was set correctly? (the only properties i can see used in solrconfig-solcoreproperties.xml are in garbage xml tags: tag1 & tag2 which aren't going to affect any behavior)

        (As a general rule: anytime i see System.setProperty i get worried ... those are going to affect the whole VM, not just this test, which could cause all sorts of confusion for other people (or other tests))

        Show
        Hoss Man added a comment - Noble: i'm really confused about a few things... 1) skimming the patch to CoreContainer it looks like "solrconfig.properties" is intented to be a new hardcoded magic filename ... but with the push towards solr.xml being the one and only magic hardcoded filename wouldn't it make more sense to people specify a properties file name (or names) there? (just like they can specify individual properties) 2) i don't really understand the way the test code is structured ... TestSolrCoreProperties extends TestCase, and contains a private inner class SolrInstance extends AbstractSolrTestCase (extends TestCase,) ... huh? SolrInstance's only value add on top of AbstractSolrTestCaseseems to be the creations of a new "solrcore.properties" file with some values in it ... but why not just commit an example "solrcore.properties" file directly into the test directory? What's the need for the inner test class? (that file creation could be in the outer setUp() method just as easily) and how does the test actaully verify that a property was set correctly? (the only properties i can see used in solrconfig-solcoreproperties.xml are in garbage xml tags: tag1 & tag2 which aren't going to affect any behavior) (As a general rule: anytime i see System.setProperty i get worried ... those are going to affect the whole VM, not just this test, which could cause all sorts of confusion for other people (or other tests))
        Hide
        Noble Paul added a comment -

        Hoss, thanks for the comments

        "solrconfig.properties" is intented to be a new hardcoded magic filename .

        For a single-core the filenames are always hardcoded like solrconfig.xml and schema.xml. solrconfig.xml filename can be overridden from web.xml, but that is only if I modify the solr.war which I believe is not really used and it is "hacking solr".

        but with the push towards solr.xml being the one and only magic hardcoded filename

        This is a good idea. But most of the users use single core deployments and the goodies that come with solr.xml is not available for them. So it is not much helpful . I wish the single core also becomes a multicore with one core and all these confusions can go away.

        We can of course extend this feature by adding a property to the core tag as <core properties="conf/props.properties"> in solr.xml . Do we really need to do it now because the properties file itself is optional and adding that to solr.xml can add to more clutter for a feature that is not widely used . Even if we add it later it is going to be backward compatible.

        For the testcase , I just copied it from another w/o giving it much of a thought. The inner class can be avoided

        anytime i see System.setProperty i get worried

        do we really have a choice here? Solr needs solr.solr.home to be set as a system property and all testcases follow this pattern

        Show
        Noble Paul added a comment - Hoss, thanks for the comments "solrconfig.properties" is intented to be a new hardcoded magic filename . For a single-core the filenames are always hardcoded like solrconfig.xml and schema.xml. solrconfig.xml filename can be overridden from web.xml, but that is only if I modify the solr.war which I believe is not really used and it is "hacking solr". but with the push towards solr.xml being the one and only magic hardcoded filename This is a good idea. But most of the users use single core deployments and the goodies that come with solr.xml is not available for them. So it is not much helpful . I wish the single core also becomes a multicore with one core and all these confusions can go away. We can of course extend this feature by adding a property to the core tag as <core properties="conf/props.properties"> in solr.xml . Do we really need to do it now because the properties file itself is optional and adding that to solr.xml can add to more clutter for a feature that is not widely used . Even if we add it later it is going to be backward compatible. For the testcase , I just copied it from another w/o giving it much of a thought. The inner class can be avoided anytime i see System.setProperty i get worried do we really have a choice here? Solr needs solr.solr.home to be set as a system property and all testcases follow this pattern
        Hide
        Noble Paul added a comment -

        The current default name is set as solrcore.properties. Is there any other preference for the name?

        Show
        Noble Paul added a comment - The current default name is set as solrcore.properties. Is there any other preference for the name?
        Hide
        Otis Gospodnetic added a comment -

        Mind including an example properties file, so we can see what's in it?

        Show
        Otis Gospodnetic added a comment - Mind including an example properties file, so we can see what's in it?
        Hide
        Noble Paul added a comment -

        There is nothing specific in the properties .The user can choose to put in anything which he he would wish to replace in solrconfig/schema

        eg: solrcore.properties

        /#this variable can be directly used in the replication section of solrconfig.xml
        masterUrl=http://master_host:8080/solr/replication
        disableMaster=true
        

        This following is our usecase.
        The developer who prepares the solrconfig.xml does not know about the host in which it is going to be deployed. So he should just use placeholders in the solrconfig and leave a properties file to the operations. The operations edit the properties file according to the deployment.

        Show
        Noble Paul added a comment - There is nothing specific in the properties .The user can choose to put in anything which he he would wish to replace in solrconfig/schema eg: solrcore.properties /# this variable can be directly used in the replication section of solrconfig.xml masterUrl=http: //master_host:8080/solr/replication disableMaster= true This following is our usecase. The developer who prepares the solrconfig.xml does not know about the host in which it is going to be deployed. So he should just use placeholders in the solrconfig and leave a properties file to the operations. The operations edit the properties file according to the deployment.
        Hide
        Hoss Man added a comment -

        For a single-core the filenames are always hardcoded like solrconfig.xml and schema.xml. solrconfig.xml filename can be overridden from web.xml,

        ...and they can be overridden in solr.xml – that's my main points: you are adding a filewhose name is hardcoded and can't be changed under any circumstances. currently solr.xml is the only field with those kinds of rules, because the solrconfig.xml and schema.xml filenames can be specified in solr.xml.

        I also contest your claim that they are alwasy hardcoded for single cores ... we've been making definite progress down a path of encouraging people to use solr.xml even for single core setups, as you say...

        I wish the single core also becomes a multicore with one core and all these confusions can go away.

        ...i agree with you completley, but it's not going to happen overnight, and adding more hardcoded things like this is just a step backwards.

        Frankly: i don't even thing there should be a default name for this new properties file, i think that if you want Solr to load properties from a file for you, you should be required to use solr.xml, and specify a filename there – that would also give us the benefit of letting people specify multiple filenames (which is my other big concern about a single magic filename: there can be only one of them. for something like schema.xml or solrconfig.xml that's not the end of the world because merging multiple files doesn't even make much sense, but property files are extremly simple, and it should be just as easy to specify 37 of them as it is to specify 1.

        Do we really need to do it now because the properties file itself is optional and adding that to solr.xml can add to more clutter for a feature that is not widely used . Even if we add it later it is going to be backward compatible.

        If it's something we know we're going to want to do, and it's going to keep the code simpler in the long run, we might as well do it right the first time. there's already too much confusion between the distinction between the solr home dir, and the solr instance dir when dealing with solr.xml ... having a new magic filename just convolutes matters (looking at the code: i can't immediately tell, is the property file expected to be in the instanceDir, or the solr home? ... what if i have both?

        do we really have a choice here? Solr needs solr.solr.home to be set as a system property and all testcases follow this pattern

        There shouldn't be any need for a test to set the solr.solr.home system property ... the TestHarness already takes care of initializing the core with the appropriate home dir.

        (if for some reason this features tickles a bit of core initialization that doesn't work properly with the TestHarness then we should fix the TestHarness ... it's probably out of date with some of the EmbeddedSolr best practices anyway)

        Show
        Hoss Man added a comment - For a single-core the filenames are always hardcoded like solrconfig.xml and schema.xml. solrconfig.xml filename can be overridden from web.xml, ...and they can be overridden in solr.xml – that's my main points: you are adding a filewhose name is hardcoded and can't be changed under any circumstances. currently solr.xml is the only field with those kinds of rules, because the solrconfig.xml and schema.xml filenames can be specified in solr.xml. I also contest your claim that they are alwasy hardcoded for single cores ... we've been making definite progress down a path of encouraging people to use solr.xml even for single core setups, as you say... I wish the single core also becomes a multicore with one core and all these confusions can go away. ...i agree with you completley, but it's not going to happen overnight, and adding more hardcoded things like this is just a step backwards. Frankly: i don't even thing there should be a default name for this new properties file, i think that if you want Solr to load properties from a file for you, you should be required to use solr.xml, and specify a filename there – that would also give us the benefit of letting people specify multiple filenames (which is my other big concern about a single magic filename: there can be only one of them. for something like schema.xml or solrconfig.xml that's not the end of the world because merging multiple files doesn't even make much sense, but property files are extremly simple, and it should be just as easy to specify 37 of them as it is to specify 1. Do we really need to do it now because the properties file itself is optional and adding that to solr.xml can add to more clutter for a feature that is not widely used . Even if we add it later it is going to be backward compatible. If it's something we know we're going to want to do, and it's going to keep the code simpler in the long run, we might as well do it right the first time. there's already too much confusion between the distinction between the solr home dir, and the solr instance dir when dealing with solr.xml ... having a new magic filename just convolutes matters (looking at the code: i can't immediately tell, is the property file expected to be in the instanceDir, or the solr home? ... what if i have both? do we really have a choice here? Solr needs solr.solr.home to be set as a system property and all testcases follow this pattern There shouldn't be any need for a test to set the solr.solr.home system property ... the TestHarness already takes care of initializing the core with the appropriate home dir. (if for some reason this features tickles a bit of core initialization that doesn't work properly with the TestHarness then we should fix the TestHarness ... it's probably out of date with some of the EmbeddedSolr best practices anyway)
        Hide
        Noble Paul added a comment -

        I also contest your claim that they are alwasy hardcoded for single cores ... we've been making definite progress down a path of encouraging people to use solr.xml even for single core setups, as you say..

        Are we going to do thiat in 1.4 i.e solr.xml for single cores? But this properties file is a critical feature for our ops to deploy solr with replication feature. (The master server is only known at deploy time). currently we are shipping four different solrconfig.xml files

        I am not really worried about the specifics of how we implement this. My requirements are pretty simple

        • A core should be able to load properties from a properties file (any file name, any loaction is OK)
        • There should be one sensible default for that file name and location , just the way we have for schema and solrconfig

        What is your preference of doing this?

        Show
        Noble Paul added a comment - I also contest your claim that they are alwasy hardcoded for single cores ... we've been making definite progress down a path of encouraging people to use solr.xml even for single core setups, as you say.. Are we going to do thiat in 1.4 i.e solr.xml for single cores? But this properties file is a critical feature for our ops to deploy solr with replication feature. (The master server is only known at deploy time). currently we are shipping four different solrconfig.xml files I am not really worried about the specifics of how we implement this. My requirements are pretty simple A core should be able to load properties from a properties file (any file name, any loaction is OK) There should be one sensible default for that file name and location , just the way we have for schema and solrconfig What is your preference of doing this?
        Hide
        Erik Hatcher added a comment -

        Noble - why aren't system properties viable for this? The replication examples show master="$

        {master}

        " constructs, allowing a system property to set master versus slave.

        Show
        Erik Hatcher added a comment - Noble - why aren't system properties viable for this? The replication examples show master="$ {master} " constructs, allowing a system property to set master versus slave.
        Hide
        Noble Paul added a comment -

        Noble - why aren't system properties viable for this?

        • Setting system properties is error prone. If we have a few dozen properties setting -D for each property is hard. The startup scripts are maintained by operations whereas this properties file should be delivered by the developers. This is more about a separation of concern
        • System properties are global properties. we should not corrupt that namespace
        Show
        Noble Paul added a comment - Noble - why aren't system properties viable for this? Setting system properties is error prone. If we have a few dozen properties setting -D for each property is hard. The startup scripts are maintained by operations whereas this properties file should be delivered by the developers. This is more about a separation of concern System properties are global properties. we should not corrupt that namespace
        Hide
        Erik Hatcher added a comment -

        Error prone? I don't buy that. It's the same as setting a name in a .properties file - no more error prone than that.

        Startup scripts - these could delegate to a developer maintained subscript that set variables to be included in -D settings.

        Global properties - yes, but you can "namespace" them... -Dcore1name.master=false -Dcore2name.master=true kinda stuff.

        I'm not yet convinced the additional .properties feature is warranted.

        Show
        Erik Hatcher added a comment - Error prone? I don't buy that. It's the same as setting a name in a .properties file - no more error prone than that. Startup scripts - these could delegate to a developer maintained subscript that set variables to be included in -D settings. Global properties - yes, but you can "namespace" them... -Dcore1name.master=false -Dcore2name.master=true kinda stuff. I'm not yet convinced the additional .properties feature is warranted.
        Hide
        Noble Paul added a comment - - edited

        Error prone? I don't buy that. It's the same as setting a name in a .properties file - no more error prone than that.

        these properties files are separately shipped and the developer decides what are the properties.

        Global properties - yes, but you can "namespace" them... -Dcore1name.master=false -Dcore2name.master=true kinda stuff.

        is this clean?

        The system properties are available across the JVM . Why do you want a system wide property for something that is only used in solrconfig/schema? There is a chance of it conflicting with other system properties too.

        I do not see the reason against the properties. It is more like your ant script loading external properties from a properties file. Nobody is mandating the use of it . If one needs to clean up the deployment he is welcome to use it.

        Show
        Noble Paul added a comment - - edited Error prone? I don't buy that. It's the same as setting a name in a .properties file - no more error prone than that. these properties files are separately shipped and the developer decides what are the properties. Global properties - yes, but you can "namespace" them... -Dcore1name.master=false -Dcore2name.master=true kinda stuff. is this clean? The system properties are available across the JVM . Why do you want a system wide property for something that is only used in solrconfig/schema? There is a chance of it conflicting with other system properties too. I do not see the reason against the properties. It is more like your ant script loading external properties from a properties file. Nobody is mandating the use of it . If one needs to clean up the deployment he is welcome to use it.
        Hide
        Noble Paul added a comment -

        If it's something we know we're going to want to do, and it's going to keep the code simpler in the long run, we might as well do it right the first time.

        I'll propose this. Anyway we are planing to move to a stage where we will use solr.xml for single core as well. So I shall add the configuration of the properties in the <core> tag as follows

        <core name="foo" properties="conf/foo-core.properties" ... />
        

        For single core , let us fix a file name . So when we introduce solr.xml for single core it becomes automatically configurable

        Show
        Noble Paul added a comment - If it's something we know we're going to want to do, and it's going to keep the code simpler in the long run, we might as well do it right the first time. I'll propose this. Anyway we are planing to move to a stage where we will use solr.xml for single core as well. So I shall add the configuration of the properties in the <core> tag as follows <core name= "foo" properties= "conf/foo-core.properties" ... /> For single core , let us fix a file name . So when we introduce solr.xml for single core it becomes automatically configurable
        Hide
        Erik Hatcher added a comment -

        Along the same lines as making master/searcher determination through properties, it would be nice to be able to conditionally enable/disable, say, /update handler by some deploy-time switch. Noble - does it make sense to consider this type of use here?

        Show
        Erik Hatcher added a comment - Along the same lines as making master/searcher determination through properties, it would be nice to be able to conditionally enable/disable, say, /update handler by some deploy-time switch. Noble - does it make sense to consider this type of use here?
        Hide
        Lance Norskog added a comment -

        About the features for subsituting properties file:

        I have run multiple Solr instances (servlets) in the same container. Yes, multicore is the better way, but we shoud not force the user to have only one Solr per Tomcat . So, we should not force only one properties file via System.properties.

        I would ask that if a configuration file uses a properties file, that configuration file should have the ability to name its own properties file. For example, solrconfig.xml should have its own entry for adding properties files. But, if solrconfig.xml names a file the solr.xml should be able to override that file name. To do this, the properties files should be named.

        In conf/query_server.properties:

        fq.size=400
        

        In foo/conf/solrconfig.xml:

        <properties name="query_server">conf/query_server.properties</properties>
        

        Later in solrconfig.xml:

        <filterCache
          class="solr.FastLRUCache"
          size="${query_server.fq.size:512}"
          initialSize="512"
          autowarmCount="0"/>
        

        Then solr.xml can override the query_servers properties file. In solr.xml:

        <core name="foo">
            <properties name="query_server">${core}/conf/query_server_mini.properties</properties>
        </core>
        

        This just gets worse and worse

        Show
        Lance Norskog added a comment - About the features for subsituting properties file: I have run multiple Solr instances (servlets) in the same container. Yes, multicore is the better way, but we shoud not force the user to have only one Solr per Tomcat . So, we should not force only one properties file via System.properties. I would ask that if a configuration file uses a properties file, that configuration file should have the ability to name its own properties file. For example, solrconfig.xml should have its own entry for adding properties files. But, if solrconfig.xml names a file the solr.xml should be able to override that file name. To do this, the properties files should be named. In conf/query_server.properties: fq.size=400 In foo/conf/solrconfig.xml: <properties name= "query_server" > conf/query_server.properties </properties> Later in solrconfig.xml: <filterCache class= "solr.FastLRUCache" size= "${query_server.fq.size:512}" initialSize= "512" autowarmCount= "0" /> Then solr.xml can override the query_servers properties file. In solr.xml: <core name= "foo" > <properties name= "query_server" > ${core}/conf/query_server_mini.properties </properties> </core> This just gets worse and worse
        Hide
        Lance Norskog added a comment -

        About use cases for this feature:

        I would like to use this along with my strange baby, SOLR-1354. It would allow me to push all parameters for an RSS/ATOM feed into a separate configuration file. This way, to add an rss feed to a Solr instance requires editing a properties file and nothing else. (The larger goal is here to make it as easy as possible to make solr useful out of the box.)

        Another place where properties files would be very useful is in DIH scripts. When we want to load multiple shards from the same data source, we need different code for each shard. It would be great to have one master DIH file and a different properties file for each shard. Each properties file has a unique value to define the records for that shard.

        Show
        Lance Norskog added a comment - About use cases for this feature: I would like to use this along with my strange baby, SOLR-1354 . It would allow me to push all parameters for an RSS/ATOM feed into a separate configuration file. This way, to add an rss feed to a Solr instance requires editing a properties file and nothing else. (The larger goal is here to make it as easy as possible to make solr useful out of the box.) Another place where properties files would be very useful is in DIH scripts. When we want to load multiple shards from the same data source, we need different code for each shard. It would be great to have one master DIH file and a different properties file for each shard. Each properties file has a unique value to define the records for that shard.
        Hide
        Noble Paul added a comment -

        would be nice to be able to conditionally enable/disable, say, /update handler by some deploy-time switch

        it is not currently possible. I recommend adding an attribute to each of the plugins "enable as follows

        <requestHandler name="/upadate" enable="${update_enable:true}"/>
        

        specifying the properties file in solrconfig is not a good option because the properties has to be loaded before loading solrconfig.xml so that the variables are replaced at load time of solrconfig

        Show
        Noble Paul added a comment - would be nice to be able to conditionally enable/disable, say, /update handler by some deploy-time switch it is not currently possible. I recommend adding an attribute to each of the plugins "enable as follows <requestHandler name= "/upadate" enable= "${update_enable:true}" /> specifying the properties file in solrconfig is not a good option because the properties has to be loaded before loading solrconfig.xml so that the variables are replaced at load time of solrconfig
        Hide
        Noble Paul added a comment -
        • The properties filename is configurable from solr.xml on a per-core basis
        • The testcase is cleaned up
        Show
        Noble Paul added a comment - The properties filename is configurable from solr.xml on a per-core basis The testcase is cleaned up
        Hide
        Noble Paul added a comment -

        Please let me know if anyone wants to change anything about this feature before committing this

        Show
        Noble Paul added a comment - Please let me know if anyone wants to change anything about this feature before committing this
        Hide
        Lance Norskog added a comment -

        For future mantainability, please change:

        <core name="foo" properties="conf/foo-core.properties" ... />
        

        to:

        <core name="foo">
            <properties>conf/foo-core.properties</properties>
        </core>
        

        This allows us to have multiple properties files later.

        Show
        Lance Norskog added a comment - For future mantainability, please change: <core name= "foo" properties= "conf/foo-core.properties" ... /> to: <core name= "foo" > <properties> conf/foo-core.properties </properties> </core> This allows us to have multiple properties files later.
        Hide
        Noble Paul added a comment -

        both schema and config are specified as attributes. That is why I kept it as attribute. DO we really need to support multiple ?
        if necessary we can "overload" the existing "property" tag instead of introducing one

        <core name="foo">
            <property file="conf/foo.properties"/>
        </core>
        
        Show
        Noble Paul added a comment - both schema and config are specified as attributes. That is why I kept it as attribute. DO we really need to support multiple ? if necessary we can "overload" the existing "property" tag instead of introducing one <core name= "foo" > <property file= "conf/foo.properties" /> </core>
        Hide
        Erik Hatcher added a comment -

        Keep it as an attribute. If/when we need, we can simply make it support a comma-separated list of files.

        Show
        Erik Hatcher added a comment - Keep it as an attribute. If/when we need, we can simply make it support a comma-separated list of files.
        Hide
        Noble Paul added a comment -

        Keep it as an attribute. If/when we need, we can simply make it support a comma-separated list of files.

        +1

        Multiple properties is an uncommon case . As you mentioned we should be able to support it using a comma-separated values

        Show
        Noble Paul added a comment - Keep it as an attribute. If/when we need, we can simply make it support a comma-separated list of files. +1 Multiple properties is an uncommon case . As you mentioned we should be able to support it using a comma-separated values
        Hide
        Noble Paul added a comment -

        committed : r807914

        Show
        Noble Paul added a comment - committed : r807914
        Hide
        Artem Russakovskii added a comment -

        So, can someone comment on whether the single core setup (solrconfig.xml) supports referencing a properties file now? I'm not using multicore, like this bug's author, and after reading through the comments here, I'm still unclear on the single core solution.

        Ideally, solrxonfig.xml would contain a location of the properties file, which it would load prior to parsing everything else.

        Thanks.

        Show
        Artem Russakovskii added a comment - So, can someone comment on whether the single core setup (solrconfig.xml) supports referencing a properties file now? I'm not using multicore, like this bug's author, and after reading through the comments here, I'm still unclear on the single core solution. Ideally, solrxonfig.xml would contain a location of the properties file, which it would load prior to parsing everything else. Thanks.
        Hide
        Noble Paul added a comment -

        can someone comment on whether the single core setup (solrconfig.xml) supports referencing a properties file now

        yes, you can. The filename and location is fixed for single core. It should be $solr_home/conf/solrcore.properties

        Show
        Noble Paul added a comment - can someone comment on whether the single core setup (solrconfig.xml) supports referencing a properties file now yes, you can. The filename and location is fixed for single core. It should be $solr_home/conf/solrcore.properties
        Hide
        Artem Russakovskii added a comment -

        Paul, thank you. How funny - I was using nightly build from 8/25/09 and looks like the final commit was made on 8/26/09. Doh!

        So I verified $solr_home/conf/solrcore.properties as working, and it's good enough for us, but it'd be ideal if this location can be specified in solrconfig.xml, for example to be set to '$solr_home/..'. However,

        a) I'm not sure this is supported right now
        b) I think we came to a conclusion in another ticket that there's no value $solr_home that one can refer to from within solrconfig.xml (http://www.nabble.com/Solr,-JNDI-config,-dataDir,-and-solr-home-problem-td25286277.html and SOLR-1414), although it looks like you may have fixed it - is it accessible by $

        {solr.core.instanceDir}

        now?

        Show
        Artem Russakovskii added a comment - Paul, thank you. How funny - I was using nightly build from 8/25/09 and looks like the final commit was made on 8/26/09. Doh! So I verified $solr_home/conf/solrcore.properties as working, and it's good enough for us, but it'd be ideal if this location can be specified in solrconfig.xml, for example to be set to '$solr_home/..'. However, a) I'm not sure this is supported right now b) I think we came to a conclusion in another ticket that there's no value $solr_home that one can refer to from within solrconfig.xml ( http://www.nabble.com/Solr,-JNDI-config,-dataDir,-and-solr-home-problem-td25286277.html and SOLR-1414 ), although it looks like you may have fixed it - is it accessible by $ {solr.core.instanceDir} now?
        Hide
        Noble Paul added a comment -

        solr.home is not technically same as solr.core.instanceDir . it can be different in a multicore setup

        Show
        Noble Paul added a comment - solr.home is not technically same as solr.core.instanceDir . it can be different in a multicore setup
        Hide
        Artem Russakovskii added a comment -

        We're using single core.

        Show
        Artem Russakovskii added a comment - We're using single core.
        Hide
        Grant Ingersoll added a comment -

        Bulk close for Solr 1.4

        Show
        Grant Ingersoll added a comment - Bulk close for Solr 1.4

          People

          • Assignee:
            Noble Paul
            Reporter:
            Noble Paul
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development