Yeah. I want to "catch" the common case. Somebody downloads the war from Maven and deploys it in his Tomcat. In that case the message should be displayed on SolrDispatchFilter startup. If the other servlets in Solr don’t use a logging impl, we are fine... Otherwise we can make some class LogInitializer and that’s used from all servlets to instantiate the logging framework for the private "log" field.
----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Mark Miller [mailto:[email protected]] > Sent: Friday, April 26, 2013 5:14 PM > To: [email protected] > Subject: Re: [VOTE] Lucene Solr 4.3.0 RC3 > > +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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
