[
https://issues.apache.org/jira/browse/SOLR-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621328#action_12621328
]
Ryan McKinley commented on SOLR-689:
------------------------------------
+1
whats up with the // bit in:
{code:java}
- persistent = cfg.getBool( "multicore/@persistent", false );
- adminPath = cfg.get( "multicore/@adminPath", null );
- libDir = cfg.get( "multicore/@sharedLib", null);
+ persistent = cfg.getBool( "//multicore/@persistent", false );
+ adminPath = cfg.get( "//multicore/@adminPath", null );
+ libDir = cfg.get( "//multicore/@sharedLib", null);
{code}
is that just safer since we may not be at the root?
> rename multicore.xml solr.xml
> -----------------------------
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> 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.
> http://www.nabble.com/Rename-multicore.xml---to18877268.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
