[Math] Utilitzation of SLF4J?

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[Math] Utilitzation of SLF4J?

ole ersoy
Hello,

We have been discussing various ways to view what's happening internally with algorithms, and the topic of including SLF4J has come up.  I know that this was discussed earlier and it was decided that CM is a low level dependency, therefore it should minimize the transitive dependencies that it introduces.  The Java community has adopted many means of dealing with potential logging conflicts, so I'm requesting that we use SLF4J for logging.

I know that JBoss introduced its own logging system, and this made me a bit nervous about this suggestion, so I looked up strategies for switching their logger out with SLF4J:
http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j

The general process I go through when working with many dependencies that might use commons-logging instead of SLF4J looks something like this:
http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi

With JDK9 individual modules can define their own isolated set of dependencies.  At this point the fix should be a permanent.  If someone has has a very intricate scenario that we have not yet seen, they could use (And probably should use) OSGi to isolate dependencies.

WDYT?

Cheers,
- Ole


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Thomas Neidhart
Hi Ole,

for a start, I think you are asking the wrong question.
First of all we need to agree that we want to add some kind of logging
facility to CM.
If the outcome is positive, there are a handful of alternatives, some of
them more viable than slf4j in the context of CM (e.g. JUL or
commons-logging).

btw. the same discussion has been done for other commons components as
well, and the result usually was: do not add logging

Thomas


On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]> wrote:

> Hello,
>
> We have been discussing various ways to view what's happening internally
> with algorithms, and the topic of including SLF4J has come up.  I know that
> this was discussed earlier and it was decided that CM is a low level
> dependency, therefore it should minimize the transitive dependencies that
> it introduces.  The Java community has adopted many means of dealing with
> potential logging conflicts, so I'm requesting that we use SLF4J for
> logging.
>
> I know that JBoss introduced its own logging system, and this made me a
> bit nervous about this suggestion, so I looked up strategies for switching
> their logger out with SLF4J:
>
> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>
> The general process I go through when working with many dependencies that
> might use commons-logging instead of SLF4J looks something like this:
>
> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>
> With JDK9 individual modules can define their own isolated set of
> dependencies.  At this point the fix should be a permanent.  If someone has
> has a very intricate scenario that we have not yet seen, they could use
> (And probably should use) OSGi to isolate dependencies.
>
> WDYT?
>
> Cheers,
> - Ole
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Gilles Sadowski
On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:

> Hi Ole,
>
> for a start, I think you are asking the wrong question.
> First of all we need to agree that we want to add some kind of
> logging
> facility to CM.
> If the outcome is positive, there are a handful of alternatives, some
> of
> them more viable than slf4j in the context of CM (e.g. JUL or
> commons-logging).

Could someone summarize why those alternatives were deemed "more
viable"?

> btw. the same discussion has been done for other commons components
> as
> well, and the result usually was: do not add logging

What was the rationale?


Gilles

> Thomas
>
>
> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]>
> wrote:
>
>> Hello,
>>
>> We have been discussing various ways to view what's happening
>> internally
>> with algorithms, and the topic of including SLF4J has come up.  I
>> know that
>> this was discussed earlier and it was decided that CM is a low level
>> dependency, therefore it should minimize the transitive dependencies
>> that
>> it introduces.  The Java community has adopted many means of dealing
>> with
>> potential logging conflicts, so I'm requesting that we use SLF4J for
>> logging.
>>
>> I know that JBoss introduced its own logging system, and this made
>> me a
>> bit nervous about this suggestion, so I looked up strategies for
>> switching
>> their logger out with SLF4J:
>>
>>
>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>
>> The general process I go through when working with many dependencies
>> that
>> might use commons-logging instead of SLF4J looks something like
>> this:
>>
>>
>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>
>> With JDK9 individual modules can define their own isolated set of
>> dependencies.  At this point the fix should be a permanent.  If
>> someone has
>> has a very intricate scenario that we have not yet seen, they could
>> use
>> (And probably should use) OSGi to isolate dependencies.
>>
>> WDYT?
>>
>> Cheers,
>> - Ole


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Phil Steitz
On 9/25/15 7:03 AM, Gilles wrote:

> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>> Hi Ole,
>>
>> for a start, I think you are asking the wrong question.
>> First of all we need to agree that we want to add some kind of
>> logging
>> facility to CM.
>> If the outcome is positive, there are a handful of alternatives,
>> some of
>> them more viable than slf4j in the context of CM (e.g. JUL or
>> commons-logging).
>
> Could someone summarize why those alternatives were deemed "more
> viable"?
>
>> btw. the same discussion has been done for other commons
>> components as
>> well, and the result usually was: do not add logging
>
> What was the rationale?

Look at the archives.  We have discussed this multiple times in the
past in [math] and each time came to the conclusion that Thomas
succinctly states above.  What has changed now?

Phil

>
>
> Gilles
>
>> Thomas
>>
>>
>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]>
>> wrote:
>>
>>> Hello,
>>>
>>> We have been discussing various ways to view what's happening
>>> internally
>>> with algorithms, and the topic of including SLF4J has come up.
>>> I know that
>>> this was discussed earlier and it was decided that CM is a low
>>> level
>>> dependency, therefore it should minimize the transitive
>>> dependencies that
>>> it introduces.  The Java community has adopted many means of
>>> dealing with
>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>> for
>>> logging.
>>>
>>> I know that JBoss introduced its own logging system, and this
>>> made me a
>>> bit nervous about this suggestion, so I looked up strategies for
>>> switching
>>> their logger out with SLF4J:
>>>
>>>
>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>
>>>
>>> The general process I go through when working with many
>>> dependencies that
>>> might use commons-logging instead of SLF4J looks something like
>>> this:
>>>
>>>
>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>
>>>
>>> With JDK9 individual modules can define their own isolated set of
>>> dependencies.  At this point the fix should be a permanent.  If
>>> someone has
>>> has a very intricate scenario that we have not yet seen, they
>>> could use
>>> (And probably should use) OSGi to isolate dependencies.
>>>
>>> WDYT?
>>>
>>> Cheers,
>>> - Ole
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Gilles Sadowski
On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:

> On 9/25/15 7:03 AM, Gilles wrote:
>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>>> Hi Ole,
>>>
>>> for a start, I think you are asking the wrong question.
>>> First of all we need to agree that we want to add some kind of
>>> logging
>>> facility to CM.
>>> If the outcome is positive, there are a handful of alternatives,
>>> some of
>>> them more viable than slf4j in the context of CM (e.g. JUL or
>>> commons-logging).
>>
>> Could someone summarize why those alternatives were deemed "more
>> viable"?
>>
>>> btw. the same discussion has been done for other commons
>>> components as
>>> well, and the result usually was: do not add logging
>>
>> What was the rationale?
>
> Look at the archives.  We have discussed this multiple times in the
> past in [math] and each time came to the conclusion that Thomas
> succinctly states above.  What has changed now?

We also discussed several times to stick with Java 5.
Fortunately, that has changed. [Although sticking with Java 7 is still
a bad decision IMHO.]

As for logging, IIRC, the sole argument was "no dependency" because
(IIRC) of the potential "JAR hell".

If there are now well-formed answers proving that the fear was
unfounded, that is also a change.

IMO, logging is quite important for any "non-obvious" code.[1]
[I'm again stating that, in that respect, CM is not like the other
"Commmons" components.]

