On Tue, May 11, 2010 at 1:50 PM, Martin Ritchie <martin.a.ritc...@gmail.com> wrote: > Sorry for late response I seem to be unable to access gmail at work just > now. > > -- > Martin > > Sent from my iPhone > > On 11 May 2010, at 17:59, Rajith Attapattu <rajit...@gmail.com> wrote: > >> 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 ) > > Sounds good > >>>> 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 > > I don't see why you want to move the jar from our lib dir. Curretly java/lib > is where all our 3rd party jars live. I think it would be beat to keep them > all on the same place.
Ok fair enough, however then we need to make sure, we do not copy that into our distributions. Our distributions should just include the slf4j-api, which will (from 1.6.0 onwards) print a message and discard any subsequent logging if no binding is detected. >>>> 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. > > We can ship bundles now, we just nee to choose to. I'll make some builds up > tonight so we can talk about concrete artifacts. > > >>> 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 >> > > --------------------------------------------------------------------- > 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/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
