That actually makes a lot of sense. ☺ Steve Molloy Software Architect | Information Discovery & Analytics R&D [http://www.opentext.com/2/emailsupport-logo-opentext-2010.gif]<http://www.opentext.com/2/email-signature-logo>
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: Uwe Schindler [mailto:u...@thetaphi.de] Sent: April-26-13 11:03 AM To: dev@lucene.apache.org Subject: RE: [VOTE] Lucene Solr 4.3.0 RC3 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<http://www.thetaphi.de/> eMail: u...@thetaphi.de<mailto:u...@thetaphi.de> From: Robert Muir [mailto:rcm...@gmail.com] Sent: Friday, April 26, 2013 4:56 PM To: dev@lucene.apache.org<mailto:dev@lucene.apache.org> 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 <smol...@opentext.com<mailto:smol...@opentext.com>> 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 [http://www.opentext.com/2/emailsupport-logo-opentext-2010.gif]<http://www.opentext.com/2/email-signature-logo> 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:rcm...@gmail.com<mailto:rcm...@gmail.com>] Sent: April-26-13 10:16 AM To: dev@lucene.apache.org<mailto:dev@lucene.apache.org> 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" <yo...@lucidworks.com<mailto:yo...@lucidworks.com>> wrote: On Fri, Apr 26, 2013 at 9:36 AM, Robert Muir <rcm...@gmail.com<mailto:rcm...@gmail.com>> wrote: > On Fri, Apr 26, 2013 at 9:34 AM, Yonik Seeley > <yo...@lucidworks.com<mailto:yo...@lucidworks.com>> 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: dev-unsubscr...@lucene.apache.org<mailto:dev-unsubscr...@lucene.apache.org> For additional commands, e-mail: dev-h...@lucene.apache.org<mailto:dev-h...@lucene.apache.org>
<<inline: image001.gif>>