Several times, I've been obliged to create a modified version of CM
to introduce "print" statements (poor man's logging!) in order to
figure out why my code did not do what it was supposed to.
It also makes a code easier to debug while developing or modifying it
(without resorting to poor man's logging, then deleting the "print",
then reinstating them, then deleting them again, ad nauseam).

Gilles

[1] No quality or complexity judgment implied.

> Phil
>>
>>
>> Gilles
>>
>>> Thomas
>>>
>>>
>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> We have been discussing various ways to view what's happening
>>>> internally
>>>> with algorithms, and the topic of including SLF4J has come up.
>>>> I know that
>>>> this was discussed earlier and it was decided that CM is a low
>>>> level
>>>> dependency, therefore it should minimize the transitive
>>>> dependencies that
>>>> it introduces.  The Java community has adopted many means of
>>>> dealing with
>>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>>> for
>>>> logging.
>>>>
>>>> I know that JBoss introduced its own logging system, and this
>>>> made me a
>>>> bit nervous about this suggestion, so I looked up strategies for
>>>> switching
>>>> their logger out with SLF4J:
>>>>
>>>>
>>>>
>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>
>>>>
>>>> The general process I go through when working with many
>>>> dependencies that
>>>> might use commons-logging instead of SLF4J looks something like
>>>> this:
>>>>
>>>>
>>>>
>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>
>>>>
>>>> With JDK9 individual modules can define their own isolated set of
>>>> dependencies.  At this point the fix should be a permanent.  If
>>>> someone has
>>>> has a very intricate scenario that we have not yet seen, they
>>>> could use
>>>> (And probably should use) OSGi to isolate dependencies.
>>>>
>>>> WDYT?
>>>>
>>>> Cheers,
>>>> - Ole


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Thomas Neidhart
On Fri, Sep 25, 2015 at 5:09 PM, Gilles <[hidden email]>
wrote:

> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:
>
>> On 9/25/15 7:03 AM, Gilles wrote:
>>
>>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>>>
>>>> Hi Ole,
>>>>
>>>> for a start, I think you are asking the wrong question.
>>>> First of all we need to agree that we want to add some kind of
>>>> logging
>>>> facility to CM.
>>>> If the outcome is positive, there are a handful of alternatives,
>>>> some of
>>>> them more viable than slf4j in the context of CM (e.g. JUL or
>>>> commons-logging).
>>>>
>>>
>>> Could someone summarize why those alternatives were deemed "more
>>> viable"?
>>>
>>> btw. the same discussion has been done for other commons
>>>> components as
>>>> well, and the result usually was: do not add logging
>>>>
>>>
>>> What was the rationale?
>>>
>>
>> Look at the archives.  We have discussed this multiple times in the
>> past in [math] and each time came to the conclusion that Thomas
>> succinctly states above.  What has changed now?
>>
>
> We also discussed several times to stick with Java 5.
> Fortunately, that has changed. [Although sticking with Java 7 is still
> a bad decision IMHO.]
>
> As for logging, IIRC, the sole argument was "no dependency" because
> (IIRC) of the potential "JAR hell".
>

that's not correct. The decision to not include any dependencies has
nothing to do with "JAR hell".

In order to prevent JAR hell, commons components strictly stick to the
"Versioning guidelines" [1]

The no-dependency rule is more related to the proposal of the component,
see [2]

[1] http://commons.apache.org/releases/versioning.html
[2] http://commons.apache.org/proper/commons-math/proposal.html

Thomas


> If there are now well-formed answers proving that the fear was
> unfounded, that is also a change.
>
> IMO, logging is quite important for any "non-obvious" code.[1]
> [I'm again stating that, in that respect, CM is not like the other
> "Commmons" components.]
>
> Several times, I've been obliged to create a modified version of CM
> to introduce "print" statements (poor man's logging!) in order to
> figure out why my code did not do what it was supposed to.
> It also makes a code easier to debug while developing or modifying it
> (without resorting to poor man's logging, then deleting the "print",
> then reinstating them, then deleting them again, ad nauseam).
>
> Gilles
>
> [1] No quality or complexity judgment implied.
>
>
> Phil
>>
>>>
>>>
>>> Gilles
>>>
>>> Thomas
>>>>
>>>>
>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]>
>>>> wrote:
>>>>
>>>> Hello,
>>>>>
>>>>> We have been discussing various ways to view what's happening
>>>>> internally
>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>> I know that
>>>>> this was discussed earlier and it was decided that CM is a low
>>>>> level
>>>>> dependency, therefore it should minimize the transitive
>>>>> dependencies that
>>>>> it introduces.  The Java community has adopted many means of
>>>>> dealing with
>>>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>>>> for
>>>>> logging.
>>>>>
>>>>> I know that JBoss introduced its own logging system, and this
>>>>> made me a
>>>>> bit nervous about this suggestion, so I looked up strategies for
>>>>> switching
>>>>> their logger out with SLF4J:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>
>>>>>
>>>>> The general process I go through when working with many
>>>>> dependencies that
>>>>> might use commons-logging instead of SLF4J looks something like
>>>>> this:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>
>>>>>
>>>>> With JDK9 individual modules can define their own isolated set of
>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>> someone has
>>>>> has a very intricate scenario that we have not yet seen, they
>>>>> could use
>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Cheers,
>>>>> - Ole
>>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

ole ersoy
In reply to this post by Thomas Neidhart
Hi Thomas,

On 09/25/2015 08:54 AM, Thomas Neidhart wrote:
> Hi Ole,
>
> for a start, I think you are asking the wrong question.
> First of all we need to agree that we want to add some kind of logging
> facility to CM.
Well it has to be SLF4J because that's the one I'm most familiar with :).  We did discuss having observers that can listen in on increment events that algorithms publish.  This would provide a dependency free method for doing so with one drawback.  Now everyone that wants the algorithm to log has to implement logging.

> If the outcome is positive, there are a handful of alternatives, some of
> them more viable than slf4j in the context of CM (e.g. JUL or
> commons-logging).
Would you be upset if it was SLF4J?  This is minor, but I like the @SLF4J annotation that Lombok provides.

>
> btw. the same discussion has been done for other commons components as
> well, and the result usually was: do not add logging
I think for the reason that commons should not introduce transitive dependencies?  This has been solved fairly well (Below).

Cheers,
- Ole

>
> Thomas
>
>
> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]> wrote:
>
>> Hello,
>>
>> We have been discussing various ways to view what's happening internally
>> with algorithms, and the topic of including SLF4J has come up.  I know that
>> this was discussed earlier and it was decided that CM is a low level
>> dependency, therefore it should minimize the transitive dependencies that
>> it introduces.  The Java community has adopted many means of dealing with
>> potential logging conflicts, so I'm requesting that we use SLF4J for
>> logging.
>>
>> I know that JBoss introduced its own logging system, and this made me a
>> bit nervous about this suggestion, so I looked up strategies for switching
>> their logger out with SLF4J:
>>
>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>
>> The general process I go through when working with many dependencies that
>> might use commons-logging instead of SLF4J looks something like this:
>>
>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>
>> With JDK9 individual modules can define their own isolated set of
>> dependencies.  At this point the fix should be a permanent.  If someone has
>> has a very intricate scenario that we have not yet seen, they could use
>> (And probably should use) OSGi to isolate dependencies.
>>
>> WDYT?
>>
>> Cheers,
>> - Ole
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Phil Steitz
On 9/25/15 8:45 AM, Ole Ersoy wrote:

> Hi Thomas,
>
> On 09/25/2015 08:54 AM, Thomas Neidhart wrote:
>> Hi Ole,
>>
>> for a start, I think you are asking the wrong question.
>> First of all we need to agree that we want to add some kind of
>> logging
>> facility to CM.
> Well it has to be SLF4J because that's the one I'm most familiar
> with :).  We did discuss having observers that can listen in on
> increment events that algorithms publish.  This would provide a
> dependency free method for doing so with one drawback.  Now
> everyone that wants the algorithm to log has to implement logging.

This is the right approach, IMO, for reasons that have been stated
in the archives.  Has more as much to do with separation of concerns
and clean API contracts as dependencies and conflicts.

Phil

>
>> If the outcome is positive, there are a handful of alternatives,
>> some of
>> them more viable than slf4j in the context of CM (e.g. JUL or
>> commons-logging).
> Would you be upset if it was SLF4J?  This is minor, but I like the
> @SLF4J annotation that Lombok provides.
>
>>
>> btw. the same discussion has been done for other commons
>> components as
>> well, and the result usually was: do not add logging
> I think for the reason that commons should not introduce
> transitive dependencies?  This has been solved fairly well (Below).
>
> Cheers,
> - Ole
>
>>
>> Thomas
>>
>>
>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]>
>> wrote:
>>
>>> Hello,
>>>
>>> We have been discussing various ways to view what's happening
>>> internally
>>> with algorithms, and the topic of including SLF4J has come up.
>>> I know that
>>> this was discussed earlier and it was decided that CM is a low
>>> level
>>> dependency, therefore it should minimize the transitive
>>> dependencies that
>>> it introduces.  The Java community has adopted many means of
>>> dealing with
>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>> for
>>> logging.
>>>
>>> I know that JBoss introduced its own logging system, and this
>>> made me a
>>> bit nervous about this suggestion, so I looked up strategies for
>>> switching
>>> their logger out with SLF4J:
>>>
>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>
>>>
>>> The general process I go through when working with many
>>> dependencies that
>>> might use commons-logging instead of SLF4J looks something like
>>> this:
>>>
>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>
>>>
>>> With JDK9 individual modules can define their own isolated set of
>>> dependencies.  At this point the fix should be a permanent.  If
>>> someone has
>>> has a very intricate scenario that we have not yet seen, they
>>> could use
>>> (And probably should use) OSGi to isolate dependencies.
>>>
>>> WDYT?
>>>
>>> Cheers,
>>> - Ole
>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

garydgregory
On Fri, Sep 25, 2015 at 8:50 AM, Phil Steitz <[hidden email]> wrote:

> On 9/25/15 8:45 AM, Ole Ersoy wrote:
> > Hi Thomas,
> >
> > On 09/25/2015 08:54 AM, Thomas Neidhart wrote:
> >> Hi Ole,
> >>
> >> for a start, I think you are asking the wrong question.
> >> First of all we need to agree that we want to add some kind of
> >> logging
> >> facility to CM.
> > Well it has to be SLF4J because that's the one I'm most familiar
> > with :).  We did discuss having observers that can listen in on
> > increment events that algorithms publish.  This would provide a
> > dependency free method for doing so with one drawback.  Now
> > everyone that wants the algorithm to log has to implement logging.
>
> This is the right approach, IMO, for reasons that have been stated
> in the archives.  Has more as much to do with separation of concerns
> and clean API contracts as dependencies and conflicts.
>

Note that Log4j 2 (we just released 2.4) has a clean separation between
logging API and implementations, including it's own of course.

We are also an active group of developers here to help you should you it!
:-)

https://logging.apache.org/log4j/2.x/index.html

Gary


