lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Commented: (SOLR-689) rename multicore.xml solr.xml
Date Mon, 11 Aug 2008 02:01:44 GMT


Hoss Man commented on SOLR-689:

to be clear: with this patch as it stands, the current syntax, with all supported options,
  <multicore adminPath="/admin/multicore" persistent="true" sharedLib="/shared/lib">
    <core name="core0" instanceDir="core0" />
    <core name="core1" instanceDir="core1" />

moving "persistent" to the <solr> tag makes sense, it's impossible for it to be specific
only to the <multicore> block. 

renaming "adminPath" to "coreAdminHandler" makes sense ... i guess ... but i would think "coreAdminPath"
or "coreAdmin" or "adminPath" would still be better vernacular - we're not asking people to
specify a handler, we're asking them to specify a path.  The fact that it's a handler isn't
something they even need to know about, all they need to know is that this is the relative
URL for administer cores.

removing <multicore> gives me pause ... as a bit of future proofing it seems like it
would make sense to collect the list of cores into a common parent (so if, for some reason,
we add other stuff unrelated to the list of cores there is a clear delineation.  <cores>

How about...

<solr persistent="true" sharedLib="/shared/lib">
  <cores adminPath="/admin/multicore" >
    <core name="core0" instanceDir="core0" />
    <core name="core1" instanceDir="core1" />


> rename multicore.xml solr.xml
> -----------------------------
>                 Key: SOLR-689
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Hoss Man
>             Fix For: 1.3
>         Attachments: SOLR-689.patch
> Per mailing list discussion (see link below) it seems prudent to rename multicore.xml
to solr.xml prior to the 1.3 release.
> short summary of the main motivations for doing this...
> {noformat}
>    1) The name of the file corresponds with one specific way it can be
>       used, but may not be applicable to all usages (namely: you can
>       have a multicore.xml file but only use one core)
>    2) The "first" config file checked to determine the application's
>       behavior, and what paths will be checked for other config files
>       is named after one specific feature of the application. 
> {noformat}
> General consensus of the thread so far seems to be that this is a good idea, and gives
us more options for the future.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message