On Mon, May 10, 2010 at 1:00 PM, Rajith Attapattu <[email protected]> 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 > <[email protected]> wrote: >> >>> -----Original Message----- >>> From: Gordon Sim [mailto:[email protected]] >>> Sent: 24 March 2010 18:59 >>> To: [email protected] >>> 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:[email protected] >> >> > > > > -- > 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:[email protected]
