+1 - if we can manage a more useful message, that would be a good improvement.
bq. and SolrDispatchFilter should get the highest priority in web.xml, so its loaded first. The problem is, we don't really control that - especially in the case when someone is just trying to suck up the war. - Mark On Apr 26, 2013, at 11:02 AM, "Uwe Schindler" <[email protected]> wrote: > Another idea: We should maybe change the ClassNotFoundException to something > that makes a useful message: > If you did not put a logging implementation outside into your servlet > container’s lib dir, then solr should fail to start and throw a usefull > Exception. Ideally this could be done on SolrDispatchFilter.init(), throwing > a ServletException explaining that you need a logging implementation! This > should be doable with some try-catch and initializing the logger in > SolrDispatchFilter.init() – and SolrDispatchFilter should get the highest > priority in web.xml, so its loaded first. > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: [email protected] > > From: Robert Muir [mailto:[email protected]] > Sent: Friday, April 26, 2013 4:56 PM > To: [email protected] > Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3 > > My problem is users will put the war in their container and get > ClassNotFoundExceptions. > > Instead they should get some basic system.out.println-logger or some no-op > implementation. > > 6 or 7 logging jars in our distribution and you are telling me it cant do > simple stuff like this? What is the point of the 6-7 jars then? > > On Fri, Apr 26, 2013 at 10:51 AM, Steve Molloy <[email protected]> wrote: > Have to agree with the not distributing 2 wars. But externalizing the logging > jars is a great improvement for people integrating it. Repackaging the war to > change logging framework to fit the rest of your code is far from being the > best option. Adding the proper slf4j jars in your container’s classpath makes > a lot more sense. > > Steve Molloy > Software Architect | Information Discovery & Analytics R&D > > <image001.gif> > > This email message is confidential, may be privileged, and is intended for > the exclusive use of the addressee. Any other person is strictly prohibited > from disclosing or reproducing it. If the addressee cannot be reached or is > unknown to you, please inform the sender by return email and delete this > email message and all copies immediately. > > From: Robert Muir [mailto:[email protected]] > Sent: April-26-13 10:16 AM > To: [email protected] > Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3 > > I am taking it up with them. Right now before its ever released. I don't > think our pmc should release two different solr-4.3.0.war files at different > download locations. And I think the war we do release, should work. > > On Apr 26, 2013 10:06 AM, "Yonik Seeley" <[email protected]> wrote: > On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir <[email protected]> wrote: > > On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley <[email protected]> wrote: > >> As to which WAR is correct, it's answered in the *first sentence* of > >> what I quoted: > >> "Slf4j/logging jars are no longer included in the Solr webapp" > > > > > > Thats not "the answer", just because its in CHANGES.txt > > *shrug* > I wasn't involved in that change, and I really don't care myself, but > it's 100% crystal clear that removing the logging jars from the WAR > was intentional (and hence the Maven artifacts are not as intended). > If you think that the decision was incorrect, then take it up with > those that made it. > > -Yonik > http://lucidworks.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
