The standalone client release bundle currently doesn't ship with any logging bindings. The 'java bundle' ships the Log4J jar itself because the broker needs it, but the slf4j-log4j binding needn't be included either except for provisioning of some sort of bindings for use in test runs, which as you say could as easily be pulled in from somewhere else.
The codebase can and should be cleared of log4j.xml and log4j.properties files. Some can simply be removed, others could just be renamed so that they are available if desired but not used just as a result of Log4J finding them on the classpath. I don't think we should be writing our own Qpid binding, and certainly not supplying it as the default. I don't see why anyone would wish to use our noddy custom binding over one of the several entrenched options, I certainly wouldn't, and by including our own we just make anyone who wishes to use one of the mainstream options then have to remove it. Downstream apps and packages should have their logging configured as required by their own maintainers, it isn't really our place to do it for them. The SL4J FAQ points out their belief that libraries should not be dealing with logging configuration and it should be left to users. SLF4J ship 4 binding options of their own (JDK logging, Simple, Log4J, and Logback) that cover a range of options, and there are of course several others besides those. If we wish to make it easier for really lazy users we could simply include a selection the existing bindings and some example configurations alongside the client libs (not actually in the lib dir where they would be picked up by default, since SLF4J also throws exceptions if multiple bindings are found) with a 1 line instruction on how to choose one, and then let them drop in whichever jar suits their needs. 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 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. Robbie > -----Original Message----- > From: Rajith Attapattu [mailto:rajit...@gmail.com] > Sent: 23 March 2010 14:16 > To: dev@qpid.apache.org > Subject: Re: Java Client Logging (yet again !) > > Ok the discussion veered a bit off topic. > So claiming it back and trying to summarize the related discussion for > folks who still didn't get a chance to respond due to being on > vacation etc. > > Issues > --------- > 1. Shipping the log4j binding is really defeating the purpose of our > logging abstraction, not to mention the perf impact it creates if > logging is not configured properly. > 2. As mentioned if not configured properly log4j defaults to debug. > 3. There is no sane way to configure log4j. I admit my attempt to have > a log4j.xml in the client module was no better than what we had > before. > 4. Our code is littered with log4j.xml and log4j.property files that > could screw up an end users logging setup based on classpath magic. > > Solutions > ------------ > 1. Not to ship any slf4j binding - ( several objected as things are > expected to work out of the box) > 2. Ship slf4j simple binding which defaults to INFO > 3. Ship our own binding which defaults to WARN and prints a warning > message at the begining asking to configure their own logging if they > want to. > > ** We should also remove all the log4j files (except in the broker etc > folder) > ** For testing we will have a log4j file and load the log4j jar from > the test resources folder. > > Option 3 has support from most folks I spoke to. > > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ > > On Mon, Mar 8, 2010 at 7:41 PM, Rajith Attapattu <rajit...@gmail.com> > wrote: > > On Mon, Mar 8, 2010 at 6:09 PM, Rafael Schloming <rafa...@redhat.com> > wrote: > >> Rajith Attapattu wrote: > >>> > >>> On Mon, Mar 8, 2010 at 3:16 PM, Rafael Schloming > <rafa...@redhat.com> > >>> wrote: > >>>> > >>>> Robbie Gemmell wrote: > >>>>>> > >>>>>> 3. From the next release we need to ship separate binaries for > the > >>>>>> broker, client and management bits. > >>>>> > >>>>> We already do release separate bundles for pretty much everything > >>>>> (Client, > >>>>> Broker, QMan[management-client], and JMX Management Consoles). > From the > >>>>> next > >>>>> release I would suggest that we stop shipping the 'java bundle' > binary > >>>>> which > >>>>> mashes most of those contents together. > >>>> > >>>> I'm not really a big fan of not shipping the bundle. > >>>> > >>>> I think users who OEM the client want to clearly understand what > it's > >>>> dependencies are and obviously want them as minimal as possible, > and I > >>>> certainly think this is an important usage scenario to > accommodate, > >>>> however > >>>> I think a large part of that can be achieved without having a > client-only > >>>> download, and I think it's important to recognize that it's not > our only > >>>> usage scenario. > >>>> > >>>> Now I'm not really against having a client only download, but I do > think > >>>> the > >>>> bundle should be kept, and in fact should really be thought of as > the > >>>> primary download for the simple reason that a client-only download > is > >>>> actually quite useless to most of our prospective users because > you can't > >>>> actually do anything useful with the client unless you have a > broker > >>>> somewhere, and even then I doubt you'll get very far without some > >>>> management > >>>> tools for simple diagnostics. > >>> > >>> While I agree with you that having the bundle is important, I'd > also > >>> think it's equally important (if not more going forward) having > >>> separate binaries for the client and management tools. > >>> I believe we should offer both. > >>> Increasingly we see our user base mixing and matching components. > >>> All though one might be interested in the JMS client, their choice > of > >>> broker maybe C++ due to a variety of reasons. > >>> Also we already have use cases where the Java management > >>> tools/libraries are used against the c++ broker. > >>> And since the Java broker now supports QMF, there will be users who > >>> may want to use the python management tools/API instead of the java > >>> based tools. > >>> People may even mix and match components btw projects going forward > as > >>> that is one of the goals of AMQP. > >> > >> Part of my point is that we need to distinguish between downloaders > and > >> users. A first-time evaluator of our project really just wants to > download > >> something that works out of the box. I think when you get into > mixing and > >> matching, that is really something for more established/serious > users. > > Fair point ! > > > >>> IMO we offer three main categories of products, namely AMQP enabled > >>> "Brokers", "Client" and "Management Tools". > >>> Therefore where possible we should **also** allow people to > download > >>> individual components. > >> > >> As I said before I don't disagree with providing separate bundles, I > just > >> don't think it is the audience we should be advertising to on the > download > >> page. > >> > >> I also feel that a broker only download is particularly useless as > you can't > >> even do something as basic as getting a list of defined queues or > exchanges > >> without getting the management tools, and while we may be somewhat > numb to > >> how odd this is because we've accepted it for so long, I think if > you put > >> yourself in the mind of someone new to qpid, it makes our download > artifacts > >> particularly frustrating and unfriendly. > >> > >>>> Contrast this to a download that includes the broker, the client, > some > >>>> basic > >>>> diagnostic/management tools, and some working examples, and I > think our > >>>> potential users will have a much nicer out-of-the-box experience > with a > >>>> bundle. > >>> > >>> I definitely see a value in providing a bundle. > >>> But I don't think downloading components separately (especially if > >>> mixing and matching btw language impls) will in anyway lead to a > >>> lesser experience than using a bundle. > >>> It all depends on what they want. If they want to mix and match > >>> components, then not providing that option will definitely impact > >>> their experience as they will have to resort building from source. > >> > >> I actually think a reasonable bundle would need to include more than > one > >> language impl since the management tools are in python (and require > the > >> python client), and IMHO they should come with the brokers. > > > > I agree with you here. > > I think you made a good point about first time evaluators vs > > experienced users who would be using Qpid in development etc. > > > > From a first time users perspective I can definitely understand the > > value of downloading something and getting it to work out of the box. > > And I agree that this is an area that we haven't really paid much > attention too. > > > > Ideally a broker download should accompany the client libs, > management > > tools and examples (that interop) along with documentation. > > That would no doubt help a new user tremendously. > > > >> Likewise a compelling out-of-the box example should really show > interop > >> between clients in all the different languages. > > > >> Either way though, I don't think you would ever need to build > anything from > >> source. Assuming a sanely organized bundle, it's really just a > tradeoff > >> between requiring a first time user to download as many as six > different > >> components to get a full working system, vs requiring an established > user to > >> download the bundle and pull out just the part he cares about. > >> > >> Obviously once you have such a sanely organized bundle it is trivial > to pull > >> out the components and offer them as well, but my point is really > that the > >> focus should be on defining the bundle, because if we think about > each > >> component separately, then we're going to end up with many different > >> components that are useless in isolation, yet don't really fit > together in > >> an obvious way. > >> > >> --Rafael > >> > >> -------------------------------------------------------------------- > - > >> 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/ > > --------------------------------------------------------------------- > 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
