[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846225#action_12846225
]
Mark Miller commented on SOLR-1817:
-----------------------------------
bq. why is "admin" suddenly a magic alias for "" in SolrDispatchFilter? (line
196)
Okay, looking closer, I think its this - if you go to a path for a core name eg
/solr/core1, and it there is no core, and so there where no errors, if its
drops in the there, the core name will change to "" - and at the bottom of
that method when it prints out the erorrs, it will get the errors for core "".
If if the default core couldnt load, any path that should get you a 404, will
actually show the default core errors.
That check is actually just there so that if you ask for solr/admin, you will
end up getting the "" core - so it makes sense to only allow it in if the
corename is admin anyway.
Though I have never really liked that logic where it looks for the admin core
and when it can't find it it drops to the "" core.
> Fix Solr error reporting to work correctly with multicore
> ---------------------------------------------------------
>
> Key: SOLR-1817
> URL: https://issues.apache.org/jira/browse/SOLR-1817
> Project: Solr
> Issue Type: Bug
> Affects Versions: 1.4
> Reporter: Mark Miller
> Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1817.patch, SOLR-1817.patch, SOLR-1817.patch
>
>
> Here is a rough patch that attempts to fix how error reporting works with
> multi-core (not in terms of logs, but what you see on an http request).
> The patch is not done - more to consider and havn't worked with how this
> changes solrconfigs abortOnConfigurationError, but the basics are here.
> If you attempt to access the path of a core that could not load, you are
> shown the errors that kept the core from properly loading.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
