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
