Martin, Thanks for the reply. I really appreciate.
I was also tempted to ship with no binding + very clear docs. But having something work out of the box is a requirement. I think the client bundle you proposed has a lot of merit on it's own and something that we should get going in the next release or so. However I don't think the client binding is going to solve the logging problem in all cases. Especially for downstream packages. Sometimes people want to install only the client package instead of the examples. In that case the client will not work as it will complain about the missing binding. That is why I think our own binding with a clear message is probably best. It can be created with minimal effort (just 2-3 classes). As it will work with all situations. I also totally agree with you about the content we log. At some point we need to go through the code and work on our logging to make it more useful. In addition to the actual content, we also need to pay close attention to how we classify the log messages. Regards, Rajith On Tue, Mar 23, 2010 at 3:49 PM, Martin Ritchie <ritch...@apache.org> wrote: > Hi Rajith, > > Appologies for not replying sooner. Now that I'm off on holiday it seems I > have time to reply. > > Also appologies for top posting the iPhone screen is a bit small for this > sort of email, the iPad will remidy that I'm sure, anyway on to the dillema > of logging. > > Totally agree that we need to purge our code base of log4j files with > default names and slf4j binding jars they are not integration friendly. > > I would actually be in favour of option 1, no slf4j bindings but I agree > that we need functional packages. > > That is why I think whatever we decide to bundle ultimately some form of > client bundle should contain a directory of libs and some documentation > explaining that these are the required libs to drop in to your app or app > server lib directory. To make this actually useful out of the bundle the > examples should be built and included in the bundle some thing like: > > Bundle: > Client > Docs > Libs > ReadMe > Examples > Bin > Docs > Lib > ReadMe > ... > > Now I'm not suggesting that the bundle should just be the client but I think > this combination of client + examples should be thought of as a functional > unit. > > We can use the examples to highlight how to configure logging, be that with > log4j or some thing else. > > This is an easy win for us right now as users get first rate examples of how > to configure Qpid and a working usable bundle. Though as Rafi points out we > may want to include the broker in the bundle. That though is for another > conversation. > > To respond to your other options briefly. I really don't think we should be > including any binding let alone writting our own, at least not in the client > lib dir. The client lib dir should be the absolute minimum required for > integration. An explination via docs, readme and the examples should make it > clear you need a binding. > > The fact that log4j defaults to debug is an issue for the log4j team. Most > of the Apache components I've used use log4j or slf4j and they all require > configuration to be useful. Those teams realise that they are a component > and don't try and force the end user into one implementation but highlight > the bindings and/or configuration are required. > > All that said I do think the actual content we are logging leaves a lot to > be desired. I have done some work recently on the Java broker to make its > logging more useful from the view of monitoring a running system. > > To that end a new set of defined numbered messages were created and whilst > they use the broker's default log4j configuration, when enabled the logging > actively forces the messages to be logged, turning on the log4j levels as > required. We can reconfigure it to use an alternative logger if required but > the key is that te logging provides useful state information for a user not > the developer focused logging we had before. > > I have not yet had time to investigate however doing something similar to > the client would be hugely benificial. This level of logging we could safely > leave enabled by default without adversley affecting performance. If we had > this then I could see the benefit of having our own logging layer so we can > default on our sensible status messages and ensure they are logged to the > correct location as defined by our user's logging binding. > > Just in case I wasn't clear I think we should be clearing out the log4j > config (issue 4), accept that issue 2 'debug by default' is the accepted > solution if using log4j. To combat this we should ensure we have the client > packaged without bindings but include the examples to provide instant > utility and explain/show how to correctly configure logging. Using this > approach we could demos number of logging options i.e. log4j, jdk logging, > slf4j simple, etc. > > > Cheers > > Martin > > > -- Martin > > Sent from my iPhone > > On 23 Mar 2010, at 14:15, Rajith Attapattu <rajit...@gmail.com> wrote: > >> 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 > > -- 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
