[
https://issues.apache.org/jira/browse/SOLR-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-3032:
---------------------------------
Attachment: SOLR-3032.patch
OK, here's a first cut. The rule I tried to follow (and I need to go over it
again with fresh eyes) was that if an exception was re-thrown, logging was
unnecessary so I took it out.
As a bonus, SolrConfig.severeErrors is gone as is all the stuff around
CoreContainer.abortOnConfigurationError.
Most of this is unutterably boring, but take a look at SolrDispatchFilter, the
real changes are there.
I'll add deprecation notices to the 3x code, but won't change anything else
there.
I'm putting this out for comments. All tests pass, but I'm not sure tests do
much to deal with logging so that probably only proves that things compile.
I'll look this over again tomorrow, then I expcet I'll commit on Sunday/Monday
unless there are howls of protest.
And I just want to add that modern IDEs make this far too easy. "Back in MY
day", *real* programmers used *real* editors. See: http://xkcd.com/378/
> Deprecate logOnce from SolrException
> ------------------------------------
>
> Key: SOLR-3032
> URL: https://issues.apache.org/jira/browse/SOLR-3032
> Project: Solr
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Labels: exceptions, logging
> Fix For: 4.0
>
> Attachments: SOLR-3032.patch
>
>
> There seems to be a growing consensus (well, Muir and Hoss agree at least)
> that having this logOnce concept in SolrException is more trouble than it's
> worth. Point in case is that trunk (4x) fails to report anything useful in
> the log file when you define a custom component and don't have any <lib>
> statements going to the right place.
> So the proposal is to remove the whole logOnce process, supporting variables
> etc. The first step here will be deprecating the various bits of code in
> SolrException and starting to remove their usages.
> I'm opening this up for discussion, error reporting seems to be one of those
> things that generates endless discussion and I'd like them aired before
> putting too much work into this. My goal will be to have this in the code
> base by next Tuesday, so speak up.
--
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: [email protected]
For additional commands, e-mail: [email protected]
