lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (SOLR-3753) Core admin and solr.xml documentation for 4.0 needs to be updated for 4.0 changes
Date Mon, 17 Sep 2012 17:39:08 GMT

     [ https://issues.apache.org/jira/browse/SOLR-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Hoss Man resolved SOLR-3753.
----------------------------

       Resolution: Fixed
    Fix Version/s: 5.0

I'm pretty sure i dealt with all of these in SOLR-3288.

The one comment i'm not clear on is this...

bq. In addition it appears that currently relative paths specified using "." or ".." are interpreted
as string literals. If that is not a bug, than this behavior needs to be documented. If it
is a bug, please let me know and I'll open another issue.

I'm not sure what you mean by "interpreted as string literals" ... I just did some testing
and confirmed that relative paths seemed to work properly -- perhaps your confusion is paths
are displayed as strings (ie: in log messages or in the Admin UI).  If you specify an absolute
path, then you see the absolute path.  but if you specify a relative path, then you see the
base path compbined with the relative path prior to resolving it to an asolute path, so the
user can see exactly how therelative path they specified is being used.  for example, this
is in the logs from my testing...

{noformat}
INFO: [other] Opening new SolrCore at solr/../../../../src-tgz/apache-solr-4.0.0-BETA/solr/example/solr/collection1/,
dataDir=solr/../../../../src-tgz/apache-solr-4.0.0-BETA/solr/example/solr/collection1/data/
{noformat}

in this case i configured a core with the instanceDir of "../../../../src-tgz/apache-solr-4.0.0-BETA/solr/example/solr/collection1/"
and i can see from the log that relative instanceDir is being resolved against the solr home
dir of "solr/".  This is how solr has reported file paths for a long time, i believe it was
a conscious choice made so that people could always know/understand *how* a final path was
chosen.

If this isn't what you ment, and you are seeing some other bug related to relative paths,
please open an issue with a specific example.

                
> Core admin and solr.xml documentation for 4.0 needs to be updated for 4.0 changes
> ---------------------------------------------------------------------------------
>
>                 Key: SOLR-3753
>                 URL: https://issues.apache.org/jira/browse/SOLR-3753
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 4.0-BETA
>            Reporter: Tom Burton-West
>            Assignee: Hoss Man
>             Fix For: 4.0, 5.0
>
>
> The existing documentation on Solr Cores needs to be updated to reflect changes in Solr
4.0
> If having at least one solr core declared is mandatory for Solr 4.0, that needs to be
stated in the release notes, in the example solr.xml file, and on the wiki page for CoreAdmin.
http://wiki.apache.org/solr/CoreAdmin.
> In the absence of a solr.xml file, current 4.0 behavior is to use defaults declared in
 CoreContainer.java.  This needs to be documented; probably in solr.xml and/or on the CoreAdmin
page.  (See line 94 of CoreAdmin.java where the default name "collection1" is declared.  Without
this documentation, users can get confused about where the "collection1" core name is coming
from. (I'm one of them).
> The solr.xml file states that paths are relative to the "installation directory" This
needs to be clarified.  In addition it appears that currently relative paths specified using
"." or ".." are interpreted as string literals.  If that is not a bug, than this behavior
needs to be documented.  If it is a bug, please let me know and I'll open another issue.
>  
> The  example/solr/README.txt  Needs to clarify which files need to be in Solr Home and
which files are mandatory or optional in the directories containing configuration files (and
data files) for Solr cores.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message