lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (SOLR-5951) SolrDispatchFilter no longer displays useful error message on statup when logging jars are missing
Date Wed, 02 Apr 2014 23:29:14 GMT


ASF subversion and git services commented on SOLR-5951:

Commit 1584214 from [~thetaphi] in branch 'dev/branches/branch_4x'
[ ]

Merged revision(s) 1584213 from lucene/dev/trunk:
SOLR-5951: Fixed SolrDispatchFilter to throw useful exception on startup if SLF4j logging
jars are missing

> SolrDispatchFilter no longer displays useful error message on statup when logging jars
are missing
> --------------------------------------------------------------------------------------------------
>                 Key: SOLR-5951
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 4.7, 4.7.1
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 4.8, 5.0, 4.7.2
>         Attachments: SOLR-5951.patch
> We no longer have logging jars in the webapp since SOLR-3706. Because of this we added
a extra check in SolrDispatchFilter's ctor to print a nice exception if the logging jars were
failing. This check was unfortunately never tests and recently broke:
> The check delays initialization of the Logger instance to inside a try-catch block inside
the explicit ctor. If it fails with ClassNotFound, it throws Exception.
> Recently we upgraded to a newer HttpClient version. Unfortunately SolrDispatchFliter
also has an implicit constructor a few lines before the main constructor:
> {code:java}
>   protected final HttpClient httpClient = HttpClientUtil.createClient(new ModifiableSolrParams());
// <-- this breaks the detection
>   private static final Charset UTF8 = StandardCharsets.UTF_8;
>   public SolrDispatchFilter() {
>     try {
>       log = LoggerFactory.getLogger(SolrDispatchFilter.class);
>     } catch (NoClassDefFoundError e) {
>       throw new SolrException(
>           ErrorCode.SERVER_ERROR,
>           "Could not find necessary SLF4j logging jars. If using Jetty, the SLF4j logging
jars need to go in "
>           +"the jetty lib/ext directory. For other containers, the corresponding directory
should be used. "
>           +"For more information, see:",
>           e);
>     }
>   }
> {code}
> The first line above {{HttpClientUtil.createClient(new ModifiableSolrParams());}} breaks
the whole thing, because it is executed before the declared constructor. The user just sees
a ClassNotFoundEx at this line of code, the nice error message is hidden.
> Because this is so easy to break, we should make the whole thing more safe (any maybe
test it). 2 options:
> # Into the webapp add a fake Servlet (not bound to anything, just loaded first) that
does not use any Solr classes at all, nothing only plain java
> # Alternatively add a Superclass between ServletFilter and SolrDispatchFilter (pkg-private).
When the servlet container loads SolrDispatchFilter, it has in any case to first load the
superclass. And this superclass does the check and throws ServletException or whatever (no
Solr Exception) with the message from the current code.
> I tend to the second approach, because it does not need to modify web-inf. It will also
work with other Solr servlets, they must just extend this hidden class. I will provide a patch
for that.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message