>
> Phil
> >
> >> If the outcome is positive, there are a handful of alternatives,
> >> some of
> >> them more viable than slf4j in the context of CM (e.g. JUL or
> >> commons-logging).
> > Would you be upset if it was SLF4J?  This is minor, but I like the
> > @SLF4J annotation that Lombok provides.
> >
> >>
> >> btw. the same discussion has been done for other commons
> >> components as
> >> well, and the result usually was: do not add logging
> > I think for the reason that commons should not introduce
> > transitive dependencies?  This has been solved fairly well (Below).
> >
> > Cheers,
> > - Ole
> >
> >>
> >> Thomas
> >>
> >>
> >> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]>
> >> wrote:
> >>
> >>> Hello,
> >>>
> >>> We have been discussing various ways to view what's happening
> >>> internally
> >>> with algorithms, and the topic of including SLF4J has come up.
> >>> I know that
> >>> this was discussed earlier and it was decided that CM is a low
> >>> level
> >>> dependency, therefore it should minimize the transitive
> >>> dependencies that
> >>> it introduces.  The Java community has adopted many means of
> >>> dealing with
> >>> potential logging conflicts, so I'm requesting that we use SLF4J
> >>> for
> >>> logging.
> >>>
> >>> I know that JBoss introduced its own logging system, and this
> >>> made me a
> >>> bit nervous about this suggestion, so I looked up strategies for
> >>> switching
> >>> their logger out with SLF4J:
> >>>
> >>>
> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
> >>>
> >>>
> >>> The general process I go through when working with many
> >>> dependencies that
> >>> might use commons-logging instead of SLF4J looks something like
> >>> this:
> >>>
> >>>
> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
> >>>
> >>>
> >>> With JDK9 individual modules can define their own isolated set of
> >>> dependencies.  At this point the fix should be a permanent.  If
> >>> someone has
> >>> has a very intricate scenario that we have not yet seen, they
> >>> could use
> >>> (And probably should use) OSGi to isolate dependencies.
> >>>
> >>> WDYT?
> >>>
> >>> Cheers,
> >>> - Ole
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>>
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Phil Steitz
In reply to this post by Gilles Sadowski
On 9/25/15 8:09 AM, Gilles wrote:

> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:
>> On 9/25/15 7:03 AM, Gilles wrote:
>>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>>>> Hi Ole,
>>>>
>>>> for a start, I think you are asking the wrong question.
>>>> First of all we need to agree that we want to add some kind of
>>>> logging
>>>> facility to CM.
>>>> If the outcome is positive, there are a handful of alternatives,
>>>> some of
>>>> them more viable than slf4j in the context of CM (e.g. JUL or
>>>> commons-logging).
>>>
>>> Could someone summarize why those alternatives were deemed "more
>>> viable"?
>>>
>>>> btw. the same discussion has been done for other commons
>>>> components as
>>>> well, and the result usually was: do not add logging
>>>
>>> What was the rationale?
>>
>> Look at the archives.  We have discussed this multiple times in the
>> past in [math] and each time came to the conclusion that Thomas
>> succinctly states above.  What has changed now?
>
> We also discussed several times to stick with Java 5.
> Fortunately, that has changed. [Although sticking with Java 7 is
> still
> a bad decision IMHO.]
>
> As for logging, IIRC, the sole argument was "no dependency" because
> (IIRC) of the potential "JAR hell".
>
> If there are now well-formed answers proving that the fear was
> unfounded, that is also a change.
>
> IMO, logging is quite important for any "non-obvious" code.[1]
> [I'm again stating that, in that respect, CM is not like the other
> "Commmons" components.]

