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
