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:
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.