I disagree.  Good tests, API contracts, exception management and
documentation can and should eliminate the need for cluttering
low-level library code with debug logging.
>
> Several times, I've been obliged to create a modified version of CM
> to introduce "print" statements (poor man's logging!) in order to
> figure out why my code did not do what it was supposed to.

Here again, tests, good design, code inspection are the way to go in
low-level components.  I have also spent a lot of time researching
bugs in [math], other Commons components and other complex systems.
My experience is a little different: excessive logging / debug code
for code that contains it often just tends to get in the way,
especially after it has rotted a bit.  Rather than adding more code
to maintain so that you can have less conceptual control over the
functional code, it is better, IMNSHO, to focus on making the
functional code as simple as possible with clean well-documented,
test-validated API contracts.  

> It also makes a code easier to debug while developing or modifying it
> (without resorting to poor man's logging, then deleting the "print",
> then reinstating them, then deleting them again, ad nauseam).
>
> Gilles
>
> [1] No quality or complexity judgment implied.
>
>> Phil
>>>
>>>
>>> Gilles
>>>
>>>> Thomas
>>>>
>>>>
>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> We have been discussing various ways to view what's happening
>>>>> internally
>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>> I know that
>>>>> this was discussed earlier and it was decided that CM is a low
>>>>> level
>>>>> dependency, therefore it should minimize the transitive
>>>>> dependencies that
>>>>> it introduces.  The Java community has adopted many means of
>>>>> dealing with
>>>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>>>> for
>>>>> logging.
>>>>>
>>>>> I know that JBoss introduced its own logging system, and this
>>>>> made me a
>>>>> bit nervous about this suggestion, so I looked up strategies for
>>>>> switching
>>>>> their logger out with SLF4J:
>>>>>
>>>>>
>>>>>
>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>
>>>>>
>>>>>
>>>>> The general process I go through when working with many
>>>>> dependencies that
>>>>> might use commons-logging instead of SLF4J looks something like
>>>>> this:
>>>>>
>>>>>
>>>>>
>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>
>>>>>
>>>>>
>>>>> With JDK9 individual modules can define their own isolated set of
>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>> someone has
>>>>> has a very intricate scenario that we have not yet seen, they
>>>>> could use
>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Cheers,
>>>>> - Ole
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> .
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

ole ersoy


On 09/25/2015 11:34 AM, Phil Steitz wrote:
> I disagree. Good tests, API contracts, exception management and documentation can and should eliminate the need for cluttering low-level library code with debug logging.

Logging could be viewed as clutter.  Constructed the right way, the logging statements could also be viewed as comments.

I agree that good tests, API contracts, and in general keeping the design as minimalistic and simple as possible should be the first criteria to review before introducing logging.  When the code is trivial I leave logging out, unless I need to put in a few statements in order to track collaboration between components in an algorithm.  Other times the method is as simple as it gets and I have to have logging.  For example take the LevenbergMarquardtOptimizer optimize() method.  It's atomic in the sense that what's in the method belongs in the method.  There are several loops within the main loop, etc. and tracking what's going, even with a observer being notified on each increment, would be far from elegant.

For example perhaps we want to see what's going on with the parameters in this small (5% of the method size) section of code:

                 // compute the scaled predicted reduction
                 // and the scaled directional derivative
                 for (int j = 0; j < solvedCols; ++j) {
                     int pj = permutation[j];
                     double dirJ = lmDir[pj];
                     work1[j] = 0;
                     for (int i = 0; i <= j; ++i) {
                         work1[i] += weightedJacobian[i][pj] * dirJ;
                     }
                 }

If there is something wrong with this in production, the shortest path to figuring that out is reviewing a trace.  The longer path is to stop the server.  Grab the data.  Open up a debugger.  Run the data.

If we wanted to observe this section of code the observer would be looking at sub loops of of the optimize method.  So that's doable, but it creates an interface design for the observer that's cluttered with events corresponding to various low level algorithm details.


>> Several times, I've been obliged to create a modified version of CM
>> to introduce "print" statements (poor man's logging!) in order to
>> figure out why my code did not do what it was supposed to.

It's pretty tragic that anyone of us should have to do this.  It's also wasteful, because if Gilles has to do this, then there's a good chance that others have to do it to.  The reason Tomcat logs at various levels is so that we can see what's going on in production and track down bugs.  Lets become one with the logging and make it into something that strengthens both code integrity and comprehensibility.  Everyone take take out your Feng Shui mat and do some deep breathing right now.

> Here again, tests, good design, code inspection are the way to go in
> low-level components.  I have also spent a lot of time researching
> bugs in [math], other Commons components and other complex systems.
> My experience is a little different: excessive logging / debug code
> for code that contains it often just tends to get in the way,
It's a very good point.  Sometimes we come across logging statements that are just noise.  Given how rigorous we are about reviewing everything though, I think a win win would be to limit the noise during code review, and pledge not to "Call our mom" in the middle of the code, etc.

> especially after it has rotted a bit.  Rather than adding more code
> to maintain so that you can have less conceptual control over the
> functional code, it is better, IMNSHO, to focus on making the
> functional code as simple as possible with clean well-documented,
> test-validated API contracts.

Totally agree.  I think this should be the first priority, and that logging should be used when there are no simple clean alternatives.

>
>> It also makes a code easier to debug while developing or modifying it
>> (without resorting to poor man's logging, then deleting the "print",
>> then reinstating them, then deleting them again, ad nauseam).
Pretty sure we have all been here.

Cheers,
- Ole


>>
>> Gilles
>>
>> [1] No quality or complexity judgment implied.
>>
>>> Phil
>>>>
>>>> Gilles
>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> We have been discussing various ways to view what's happening
>>>>>> internally
>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>> I know that
>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>> level
>>>>>> dependency, therefore it should minimize the transitive
>>>>>> dependencies that
>>>>>> it introduces.  The Java community has adopted many means of
>>>>>> dealing with
>>>>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>>>>> for
>>>>>> logging.
>>>>>>
>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>> made me a
>>>>>> bit nervous about this suggestion, so I looked up strategies for
>>>>>> switching
>>>>>> their logger out with SLF4J:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>
>>>>>>
>>>>>>
>>>>>> The general process I go through when working with many
>>>>>> dependencies that
>>>>>> might use commons-logging instead of SLF4J looks something like
>>>>>> this:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>
>>>>>>
>>>>>>
>>>>>> With JDK9 individual modules can define their own isolated set of
>>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>>> someone has
>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>> could use
>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Cheers,
>>>>>> - Ole
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>> .
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Phil Steitz
On 9/25/15 11:01 AM, Ole Ersoy wrote:

>
>
> On 09/25/2015 11:34 AM, Phil Steitz wrote:
>> I disagree. Good tests, API contracts, exception management and
>> documentation can and should eliminate the need for cluttering
>> low-level library code with debug logging.
>
> Logging could be viewed as clutter.  Constructed the right way,
> the logging statements could also be viewed as comments.
>
> I agree that good tests, API contracts, and in general keeping the
> design as minimalistic and simple as possible should be the first
> criteria to review before introducing logging.  When the code is
> trivial I leave logging out, unless I need to put in a few
> statements in order to track collaboration between components in
> an algorithm.  
> Other times the method is as simple as it gets and I have to have
> logging.  For example take the LevenbergMarquardtOptimizer
> optimize() method.  It's atomic in the sense that what's in the
> method belongs in the method.  There are several loops within the
> main loop, etc. and tracking what's going, even with a observer
> being notified on each increment, would be far from elegant.

Why, exactly do you need to "track what is going on?"  If you need
to do that as a user of the code, some kind of listener or API to
give you the information that you need is appropriate.  Dumping text
to an external resource to "solve" this usually indicates smelliness
somewhere - either in the library API or the client code.

>
> For example perhaps we want to see what's going on with the
> parameters in this small (5% of the method size) section of code:

What parameters and where did they come from?  If from the client,
the client can validate them.  If the library needs to validate or
confirm suitability, then it should do that in code or via tests.

>
>                 // compute the scaled predicted reduction
>                 // and the scaled directional derivative
>                 for (int j = 0; j < solvedCols; ++j) {
>                     int pj = permutation[j];
>                     double dirJ = lmDir[pj];
>                     work1[j] = 0;
>                     for (int i = 0; i <= j; ++i) {
>                         work1[i] += weightedJacobian[i][pj] * dirJ;
>                     }
>                 }
>
> If there is something wrong with this in production, the shortest
> path to figuring that out is reviewing a trace.  The longer path
> is to stop the server.  Grab the data.  Open up a debugger.  Run
> the data.
>
> If we wanted to observe this section of code the observer would be
> looking at sub loops of of the optimize method.  So that's doable,
> but it creates an interface design for the observer that's
> cluttered with events corresponding to various low level algorithm
> details.
>
>
>>> Several times, I've been obliged to create a modified version of CM
>>> to introduce "print" statements (poor man's logging!) in order to
>>> figure out why my code did not do what it was supposed to.
>
> It's pretty tragic that anyone of us should have to do this.  It's
> also wasteful, because if Gilles has to do this, then there's a
> good chance that others have to do it to.  The reason Tomcat logs
> at various levels is so that we can see what's going on in
> production and track down bugs.

No.  Have a look at the Tomcat logging code.  It is mostly
initialization, shutdown and exceptions or warnings.  This is
necessary because tomcat is a container - there is no client
application to catch exceptions or get API results back.  The analog
for the kind of instrumentation you are proposing inside [math]
would be like tomcat larding itself up with debug logging throughout
the request processing lifecycle, which it does not do.   It is a
bad analogy in any case, because Tomcat is a container, which is 2
big steps up the processing chain from a low-level library.

Phil

> Lets become one with the logging and make it into something that
> strengthens both code integrity and comprehensibility.  Everyone
> take take out your Feng Shui mat and do some deep breathing right
> now.
>
>> Here again, tests, good design, code inspection are the way to go in
>> low-level components.  I have also spent a lot of time researching
>> bugs in [math], other Commons components and other complex systems.
>> My experience is a little different: excessive logging / debug code
>> for code that contains it often just tends to get in the way,
> It's a very good point.  Sometimes we come across logging
> statements that are just noise.  Given how rigorous we are about
> reviewing everything though, I think a win win would be to limit
> the noise during code review, and pledge not to "Call our mom" in
> the middle of the code, etc.
>
>> especially after it has rotted a bit.  Rather than adding more code
>> to maintain so that you can have less conceptual control over the
>> functional code, it is better, IMNSHO, to focus on making the
>> functional code as simple as possible with clean well-documented,
>> test-validated API contracts.
>
> Totally agree.  I think this should be the first priority, and
> that logging should be used when there are no simple clean
> alternatives.
>
>>
>>> It also makes a code easier to debug while developing or
>>> modifying it
>>> (without resorting to poor man's logging, then deleting the
>>> "print",
>>> then reinstating them, then deleting them again, ad nauseam).
> Pretty sure we have all been here.
>
> Cheers,
> - Ole
>
>
>>>
>>> Gilles
>>>
>>> [1] No quality or complexity judgment implied.
>>>
>>>> Phil
>>>>>
>>>>> Gilles
>>>>>
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> We have been discussing various ways to view what's happening
>>>>>>> internally
>>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>>> I know that
>>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>>> level
>>>>>>> dependency, therefore it should minimize the transitive
>>>>>>> dependencies that
>>>>>>> it introduces.  The Java community has adopted many means of
>>>>>>> dealing with
>>>>>>> potential logging conflicts, so I'm requesting that we use
>>>>>>> SLF4J
>>>>>>> for
>>>>>>> logging.
>>>>>>>
>>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>>> made me a
>>>>>>> bit nervous about this suggestion, so I looked up strategies
>>>>>>> for
>>>>>>> switching
>>>>>>> their logger out with SLF4J:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The general process I go through when working with many
>>>>>>> dependencies that
>>>>>>> might use commons-logging instead of SLF4J looks something like
>>>>>>> this:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> With JDK9 individual modules can define their own isolated
>>>>>>> set of
>>>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>>>> someone has
>>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>>> could use
>>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> - Ole
>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>> .
>>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

ole ersoy


On 09/25/2015 03:06 PM, Phil Steitz wrote:

> On 9/25/15 11:01 AM, Ole Ersoy wrote:
>>
>> On 09/25/2015 11:34 AM, Phil Steitz wrote:
>>> I disagree. Good tests, API contracts, exception management and
>>> documentation can and should eliminate the need for cluttering
>>> low-level library code with debug logging.
>> Logging could be viewed as clutter.  Constructed the right way,
>> the logging statements could also be viewed as comments.
>>
>> I agree that good tests, API contracts, and in general keeping the
>> design as minimalistic and simple as possible should be the first
>> criteria to review before introducing logging.  When the code is
>> trivial I leave logging out, unless I need to put in a few
>> statements in order to track collaboration between components in
>> an algorithm.
>> Other times the method is as simple as it gets and I have to have
>> logging.  For example take the LevenbergMarquardtOptimizer
>> optimize() method.  It's atomic in the sense that what's in the
>> method belongs in the method.  There are several loops within the
>> main loop, etc. and tracking what's going, even with a observer
>> being notified on each increment, would be far from elegant.
> Why, exactly do you need to "track what is going on?"
I hope that I don't.  Most of the time code we write, especially the CM code, is rock solid.  When implementing complex algorithms we break it down to simple building blocks, reason about it, break it down some more, unit test it, and it looks fantastic.  Then we hit a snag, and start putting in println statements.  Then we delete these after the fix, cut up 5 chickens, and pray.

If an issue occurs, then there is a low probability that it is a CM component.  The traces can help prove that it is not the CM component.

If the code is now rock solid, then the log statements bother no one.  We put the code back in production, trace initially to make sure everything looks healthy, and then turn off logging.  On the flip side if we notice that something else seems off, we're back to putting in the println statements again.

Watching traces of CM components in production is an additional insurance policy for guaranteeing quality.

Also if there is an issue, and someone needs to understand it fast, the best way is to watch data flow through the system.  For new contributors, this could be a good way to get up to speed on an algorithm.


>    If you need
> to do that as a user of the code, some kind of listener or API to
> give you the information that you need is appropriate.
I agree, but as I showed with the LevenbergMarquardtOptimizer attempting inject code into the optimize() method is a non trivial exercise.  Components should have a simple way to examine discrete steps that are being performed.

>    Dumping text
> to an external resource to "solve" this usually indicates smelliness
> somewhere - either in the library API or the client code.
Or it is a precaution to ensure that no one forgot to flush.

>
>> For example perhaps we want to see what's going on with the
>> parameters in this small (5% of the method size) section of code:
> What parameters and where did they come from?  If from the client,
> the client can validate them.  If the library needs to validate or
> confirm suitability, then it should do that in code or via tests.
>>                  // compute the scaled predicted reduction
>>                  // and the scaled directional derivative
>>                  for (int j = 0; j < solvedCols; ++j) {
>>                      int pj = permutation[j];
>>                      double dirJ = lmDir[pj];
>>                      work1[j] = 0;
>>                      for (int i = 0; i <= j; ++i) {
>>                          work1[i] += weightedJacobian[i][pj] * dirJ;
>>                      }
>>                  }
>>
>> If there is something wrong with this in production, the shortest
>> path to figuring that out is reviewing a trace.  The longer path
>> is to stop the server.  Grab the data.  Open up a debugger.  Run
>> the data.
>>
>> If we wanted to observe this section of code the observer would be
>> looking at sub loops of of the optimize method.  So that's doable,
>> but it creates an interface design for the observer that's
>> cluttered with events corresponding to various low level algorithm
>> details.
>>
>>
>>>> Several times, I've been obliged to create a modified version of CM
>>>> to introduce "print" statements (poor man's logging!) in order to
>>>> figure out why my code did not do what it was supposed to.
>> It's pretty tragic that anyone of us should have to do this.  It's
>> also wasteful, because if Gilles has to do this, then there's a
>> good chance that others have to do it to.  The reason Tomcat logs
>> at various levels is so that we can see what's going on in
>> production and track down bugs.
> No.  Have a look at the Tomcat logging code.  It is mostly
> initialization, shutdown and exceptions or warnings.

I agree, but I would argue that these should be far simpler to reason about than the life cycle of some of the CM algorithms.

>    This is
> necessary because tomcat is a container - there is no client
> application to catch exceptions or get API results back.
The use case is the same.  If there is a production problem, it will show up in the logs.  This is what Gilles and I are asking for.  The ability to help diagnose component performance by reviewing a trace.  If the component is rock solid, then the additional tracing is free.

Part of this reminds me of a hesitation I had with use Markdown syntax for tables.  It's pretty tedious to line up all the pipes, etc. to make the tables look pretty.  Then I downloaded atom and a markdown plugin, and it automatically did it for me.

It should be pretty easy to hide logging statements in code via tooling. I just searched, and it does not look like it exists yet, but at least others are thinking about it:
http://stackoverflow.com/questions/10705814/how-to-write-eclipse-plugin-to-hide-logger-statements


>    The analog
> for the kind of instrumentation you are proposing inside [math]
> would be like tomcat larding itself up with debug logging throughout
> the request processing lifecycle, which it does not do.
I agree, but the request API publishes a great deal of detail about each request.  Also Tomcat is in production all over the place.  It goes through a lot of hammering.  Math components get far less exposure....probably in the order of 1/100,000.,,I think would be a conservative estimate.


>     It is a
> bad analogy in any case, because Tomcat is a container, which is 2
> big steps up the processing chain from a low-level library.
That's fair.  The CM developers are all very talented though.  I don't think Gilles is going to get all sloppy joe with his logging. He cares a great deal about the code quality, just like everyone else.  I think if we OK logging, then initially Gilles will probably be the only one using it, because he strongly feels he needs it. The rest of us seem fairly content with the state of the components, so I'm guessing the components will stay the way they are for a while.  If there is nothing wrong, then there is no need to introduce tracing.

When I perform the LevenbergMarquardtOptimizer I'm about to embark on, I'm going to introduce tracing just to learn more about the algorithms dynamics.  It would be a shame to have to delete the tracing when the refactoring is complete.

Introducing tracing is going to give future maintainers and contributors a great on ramp.

Cheers,
- Ole



>
> Phil
>
>> Lets become one with the logging and make it into something that
>> strengthens both code integrity and comprehensibility.  Everyone
>> take take out your Feng Shui mat and do some deep breathing right
>> now.
>>
>>> Here again, tests, good design, code inspection are the way to go in
>>> low-level components.  I have also spent a lot of time researching
>>> bugs in [math], other Commons components and other complex systems.
>>> My experience is a little different: excessive logging / debug code
>>> for code that contains it often just tends to get in the way,
>> It's a very good point.  Sometimes we come across logging
>> statements that are just noise.  Given how rigorous we are about
>> reviewing everything though, I think a win win would be to limit
>> the noise during code review, and pledge not to "Call our mom" in
>> the middle of the code, etc.
>>
>>> especially after it has rotted a bit.  Rather than adding more code
>>> to maintain so that you can have less conceptual control over the
>>> functional code, it is better, IMNSHO, to focus on making the
>>> functional code as simple as possible with clean well-documented,
>>> test-validated API contracts.
>> Totally agree.  I think this should be the first priority, and
>> that logging should be used when there are no simple clean
>> alternatives.
>>
>>>> It also makes a code easier to debug while developing or
>>>> modifying it
>>>> (without resorting to poor man's logging, then deleting the
>>>> "print",
>>>> then reinstating them, then deleting them again, ad nauseam).
>> Pretty sure we have all been here.
>>
>> Cheers,
>> - Ole
>>
>>
>>>> Gilles
>>>>
>>>> [1] No quality or complexity judgment implied.
>>>>
>>>>> Phil
>>>>>> Gilles
>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> We have been discussing various ways to view what's happening
>>>>>>>> internally
>>>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>>>> I know that
>>>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>>>> level
>>>>>>>> dependency, therefore it should minimize the transitive
>>>>>>>> dependencies that
>>>>>>>> it introduces.  The Java community has adopted many means of
>>>>>>>> dealing with
>>>>>>>> potential logging conflicts, so I'm requesting that we use
>>>>>>>> SLF4J
>>>>>>>> for
>>>>>>>> logging.
>>>>>>>>
>>>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>>>> made me a
>>>>>>>> bit nervous about this suggestion, so I looked up strategies
>>>>>>>> for
>>>>>>>> switching
>>>>>>>> their logger out with SLF4J:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The general process I go through when working with many
>>>>>>>> dependencies that
>>>>>>>> might use commons-logging instead of SLF4J looks something like
>>>>>>>> this:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> With JDK9 individual modules can define their own isolated
>>>>>>>> set of
>>>>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>>>>> someone has
>>>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>>>> could use
>>>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> - Ole
>>>> ---------------------------------------------------------------------
>>>>
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>> .
>>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Gilles Sadowski
In reply to this post by Phil Steitz
On Fri, 25 Sep 2015 13:06:43 -0700, Phil Steitz wrote:

I say something like: "I had to fork some CM class to insert
log statements."
You say something like: "No, you don't; write test or inspect
the code."

You had been more constructive:
   http://markmail.org/thread/a5jl6fkjjtm5qbsw

Even if Ole may have picked the wrong example with Tomcat, the
actual request is to be able to follow the execution of a fairly
complex algorithm, like an optimizer, when applied to a fairly
complex user's code, in order to figure out whether there is a
problem; and if so, where it is (in the user's model, in the
call, in the optimizer, whether there is a mismatch between the
user's expectations and the capability of the selected algorithm,
etc.)

Ole's first example with an excerpt of the Levenberg-Marquardt
implementation is actually a hit: a few years ago, a bug was found
somewhere right around that same code:
   https://issues.apache.org/jira/browse/MATH-406
It's an example where logging is a valuable help in debugging.
Another is the poor man's logging fiddling to track the cause of
the erratic behaviour of one of the CI machines.

Gilles

> On 9/25/15 11:01 AM, Ole Ersoy wrote:
>>
>>
>> On 09/25/2015 11:34 AM, Phil Steitz wrote:
>>> I disagree. Good tests, API contracts, exception management and
>>> documentation can and should eliminate the need for cluttering
>>> low-level library code with debug logging.
>>
>> Logging could be viewed as clutter.  Constructed the right way,
>> the logging statements could also be viewed as comments.
>>
>> I agree that good tests, API contracts, and in general keeping the
>> design as minimalistic and simple as possible should be the first
>> criteria to review before introducing logging.  When the code is
>> trivial I leave logging out, unless I need to put in a few
>> statements in order to track collaboration between components in
>> an algorithm.
>> Other times the method is as simple as it gets and I have to have
>> logging.  For example take the LevenbergMarquardtOptimizer
>> optimize() method.  It's atomic in the sense that what's in the
>> method belongs in the method.  There are several loops within the
>> main loop, etc. and tracking what's going, even with a observer
>> being notified on each increment, would be far from elegant.
>
> Why, exactly do you need to "track what is going on?"  If you need
> to do that as a user of the code, some kind of listener or API to
> give you the information that you need is appropriate.  Dumping text
> to an external resource to "solve" this usually indicates smelliness
> somewhere - either in the library API or the client code.
>
>>
>> For example perhaps we want to see what's going on with the
>> parameters in this small (5% of the method size) section of code:
>
> What parameters and where did they come from?  If from the client,
> the client can validate them.  If the library needs to validate or
> confirm suitability, then it should do that in code or via tests.
>>
>>                 // compute the scaled predicted reduction
>>                 // and the scaled directional derivative
>>                 for (int j = 0; j < solvedCols; ++j) {
>>                     int pj = permutation[j];
>>                     double dirJ = lmDir[pj];
>>                     work1[j] = 0;
>>                     for (int i = 0; i <= j; ++i) {
>>                         work1[i] += weightedJacobian[i][pj] * dirJ;
>>                     }
>>                 }
>>
>> If there is something wrong with this in production, the shortest
>> path to figuring that out is reviewing a trace.  The longer path
>> is to stop the server.  Grab the data.  Open up a debugger.  Run
>> the data.
>>
>> If we wanted to observe this section of code the observer would be
>> looking at sub loops of of the optimize method.  So that's doable,
>> but it creates an interface design for the observer that's
>> cluttered with events corresponding to various low level algorithm
>> details.
>>
>>
>>>> Several times, I've been obliged to create a modified version of
>>>> CM
>>>> to introduce "print" statements (poor man's logging!) in order to
>>>> figure out why my code did not do what it was supposed to.
>>
>> It's pretty tragic that anyone of us should have to do this.  It's
>> also wasteful, because if Gilles has to do this, then there's a
>> good chance that others have to do it to.  The reason Tomcat logs
>> at various levels is so that we can see what's going on in
>> production and track down bugs.
>
> No.  Have a look at the Tomcat logging code.  It is mostly
> initialization, shutdown and exceptions or warnings.  This is
> necessary because tomcat is a container - there is no client
> application to catch exceptions or get API results back.  The analog
> for the kind of instrumentation you are proposing inside [math]
> would be like tomcat larding itself up with debug logging throughout
> the request processing lifecycle, which it does not do.   It is a
> bad analogy in any case, because Tomcat is a container, which is 2
> big steps up the processing chain from a low-level library.
>
> Phil
>
>> Lets become one with the logging and make it into something that
>> strengthens both code integrity and comprehensibility.  Everyone
>> take take out your Feng Shui mat and do some deep breathing right
>> now.
>>
>>> Here again, tests, good design, code inspection are the way to go
>>> in
>>> low-level components.  I have also spent a lot of time researching
>>> bugs in [math], other Commons components and other complex systems.
>>> My experience is a little different: excessive logging / debug code
>>> for code that contains it often just tends to get in the way,
>> It's a very good point.  Sometimes we come across logging
>> statements that are just noise.  Given how rigorous we are about
>> reviewing everything though, I think a win win would be to limit
>> the noise during code review, and pledge not to "Call our mom" in
>> the middle of the code, etc.
>>
>>> especially after it has rotted a bit.  Rather than adding more code
>>> to maintain so that you can have less conceptual control over the
>>> functional code, it is better, IMNSHO, to focus on making the
>>> functional code as simple as possible with clean well-documented,
>>> test-validated API contracts.
>>
>> Totally agree.  I think this should be the first priority, and
>> that logging should be used when there are no simple clean
>> alternatives.
>>
>>>
>>>> It also makes a code easier to debug while developing or
>>>> modifying it
>>>> (without resorting to poor man's logging, then deleting the
>>>> "print",
>>>> then reinstating them, then deleting them again, ad nauseam).
>> Pretty sure we have all been here.
>>
>> Cheers,
>> - Ole
>>
>>
>>>>
>>>> Gilles
>>>>
>>>> [1] No quality or complexity judgment implied.
>>>>
>>>>> Phil
>>>>>>
>>>>>> Gilles
>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy
>>>>>>> <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> We have been discussing various ways to view what's happening
>>>>>>>> internally
>>>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>>>> I know that
>>>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>>>> level
>>>>>>>> dependency, therefore it should minimize the transitive
>>>>>>>> dependencies that
>>>>>>>> it introduces.  The Java community has adopted many means of
>>>>>>>> dealing with
>>>>>>>> potential logging conflicts, so I'm requesting that we use
>>>>>>>> SLF4J
>>>>>>>> for
>>>>>>>> logging.
>>>>>>>>
>>>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>>>> made me a
>>>>>>>> bit nervous about this suggestion, so I looked up strategies
>>>>>>>> for
>>>>>>>> switching
>>>>>>>> their logger out with SLF4J:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The general process I go through when working with many
>>>>>>>> dependencies that
>>>>>>>> might use commons-logging instead of SLF4J looks something
>>>>>>>> like
>>>>>>>> this:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> With JDK9 individual modules can define their own isolated
>>>>>>>> set of
>>>>>>>> dependencies.  At this point the fix should be a permanent.  
>>>>>>>> If
>>>>>>>> someone has
>>>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>>>> could use
>>>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> - Ole
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>> .
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Hasan Diwan
Oughtn't there be an option to have logging for developers? If you'd like
to use it, feel free; if not, don't. Including log4j (or slf or
commons-logging, so on) doesn't add too much weight to the jar -- one file,
a small properties file, and 4-lines in the pom file. If there is interest,
I can submit a patch adding log4j and log4j.properties to JIRA. Let me
know? -- H

On 25 September 2015 at 16:26, Gilles <[hidden email]> wrote:

> On Fri, 25 Sep 2015 13:06:43 -0700, Phil Steitz wrote:
>
> I say something like: "I had to fork some CM class to insert
> log statements."
> You say something like: "No, you don't; write test or inspect
> the code."
>
> You had been more constructive:
>   http://markmail.org/thread/a5jl6fkjjtm5qbsw
>
> Even if Ole may have picked the wrong example with Tomcat, the
> actual request is to be able to follow the execution of a fairly
> complex algorithm, like an optimizer, when applied to a fairly
> complex user's code, in order to figure out whether there is a
> problem; and if so, where it is (in the user's model, in the
> call, in the optimizer, whether there is a mismatch between the
> user's expectations and the capability of the selected algorithm,
> etc.)
>
> Ole's first example with an excerpt of the Levenberg-Marquardt
> implementation is actually a hit: a few years ago, a bug was found
> somewhere right around that same code:
>   https://issues.apache.org/jira/browse/MATH-406
> It's an example where logging is a valuable help in debugging.
> Another is the poor man's logging fiddling to track the cause of
> the erratic behaviour of one of the CI machines.
>
> Gilles
>
>
> On 9/25/15 11:01 AM, Ole Ersoy wrote:
>>
>>>
>>>
>>> On 09/25/2015 11:34 AM, Phil Steitz wrote:
>>>
>>>> I disagree. Good tests, API contracts, exception management and
>>>> documentation can and should eliminate the need for cluttering
>>>> low-level library code with debug logging.
>>>>
>>>
>>> Logging could be viewed as clutter.  Constructed the right way,
>>> the logging statements could also be viewed as comments.
>>>
>>> I agree that good tests, API contracts, and in general keeping the
>>> design as minimalistic and simple as possible should be the first
>>> criteria to review before introducing logging.  When the code is
>>> trivial I leave logging out, unless I need to put in a few
>>> statements in order to track collaboration between components in
>>> an algorithm.
>>> Other times the method is as simple as it gets and I have to have
>>> logging.  For example take the LevenbergMarquardtOptimizer
>>> optimize() method.  It's atomic in the sense that what's in the
>>> method belongs in the method.  There are several loops within the
>>> main loop, etc. and tracking what's going, even with a observer
>>> being notified on each increment, would be far from elegant.
>>>
>>
>> Why, exactly do you need to "track what is going on?"  If you need
>> to do that as a user of the code, some kind of listener or API to
>> give you the information that you need is appropriate.  Dumping text
>> to an external resource to "solve" this usually indicates smelliness
>> somewhere - either in the library API or the client code.
>>
>>
>>> For example perhaps we want to see what's going on with the
>>> parameters in this small (5% of the method size) section of code:
>>>
>>
>> What parameters and where did they come from?  If from the client,
>> the client can validate them.  If the library needs to validate or
>> confirm suitability, then it should do that in code or via tests.
>>
>>>
>>>                 // compute the scaled predicted reduction
>>>                 // and the scaled directional derivative
>>>                 for (int j = 0; j < solvedCols; ++j) {
>>>                     int pj = permutation[j];
>>>                     double dirJ = lmDir[pj];
>>>                     work1[j] = 0;
>>>                     for (int i = 0; i <= j; ++i) {
>>>                         work1[i] += weightedJacobian[i][pj] * dirJ;
>>>                     }
>>>                 }
>>>
>>> If there is something wrong with this in production, the shortest
>>> path to figuring that out is reviewing a trace.  The longer path
>>> is to stop the server.  Grab the data.  Open up a debugger.  Run
>>> the data.
>>>
>>> If we wanted to observe this section of code the observer would be
>>> looking at sub loops of of the optimize method.  So that's doable,
>>> but it creates an interface design for the observer that's
>>> cluttered with events corresponding to various low level algorithm
>>> details.
>>>
>>>
>>> Several times, I've been obliged to create a modified version of CM
>>>>> to introduce "print" statements (poor man's logging!) in order to
>>>>> figure out why my code did not do what it was supposed to.
>>>>>
>>>>
>>> It's pretty tragic that anyone of us should have to do this.  It's
>>> also wasteful, because if Gilles has to do this, then there's a
>>> good chance that others have to do it to.  The reason Tomcat logs
>>> at various levels is so that we can see what's going on in
>>> production and track down bugs.
>>>
>>
>> No.  Have a look at the Tomcat logging code.  It is mostly
>> initialization, shutdown and exceptions or warnings.  This is
>> necessary because tomcat is a container - there is no client
>> application to catch exceptions or get API results back.  The analog
>> for the kind of instrumentation you are proposing inside [math]
>> would be like tomcat larding itself up with debug logging throughout
>> the request processing lifecycle, which it does not do.   It is a
>> bad analogy in any case, because Tomcat is a container, which is 2
>> big steps up the processing chain from a low-level library.
>>
>> Phil
>>
>> Lets become one with the logging and make it into something that
>>> strengthens both code integrity and comprehensibility.  Everyone
>>> take take out your Feng Shui mat and do some deep breathing right
>>> now.
>>>
>>> Here again, tests, good design, code inspection are the way to go in
>>>> low-level components.  I have also spent a lot of time researching
>>>> bugs in [math], other Commons components and other complex systems.
>>>> My experience is a little different: excessive logging / debug code
>>>> for code that contains it often just tends to get in the way,
>>>>
>>> It's a very good point.  Sometimes we come across logging
>>> statements that are just noise.  Given how rigorous we are about
>>> reviewing everything though, I think a win win would be to limit
>>> the noise during code review, and pledge not to "Call our mom" in
>>> the middle of the code, etc.
>>>
>>> especially after it has rotted a bit.  Rather than adding more code
>>>> to maintain so that you can have less conceptual control over the
>>>> functional code, it is better, IMNSHO, to focus on making the
>>>> functional code as simple as possible with clean well-documented,
>>>> test-validated API contracts.
>>>>
>>>
>>> Totally agree.  I think this should be the first priority, and
>>> that logging should be used when there are no simple clean
>>> alternatives.
>>>
>>>
>>>> It also makes a code easier to debug while developing or
>>>>> modifying it
>>>>> (without resorting to poor man's logging, then deleting the
>>>>> "print",
>>>>> then reinstating them, then deleting them again, ad nauseam).
>>>>>
>>>> Pretty sure we have all been here.
>>>
>>> Cheers,
>>> - Ole
>>>
>>>
>>>
>>>>> Gilles
>>>>>
>>>>> [1] No quality or complexity judgment implied.
>>>>>
>>>>> Phil
>>>>>>
>>>>>>>
>>>>>>> Gilles
>>>>>>>
>>>>>>> Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> We have been discussing various ways to view what's happening
>>>>>>>>> internally
>>>>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>>>>> I know that
>>>>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>>>>> level
>>>>>>>>> dependency, therefore it should minimize the transitive
>>>>>>>>> dependencies that
>>>>>>>>> it introduces.  The Java community has adopted many means of
>>>>>>>>> dealing with
>>>>>>>>> potential logging conflicts, so I'm requesting that we use
>>>>>>>>> SLF4J
>>>>>>>>> for
>>>>>>>>> logging.
>>>>>>>>>
>>>>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>>>>> made me a
>>>>>>>>> bit nervous about this suggestion, so I looked up strategies
>>>>>>>>> for
>>>>>>>>> switching
>>>>>>>>> their logger out with SLF4J:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The general process I go through when working with many
>>>>>>>>> dependencies that
>>>>>>>>> might use commons-logging instead of SLF4J looks something like
>>>>>>>>> this:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> With JDK9 individual modules can define their own isolated
>>>>>>>>> set of
>>>>>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>>>>>> someone has
>>>>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>>>>> could use
>>>>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>>>>
>>>>>>>>> WDYT?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> - Ole
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>> .
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
OpenPGP: https://hasan.d8u.us/gpg.key
Sent from my mobile device
Envoyé de mon portable
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Gilles Sadowski
In reply to this post by Thomas Neidhart
On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:

> On Fri, Sep 25, 2015 at 5:09 PM, Gilles
> <[hidden email]>
> wrote:
>
>> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:
>>
>>> On 9/25/15 7:03 AM, Gilles wrote:
>>>
>>>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>>>>
>>>>> Hi Ole,
>>>>>
>>>>> for a start, I think you are asking the wrong question.
>>>>> First of all we need to agree that we want to add some kind of
>>>>> logging
>>>>> facility to CM.
>>>>> If the outcome is positive, there are a handful of alternatives,
>>>>> some of
>>>>> them more viable than slf4j in the context of CM (e.g. JUL or
>>>>> commons-logging).
>>>>>
>>>>
>>>> Could someone summarize why those alternatives were deemed "more
>>>> viable"?
>>>>
>>>> btw. the same discussion has been done for other commons
>>>>> components as
>>>>> well, and the result usually was: do not add logging
>>>>>
>>>>
>>>> What was the rationale?
>>>>
>>>
>>> Look at the archives.  We have discussed this multiple times in the
>>> past in [math] and each time came to the conclusion that Thomas
>>> succinctly states above.  What has changed now?
>>>
>>
>> We also discussed several times to stick with Java 5.
>> Fortunately, that has changed. [Although sticking with Java 7 is
>> still
>> a bad decision IMHO.]
>>
>> As for logging, IIRC, the sole argument was "no dependency" because
>> (IIRC) of the potential "JAR hell".
>>
>
> that's not correct. The decision to not include any dependencies has
> nothing to do with "JAR hell".

Although I can't find it now, I'm pretty sure that I more than once
got such an answer.

> In order to prevent JAR hell, commons components strictly stick to
> the
> "Versioning guidelines" [1]

I can't see how it relates.
But if you mean that no JAR hell can emerge from using a logging
framework,
then that's good news.

> The no-dependency rule is more related to the proposal of the
> component,
> see [2]

Thanks for the reminder; in that document, we read:

   (1) Scope of the Package
    [...]
    5. Limited dependencies. No external dependencies beyond Commons
components and the JDK

So we are fine if use "Log4j 2" as kindly offered by Gary.

My long-standing mentioning of slf4j was only because of its
"weightlessness" (thanks to the no-op implementation of its API).
If "Log4j 2" has followed this path, good for everyone.

No objection, then?


Gilles

> [1] http://commons.apache.org/releases/versioning.html
> [2] http://commons.apache.org/proper/commons-math/proposal.html
>
> Thomas
>
>
>> If there are now well-formed answers proving that the fear was
>> unfounded, that is also a change.
>>
>> IMO, logging is quite important for any "non-obvious" code.[1]
>> [I'm again stating that, in that respect, CM is not like the other
>> "Commmons" components.]
>>
>> Several times, I've been obliged to create a modified version of CM
>> to introduce "print" statements (poor man's logging!) in order to
>> figure out why my code did not do what it was supposed to.
>> It also makes a code easier to debug while developing or modifying
>> it
>> (without resorting to poor man's logging, then deleting the "print",
>> then reinstating them, then deleting them again, ad nauseam).
>>
>> Gilles
>>
>> [1] No quality or complexity judgment implied.
>>
>>
>> Phil
>>>
>>>>
>>>>
>>>> Gilles
>>>>
>>>> Thomas
>>>>>
>>>>>
>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>>
>>>>>> We have been discussing various ways to view what's happening
>>>>>> internally
>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>> I know that
>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>> level
>>>>>> dependency, therefore it should minimize the transitive
>>>>>> dependencies that
>>>>>> it introduces.  The Java community has adopted many means of
>>>>>> dealing with
>>>>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>>>>> for
>>>>>> logging.
>>>>>>
>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>> made me a
>>>>>> bit nervous about this suggestion, so I looked up strategies for
>>>>>> switching
>>>>>> their logger out with SLF4J:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>
>>>>>>
>>>>>> The general process I go through when working with many
>>>>>> dependencies that
>>>>>> might use commons-logging instead of SLF4J looks something like
>>>>>> this:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>
>>>>>>
>>>>>> With JDK9 individual modules can define their own isolated set
>>>>>> of
>>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>>> someone has
>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>> could use
>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Cheers,
>>>>>> - Ole
>>>>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Hasan Diwan
On 25 September 2015 at 16:47, Gilles <[hidden email]> wrote:

> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
>
>> On Fri, Sep 25, 2015 at 5:09 PM, Gilles <[hidden email]>
>> wrote:
>>
>> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:
>>>
>>> On 9/25/15 7:03 AM, Gilles wrote:
>>>>
>>>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>>>>>
>>>>> Hi Ole,
>>>>>>
>>>>>> for a start, I think you are asking the wrong question.
>>>>>> First of all we need to agree that we want to add some kind of
>>>>>> logging
>>>>>> facility to CM.
>>>>>> If the outcome is positive, there are a handful of alternatives,
>>>>>> some of
>>>>>> them more viable than slf4j in the context of CM (e.g. JUL or
>>>>>> commons-logging).
>>>>>>
>>>>>>
>>>>> Could someone summarize why those alternatives were deemed "more
>>>>> viable"?
>>>>>
>>>>> btw. the same discussion has been done for other commons
>>>>>
>>>>>> components as
>>>>>> well, and the result usually was: do not add logging
>>>>>>
>>>>>>
>>>>> What was the rationale?
>>>>>
>>>>>
>>>> Look at the archives.  We have discussed this multiple times in the
>>>> past in [math] and each time came to the conclusion that Thomas
>>>> succinctly states above.  What has changed now?
>>>>
>>>>
>>> We also discussed several times to stick with Java 5.
>>> Fortunately, that has changed. [Although sticking with Java 7 is still
>>> a bad decision IMHO.]
>>>
>>> As for logging, IIRC, the sole argument was "no dependency" because
>>> (IIRC) of the potential "JAR hell".
>>>
>>>
>> that's not correct. The decision to not include any dependencies has
>> nothing to do with "JAR hell".
>>
>
> Although I can't find it now, I'm pretty sure that I more than once
> got such an answer.
>
> In order to prevent JAR hell, commons components strictly stick to the
>> "Versioning guidelines" [1]
>>
>
> I can't see how it relates.
> But if you mean that no JAR hell can emerge from using a logging framework,
> then that's good news.
>
> The no-dependency rule is more related to the proposal of the component,
>> see [2]
>>
>
> Thanks for the reminder; in that document, we read:
>
>   (1) Scope of the Package
>    [...]
>    5. Limited dependencies. No external dependencies beyond Commons
> components and the JDK
>
> So we are fine if use "Log4j 2" as kindly offered by Gary.
>
> My long-standing mentioning of slf4j was only because of its
> "weightlessness" (thanks to the no-op implementation of its API).
> If "Log4j 2" has followed this path, good for everyone.
>
> No objection, then?


I'm still not clear what log4j 2 adds -- most Apache java projects seem to
use log4j 1.2, seems to work well. -- H

>
>
>
> Gilles
>
>
> [1] http://commons.apache.org/releases/versioning.html
>> [2] http://commons.apache.org/proper/commons-math/proposal.html
>>
>> Thomas
>>
>>
>> If there are now well-formed answers proving that the fear was
>>> unfounded, that is also a change.
>>>
>>> IMO, logging is quite important for any "non-obvious" code.[1]
>>> [I'm again stating that, in that respect, CM is not like the other
>>> "Commmons" components.]
>>>
>>> Several times, I've been obliged to create a modified version of CM
>>> to introduce "print" statements (poor man's logging!) in order to
>>> figure out why my code did not do what it was supposed to.
>>> It also makes a code easier to debug while developing or modifying it
>>> (without resorting to poor man's logging, then deleting the "print",
>>> then reinstating them, then deleting them again, ad nauseam).
>>>
>>> Gilles
>>>
>>> [1] No quality or complexity judgment implied.
>>>
>>>
>>> Phil
>>>
>>>>
>>>>
>>>>>
>>>>> Gilles
>>>>>
>>>>> Thomas
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>>
>>>>>>> We have been discussing various ways to view what's happening
>>>>>>> internally
>>>>>>> with algorithms, and the topic of including SLF4J has come up.
>>>>>>> I know that
>>>>>>> this was discussed earlier and it was decided that CM is a low
>>>>>>> level
>>>>>>> dependency, therefore it should minimize the transitive
>>>>>>> dependencies that
>>>>>>> it introduces.  The Java community has adopted many means of
>>>>>>> dealing with
>>>>>>> potential logging conflicts, so I'm requesting that we use SLF4J
>>>>>>> for
>>>>>>> logging.
>>>>>>>
>>>>>>> I know that JBoss introduced its own logging system, and this
>>>>>>> made me a
>>>>>>> bit nervous about this suggestion, so I looked up strategies for
>>>>>>> switching
>>>>>>> their logger out with SLF4J:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
>>>>>>>
>>>>>>>
>>>>>>> The general process I go through when working with many
>>>>>>> dependencies that
>>>>>>> might use commons-logging instead of SLF4J looks something like
>>>>>>> this:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
>>>>>>>
>>>>>>>
>>>>>>> With JDK9 individual modules can define their own isolated set of
>>>>>>> dependencies.  At this point the fix should be a permanent.  If
>>>>>>> someone has
>>>>>>> has a very intricate scenario that we have not yet seen, they
>>>>>>> could use
>>>>>>> (And probably should use) OSGi to isolate dependencies.
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> - Ole
>>>>>>>
>>>>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
OpenPGP: https://hasan.d8u.us/gpg.key
Sent from my mobile device
Envoyé de mon portable
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Bernd Eckenfels
In reply to this post by Gilles Sadowski
For such a simple case like logging in a (math) library you can also use
the JDK jul logging.

However I really do not see a need for it (and I
think it can negatively impact the user experience of a lib if it does
logging even when it has no environmental interactions)


Am Sat, 26 Sep
2015 01:47:09 +0200 schrieb Gilles <[hidden email]>:

> Thanks for the reminder; in that document, we read:
>
>    (1) Scope of the Package
>     [...]
>     5. Limited dependencies. No external dependencies beyond Commons
> components and the JDK
>
> So we are fine if use "Log4j 2" as kindly offered by Gary.
>
> My long-standing mentioning of slf4j was only because of its
> "weightlessness" (thanks to the no-op implementation of its API).
> If "Log4j 2" has followed this path, good for everyone.
>
> No objection, then?

Uh, be carefull with the trigger of that gun you point at somenes
chest :)

Gruss
Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Gilles Sadowski
On Sat, 26 Sep 2015 02:00:13 +0200, Bernd Eckenfels wrote:
> For such a simple case like logging in a (math) library you can also
> use
> the JDK jul logging.

This may make you change your mind:
   
http://stackoverflow.com/questions/11359187/why-not-use-java-util-logging

> However I really do not see a need for it

Examples were given in this thread.

> (and I
> think it can negatively impact the user experience of a lib if it
> does
> logging even when it has no environmental interactions)

Could you elaborate on "negatively impact"?  Thanks.

>
> Am Sat, 26 Sep
> 2015 01:47:09 +0200 schrieb Gilles <[hidden email]>:
>
>> Thanks for the reminder; in that document, we read:
>>
>>    (1) Scope of the Package
>>     [...]
>>     5. Limited dependencies. No external dependencies beyond Commons
>> components and the JDK
>>
>> So we are fine if use "Log4j 2" as kindly offered by Gary.
>>
>> My long-standing mentioning of slf4j was only because of its
>> "weightlessness" (thanks to the no-op implementation of its API).
>> If "Log4j 2" has followed this path, good for everyone.
>>
>> No objection, then?
>
> Uh, be carefull with the trigger of that gun you point at somenes
> chest :)

Sure. :-D

Regards,
Gilles


> Gruss
> Bernd
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Utilitzation of SLF4J?

Gilles Sadowski
In reply to this post by Hasan Diwan
On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:

> On 25 September 2015 at 16:47, Gilles <[hidden email]>
> wrote:
>
>> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
>>
>>> On Fri, Sep 25, 2015 at 5:09 PM, Gilles
>>> <[hidden email]>
>>> wrote:
>>>
>>> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:
>>>>
>>>> On 9/25/15 7:03 AM, Gilles wrote:
>>>>>
>>>>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>>>>>>
>>>>>> Hi Ole,
>>>>>>>
>>>>>>> for a start, I think you are asking the wrong question.
>>>>>>> First of all we need to agree that we want to add some kind of
>>>>>>> logging
>>>>>>> facility to CM.
>>>>>>> If the outcome is positive, there are a handful of
>>>>>>> alternatives,
>>>>>>> some of
>>>>>>> them more viable than slf4j in the context of CM (e.g. JUL or
>>>>>>> commons-logging).
>>>>>>>
>>>>>>>
>>>>>> Could someone summarize why those alternatives were deemed "more
>>>>>> viable"?
>>>>>>
>>>>>> btw. the same discussion has been done for other commons
>>>>>>
>>>>>>> components as
>>>>>>> well, and the result usually was: do not add logging
>>>>>>>
>>>>>>>
>>>>>> What was the rationale?
>>>>>>
>>>>>>
>>>>> Look at the archives.  We have discussed this multiple times in
>>>>> the
>>>>> past in [math] and each time came to the conclusion that Thomas
>>>>> succinctly states above.  What has changed now?
>>>>>
>>>>>
>>>> We also discussed several times to stick with Java 5.
>>>> Fortunately, that has changed. [Although sticking with Java 7 is
>>>> still
>>>> a bad decision IMHO.]
>>>>
>>>> As for logging, IIRC, the sole argument was "no dependency"
>>>> because
>>>> (IIRC) of the potential "JAR hell".
>>>>
>>>>
>>> that's not correct. The decision to not include any dependencies
>>> has
>>> nothing to do with "JAR hell".
>>>
>>
>> Although I can't find it now, I'm pretty sure that I more than once
>> got such an answer.
>>
>> In order to prevent JAR hell, commons components strictly stick to
>> the
>>> "Versioning guidelines" [1]
>>>
>>
>> I can't see how it relates.
>> But if you mean that no JAR hell can emerge from using a logging
>> framework,
>> then that's good news.
>>
>> The no-dependency rule is more related to the proposal of the
>> component,
>>> see [2]
>>>
>>
>> Thanks for the reminder; in that document, we read:
>>
>>   (1) Scope of the Package
>>    [...]
>>    5. Limited dependencies. No external dependencies beyond Commons
>> components and the JDK
>>
>> So we are fine if use "Log4j 2" as kindly offered by Gary.
>>
>> My long-standing mentioning of slf4j was only because of its
>> "weightlessness" (thanks to the no-op implementation of its API).
>> If "Log4j 2" has followed this path, good for everyone.
>>
>> No objection, then?
>
>
> I'm still not clear what log4j 2 adds -- most Apache java projects
> seem to
> use log4j 1.2, seems to work well. -- H
>

I can only answer about "slf4j" where the "f" stands for facade: it's
"only"
an API, with bridges to several logging frameworks (log4j, logback,
etc.).

The separation of concerns (API vs one of several implementations to
choose from)
allows the top-level application to uniformly configure logging or to
disable it
completely (if choosing the "no-op" implementation).

Hopefully, this flexibility has been included in "Log4j 2" (TBC by the
experts).

Regards,
Gilles

>>
>>
>>
>>>>> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123