> -----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]
