Patch up. https://issues.apache.org/jira/browse/SOLR-4771
- Mark On Apr 26, 2013, at 11:34 AM, Uwe Schindler <[email protected]> wrote: > 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 > 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 > > <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: 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 > 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]
