You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2010/05/10 19:00:17 UTC
Re: Java Client Logging (yet again !)
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 )
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
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.
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
<ro...@gmail.com> wrote:
>
>> -----Original Message-----
>> From: Gordon Sim [mailto:gsim@redhat.com]
>> Sent: 24 March 2010 18:59
>> To: dev@qpid.apache.org
>> 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:dev-subscribe@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-subscribe@qpid.apache.org
Re: Java Client Logging (yet again !)
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, May 11, 2010 at 1:50 PM, Martin Ritchie
<ma...@gmail.com> wrote:
> 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 <ra...@gmail.com> 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 <ra...@gmail.com>
>> wrote:
>>>
>>> On Mon, May 10, 2010 at 1:00 PM, Rajith Attapattu <ra...@gmail.com>
>>> 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.
Ok fair enough, however then we need to make sure, we do not copy that
into our distributions.
Our distributions should just include the slf4j-api, which will (from
1.6.0 onwards) print a message and discard any subsequent logging if
no binding is detected.
>>>> 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 version
>>> 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
>>>> <ro...@gmail.com> wrote:
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Gordon Sim [mailto:gsim@redhat.com]
>>>>>> Sent: 24 March 2010 18:59
>>>>>> To: dev@qpid.apache.org
>>>>>> 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:dev-subscribe@qpid.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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:dev-subscribe@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
Re: Java Client Logging (yet again !)
Posted by Martin Ritchie <ma...@gmail.com>.
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 <ra...@gmail.com> 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
> <ra...@gmail.com> wrote:
>> On Mon, May 10, 2010 at 1:00 PM, Rajith Attapattu
>> <ra...@gmail.com> 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
>>> <ro...@gmail.com> wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Gordon Sim [mailto:gsim@redhat.com]
>>>>> Sent: 24 March 2010 18:59
>>>>> To: dev@qpid.apache.org
>>>>> 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:dev-subscribe@qpid.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Java Client Logging (yet again !)
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <ra...@gmail.com> wrote:
> On Mon, May 10, 2010 at 1:00 PM, Rajith Attapattu <ra...@gmail.com> 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 )
>>
>> 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
>>
>> 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.
>
> Ceki Gülcü has kindly brought to my attention, that from SLF4J version
> 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
>> <ro...@gmail.com> wrote:
>>>
>>>> -----Original Message-----
>>>> From: Gordon Sim [mailto:gsim@redhat.com]
>>>> Sent: 24 March 2010 18:59
>>>> To: dev@qpid.apache.org
>>>> 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:dev-subscribe@qpid.apache.org
>>>
>>>
>>
>>
>>
>> --
>> 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:dev-subscribe@qpid.apache.org
Re: Java Client Logging (yet again !)
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, May 10, 2010 at 1:00 PM, Rajith Attapattu <ra...@gmail.com> 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 )
>
> 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
>
> 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.
Ceki Gülcü has kindly brought to my attention, that from SLF4J version
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
> <ro...@gmail.com> wrote:
>>
>>> -----Original Message-----
>>> From: Gordon Sim [mailto:gsim@redhat.com]
>>> Sent: 24 March 2010 18:59
>>> To: dev@qpid.apache.org
>>> 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:dev-subscribe@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-subscribe@qpid.apache.org