[
https://issues.apache.org/jira/browse/SOLR-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184262#comment-13184262
]
Erick Erickson commented on SOLR-3022:
--------------------------------------
Looking at this a bit more, there are a couple of issues:
It looks like the change in behavior is a results of deprecating
SolrConfig.severeErrors. Specifically, there is a bit of code in
SolrDispatchFilter that prints out the severeErrors if:
if( abortOnConfigurationError && SolrConfig.severeErrors.size() > 0 ){
print stuff
}
Well, aborgOnConfigurationError is also deprecated with the comment:
@deprecated all cores now abort on configuration error regardless of
configuration
But apparently they no longer print out the stack trace that is helpful. And
the line in 3x solrconfig.xml that set abortOnConfigurationError=true has been
removed so it defaults to false. But even when true, printStackTrace doesn't
print out on trunk, I don't quite know why. I hacked some stuff and going into
that loop and printing out getMessage() from every Throwable in that collection
*does* print a message. But I'm not going to worry about that now...
I wonder it this is related to this deprecation comment in SolrConfig.xml for
severeErrors:
"@deprecated All exceptions encountered during config parsing are now thrown by
the respective constructors, preventing initialization."
*********
The other issue is that two SolrException c'tors hard code "logged=true", which
puzzles me:
public SolrException(ErrorCode code, Throwable th) {
super(th);
this.code=code.code;
logged=true; <== what?
}
Would it make more sense to do something like:
if (th instanceof SolrException) {
logged = ((SolrExcption)th).logged;
} else {
logged = true;
}
And something similar for the other constructor that hard-codes true that has
this signature:
public SolrException(ErrorCode code, String msg, Throwable th)
and let the default value of false stand otherwise? I could easily be persuaded
that the else clause should be removed......
Although this code hasn't changed since 3.x days, it still seems questionable
to hard-code this to true.
Anyway, the net-net of this is that we've lost some useful information. I'm not
entirely comfortable with changing the constructors for SolrException to remove
the hard-coded "true" without running it by folks. I would argue that doing
what I outlined above makes sense, and if that results in more stack traces
than we want people should use the c'tor that sets the logged value. What do
you think?
> AbstractPluginLoader does not log caught exceptions
> ---------------------------------------------------
>
> Key: SOLR-3022
> URL: https://issues.apache.org/jira/browse/SOLR-3022
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: James Dyer
> Assignee: Erick Erickson
> Priority: Trivial
> Fix For: 4.0
>
> Attachments: SOLR-3022.patch
>
>
> I was setting up a new 4.x environment but forgot to put a custom Analyzer in
> the classpath. Unfortunately AbstractPluginLoader didn't log the exception
> and it took a long time for me to figure out why "No cores were created".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
