Unfortunately thats not possible with SFL4J: The „simplicity” of this framework is based on the fact that the class path can only conatin *one* logging implementation. If we ship with one we are back at the problem that users had before, the one from the WAR file took preference.
The idea you had is not easily solveable, because you have no control on the classpath from inside the webapp (means at the time of loading the dispatch filter, the logging framework tries to initialize itself and you cannot change the *current* classloader so classes loaded later from the same webapp classloader will see the logging jar). So we can only stop working, but then with a good message. That’s the idea here. Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen <http://www.thetaphi.de/> http://www.thetaphi.de eMail: [email protected] From: Dyer, James [mailto:[email protected]] Sent: Friday, April 26, 2013 5:27 PM To: [email protected] Subject: RE: [VOTE] Lucene Solr 4.3.0 RC3 In the "catch", we could have it warn users that there is no external logging jar and then load a default implementation (commons-logging or even no-op). This would let users have a working .war if they do not include a logging jar but would make overriding this as easy as putting a logging jar in the classpath. James Dyer Ingram Content Group (615) 213-4311 From: Steve Molloy [mailto:[email protected]] Sent: Friday, April 26, 2013 10:05 AM To: [email protected] Subject: RE: [VOTE] Lucene Solr 4.3.0 RC3 That actually makes a lot of sense. J Steve Molloy Software Architect | Information Discovery & Analytics R&D <http://www.opentext.com/2/email-signature-logo> http://www.opentext.com/2/emailsupport-logo-opentext-2010.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: Uwe Schindler [mailto:[email protected]] Sent: April-26-13 11:03 AM To: [email protected] 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: [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 <http://www.opentext.com/2/email-signature-logo> http://www.opentext.com/2/emailsupport-logo-opentext-2010.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]
<<image001.gif>>
