@Jan:
my grand realization recently was that all that's totally under the
control of the user. If I put something like
<str name="dataDir">${solr.data.dir:.}</str>
then the sys prop you need to specify at startup is, you guessed it,
-Dsolr.data.dir... Or I'm misunderstanding your commet. There are some
crazy "implicit properties" that are hard-coded this way
(solr.blahblah) which were being persisted mistakenly just to add
confusion to the issue. You can still define them though....About SOLR-4495. Actually, sounds like a reasonable idea. I'd prefer to have some syntax that doesn't require multiple tags at this point, possibly semi-colon separated? I'll be happy to work with you on that one, but I won't be able to carry much of that load for a couple of months at least. Versioning solr.xml seems, off the top of my head, to be a Good Thing, how about raising a JIRA (Yeah, I'm lazy today). So far we should be OK, since anything without a version tag is automatically generation 1.... @Tomás: Yeah, I agree. So far I've just been copying things I've found in various places, things are a bit out of synch here in terms of what's used for which...... On Fri, Apr 19, 2013 at 9:56 AM, Tomás Fernández Löbbe <[email protected]> wrote: > It would be useful to have in the core.properties description, which of > those properties are required in which situation (e.g. "required when using > SolrCloud"), and all the default values. > > > On Fri, Apr 19, 2013 at 10:07 AM, Jan Høydahl <[email protected]> wrote: >> >> Could you remove sharedLib and instead allow multiple <lib>my/path</lib> >> tags similar to in solrconfig.xml? See SOLR-4495 >> >> +1 to prefixing sys.props with "solr." as we've done so far with >> solr.solr.home, solr.data.dir etc. >> >> Q: Should solr.xml be versioned as well, to handle future deprecation, >> back-compat etc? >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> Solr Training - www.solrtraining.com >> >> 15. apr. 2013 kl. 03:06 skrev Erick Erickson <[email protected]>: >> >> > Mark: >> > >> > OK, updated the example, I'd appreciate a quick glance to see if I put >> > the right properties in the solrcloud tag. Code fixes coming. >> > >> > On Sun, Apr 14, 2013 at 8:57 PM, Erick Erickson >> > <[email protected]> wrote: >> >> bq: What happened to the SolrCloud section? >> >> >> >> It wasn't in the bits I cut-n-pasted, so I didn't include it at all. >> >> Sheeesh! I'll fix, thanks for looking. It's amazing what I can fail to >> >> see. >> >> >> >> bq: sub-properties file >> >> >> >> Sounds like this is also really SOLR-4546, so maybe that's coming back? >> >> >> >> Erick >> >> >> >> On Sun, Apr 14, 2013 at 1:28 PM, Mark Miller <[email protected]> >> >> wrote: >> >>> >> >>> On Apr 14, 2013, at 11:42 AM, Erick Erickson <[email protected]> >> >>> wrote: >> >>> >> >>>> I've started a new page here: >> >>>> >> >>>> It's completely rudimentary, but I wanted to get it started so as >> >>>> many >> >>>> eyes as possible can get on it. See: >> >>>> http://wiki.apache.org/solr/Solr.xml%204.3%20and%20beyond >> >>> >> >>> What happened to the SolrCloud section? I think that's a very helpful >> >>> division. >> >>> >> >>>> >> >>>> Question: >> >>>> With the new style, does allowing cores.properties to specify an >> >>>> alternate instanceDir make any sense? I don't think so. >> >>> >> >>> Right, I don't either. These will be autodiscovered from a root >> >>> location, not specified or overridable individually. >> >>> >> >>>> >> >>>> What about the sub-properties file ('properties' property). >> >>> >> >>> I'd have to look to comment. Not familiar with that one. >> >>> >> >>> - Mark >> >>> >> >>>> >> >>>> Erick >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: [email protected] >> >>>> For additional commands, e-mail: [email protected] >> >>>> >> >>> >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: [email protected] >> >>> For additional commands, e-mail: [email protected] >> >>> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
