Sorry for late response I seem to be unable to access gmail at work
just now.
--
Martin
Sent from my iPhone
On 11 May 2010, at 17:59, Rajith Attapattu <[email protected]> wrote:
Since, there doesn't seem to be any objections, I will proceed with my
plan in the evening.
Rajith
On Mon, May 10, 2010 at 2:12 PM, Rajith Attapattu
<[email protected]> wrote:
On Mon, May 10, 2010 at 1:00 PM, Rajith Attapattu
<[email protected]> wrote:
Sorry for allowing this thread to rot a bit.
Based on all the comments we had so far, let me try to summarize on
what we have seemed to reach some consensus.
1. We agreed that all though not shipping a slf4j binding is a
plausible option, it does pose some challengers w.r.t running
examples out of the box.
2. Most people disagreed about shipping our own plugging.
3. Shipping the slf4j-jdk1.4 a.k.a Java Logging binding was
brought up
as a possible solution.
Based on the above, may I suggest the following.
1. Remove all log4j.xml and log4j.properties files from the code
based
(except for the ones in broker/etc )
Sounds good
2. Remove the slf4j-log4j binding from java/lib
3. Put sl4j-log4j binding in the test-profiles/test-resources as our
test output is configured using log4j and set the path in ant test.
4. Put sl4j-jdk1.4 binding in client/example/lib folder
I don't see why you want to move the jar from our lib dir. Curretly
java/lib is where all our 3rd party jars live. I think it would be
beat to keep them all on the same place.
5. Document clearly the logging mechanism in the
"Programming-In-Apache-Qpid' guide.
This should include how one could change to a different slf4j
binding
6. Upstream packages could use a binding of their choice.
7. Eventually when when we ship bundles in Qpid that works out-of-
box
we could use the sl4j-jdk1.4 to ensure the logging works.
We can ship bundles now, we just nee to choose to. I'll make some
builds up tonight so we can talk about concrete artifacts.
Ceki Gülcü has kindly brought to my attention, that from SLF4J ver
sion
1.6.0, if no binding is found, it will print the following message
and
continue to discard the rest.
(Earlier it threw and exception).
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for
further details.
So we could probably ship our bundle (item 7) without any binding.
If the end user needs to do any sort of further debugging, then they
could download a binding of their choice and configure it the way
they
like.
In our documentation we should provide information on how our logger
objects are configured, so they would know what to enable etc..
Rajith
Does this sound like a plan? If you see anything wrong or disagree,
please shout.
Regards,
Rajith.
On Wed, Mar 24, 2010 at 6:47 PM, Robbie Gemmell
<[email protected]> wrote:
-----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]
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
--
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:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
