Since, there doesn't seem to be any objections, I will proceed with my plan in the evening.
Rajith On Mon, May 10, 2010 at 2:12 PM, Rajith Attapattu <rajit...@gmail.com> wrote: > On Mon, May 10, 2010 at 1:00 PM, Rajith Attapattu <rajit...@gmail.com> wrote: >> Sorry for allowing this thread to rot a bit. >> Based on all the comments we had so far, let me try to summarize on >> what we have seemed to reach some consensus. >> >> 1. We agreed that all though not shipping a slf4j binding is a >> plausible option, it does pose some challengers w.r.t running >> examples out of the box. >> 2. Most people disagreed about shipping our own plugging. >> 3. Shipping the slf4j-jdk1.4 a.k.a Java Logging binding was brought up >> as a possible solution. >> >> Based on the above, may I suggest the following. >> >> 1. Remove all log4j.xml and log4j.properties files from the code based >> (except for the ones in broker/etc ) >> >> 2. Remove the slf4j-log4j binding from java/lib >> >> 3. Put sl4j-log4j binding in the test-profiles/test-resources as our >> test output is configured using log4j and set the path in ant test. >> >> 4. Put sl4j-jdk1.4 binding in client/example/lib folder >> >> 5. Document clearly the logging mechanism in the >> "Programming-In-Apache-Qpid' guide. >> This should include how one could change to a different slf4j binding >> >> 6. Upstream packages could use a binding of their choice. >> >> 7. Eventually when when we ship bundles in Qpid that works out-of-box >> we could use the sl4j-jdk1.4 to ensure the logging works. > > Ceki Gülcü has kindly brought to my attention, that from SLF4J version > 1.6.0, if no binding is found, it will print the following message and > continue to discard the rest. > (Earlier it threw and exception). > > SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". > SLF4J: Defaulting to no-operation (NOP) logger implementation > SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for > further details. > > So we could probably ship our bundle (item 7) without any binding. > If the end user needs to do any sort of further debugging, then they > could download a binding of their choice and configure it the way they > like. > In our documentation we should provide information on how our logger > objects are configured, so they would know what to enable etc.. > > Rajith > >> Does this sound like a plan? If you see anything wrong or disagree, >> please shout. >> >> Regards, >> >> Rajith. >> >> On Wed, Mar 24, 2010 at 6:47 PM, Robbie Gemmell >> <robbie.gemm...@gmail.com> wrote: >>> >>>> -----Original Message----- >>>> From: Gordon Sim [mailto:g...@redhat.com] >>>> Sent: 24 March 2010 18:59 >>>> To: dev@qpid.apache.org >>>> Subject: Re: Java Client Logging (yet again !) >>>> >>>> On 03/23/2010 09:20 PM, Robbie Gemmell wrote: >>>> > Alternatively, shipping the JDK bindings by default could be a viable >>>> > option, working out the box but requiring that users actually >>>> > configure java.util.logging to required behaviour. >>>> >>>> I like this approach. >>>> >>>> It doesn't have to be in the same location as the core jars if that is >>>> felt to cause confusion. Perhaps e.g. bundled with examples or >>>> similar[1]. >>>> >>>> > I would think that anyone who doesn't care enough to configure the >>>> > logging at all might reasonably expect not to be too surprised to >>>> > find there are none, if they ever even looked at the logs. >>>> >>>> I think it can be frustrating for people trying to get familiar with >>>> the >>>> project to debug simple problems with packaged examples or tools if >>>> there is no logging available. >>>> >>>> Not everyone who ends up trying to get something working with the JMS >>>> client has experience with sl4j. Having to dig around on information on >>>> what to download, where to install it and then what format of file >>>> needs >>>> to be created is significantly harder than e.g. the python or c++ >>>> clients. Making that easier is in my view quite reasonable. Having at >>>> least warning level messages be visible is also a help. >>>> >>>> --Gordon >>>> >>>> [1] I always feel like there something missing on the java side when >>>> testing releases - no test app or examples to run. >>>> >>> >>> >>> We do actually have examples, but we don't currently ship them in the >>> standalone client bundle and they just get lost in the noise of the full >>> bundle, since the lib dir has such a vast number and mix of jars and it also >>> isn't that clear how to run/use them. I like Martin's suggestion for >>> shipping them as a side dir in the client bundle, and from there we could >>> make it clear how to leverage one or two of them as a specific test or first >>> time user example. >>> >>> I agree that having logging available easily is a good thing and is >>> obviously very useful for new people to the project to debug things. I just >>> don't think we should provide something that self configures the logging by >>> default, and don't think it is unreasonable to expect a user who wants >>> logging to do something as simple as pick which jar they wish to use for >>> bindings and specify a configuration. We should definitely make that simpler >>> than we do now though, I'm not saying they need to work these things out for >>> themselves from scratch, we can certainly provide example bindings and >>> configuration files to make it a trivial operation. >>> >>> Although not my first choice (which would be to supply no bindings in the >>> core client lib dir, but provide some alongside the libs with sample config >>> and clear 1 line instructions in the Readme on how to choose/configure one), >>> I could live with shipping the JDK logging bindings with the libs so that >>> you could use the bundle out of the box without doing _anything_ else, >>> albeit not actually getting any logging unless you specify a [provided >>> sample] property file to configure java.util.logging appropriately when >>> starting your client app's JVM. >>> >>> Robbie >>> >>> >>> --------------------------------------------------------------------- >>> Apache Qpid - AMQP Messaging Implementation >>> Project: http://qpid.apache.org >>> Use/Interact: mailto:dev-subscr...@qpid.apache.org >>> >>> >> >> >> >> -- >> Regards, >> >> Rajith Attapattu >> Red Hat >> http://rajith.2rlabs.com/ >> > > > > -- > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
