subject:"\[Math\] Utilitzation of SLF4J\?"


On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:

On 09/26/2015 02:33 AM, Gilles wrote:

On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
On 25 September 2015 at 16:47, Gilles 


wrote:


On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:

On Fri, Sep 25, 2015 at 5:09 PM, 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".


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.


log4j is not a commons component btw.


Too bad for me. :-/
Case resolved, then, by the argument of authority?
"Commons" is OK but not another Apache project, by virtue of a
document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not to
mention that the "scope" of CM currently goes well beyond "the most
common practical problems not immediately available in the Java
programming language")...

What's the _technical_ rationale for accepting this dependency and
not accepting that dependency?

I have not seen a single example of a useful logging message that 
could
be added to commons-math, but we are already discussing which 
framework

to use.


If it is not useful to you, why would you conclude that it is not
useful to others?

At the cost of repeating myself, once more, the use-case is not
primarily about debugging CM, but sometimes one could need to assess
how a "non-obvious" CM algorithm responds to an application's request.
I've clearly expressed that use-case in a previous message.

Another example: I have a class that wraps a CM root solver; it is
stuffed with log statements because the message contained in the
"NoBracketingException" was utterly insufficient (and plainly
misleading due the default formatting of numbers) to figure out why
certain calls succeeded and others not.
It's a problem (or a limitation) in the application, but in the
absence of other clues, tracing the solver could help figure out a
workaround.
The alternative to the "logging" approach, would have been to include
a precondition check before calling the solver, that would in effect
duplicate the bracketing check done inside the solver. Given the vast
amount of cases where the code ran smoothly, this is clearly a
sub-optimal solution as compared to turning logging on and rerun the
case that led to a crash.

What can I say more about the usefulness (for a "low-tech" person
like me) than the intro here:
  http://logging.apache.org/log4j/2.x/manual/index.html
?

The examples with println debugging are not valid imho, because how 
do
you know in advance what you will need to log in order to 
successfully

debug some piece of code and such low-level information should not be
captured in logs anyway.


Why are there several log levels?  Low-level info can be routed to
"DEBUG" or "TRACE".
As Ole put it quite eloquently, logging is a safety net that we hope
we'll never need, until we do.

Each layer of an application has its own notion of what is the
appropriate log level. What is "INFO" for some low-level library
will very probably not be so for most applications that use the
library.
Setting levels per package or class takes care of that: it's the
library's *user* who chooses what is useful in the

Re: [Math] Utilitzation of SLF4J?

2015-09-26 Thread Thomas Neidhart

On 09/26/2015 01:11 PM, Gilles wrote:
> On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
>> On 09/26/2015 02:33 AM, Gilles wrote:
>>> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
 On 25 September 2015 at 16:47, Gilles 
 wrote:

> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
>
>> On Fri, Sep 25, 2015 at 5:09 PM, 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".
>>>
>>>
>> 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.
>>
>> log4j is not a commons component btw.
> 
> Too bad for me. :-/
> Case resolved, then, by the argument of authority?

I just pointed out that log4j is not a commons component and did not
imply anything else.

> "Commons" is OK but not another Apache project, by virtue of a
> document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not to
> mention that the "scope" of CM currently goes well beyond "the most
> common practical problems not immediately available in the Java
> programming language")...
> 
> What's the _technical_ rationale for accepting this dependency and
> not accepting that dependency?
> 
>> I have not seen a single example of a useful logging message that could
>> be added to commons-math, but we are already discussing which framework
>> to use.
> 
> If it is not useful to you, why would you conclude that it is not
> useful to others?
> 
> At the cost of repeating myself, once more, the use-case is not
> primarily about debugging CM, but sometimes one could need to assess
> how a "non-obvious" CM algorithm responds to an application's request.
> I've clearly expressed that use-case in a previous message.
> 
> Another example: I have a class that wraps a CM root solver; it is
> stuffed with log statements because the message contained in the
> "NoBracketingException" was utterly insufficient (and plainly
> misleading due the default formatting of numbers) to figure out why
> certain calls succeeded and others not.
> It's a problem (or a limitation) in the application, but in the
> absence of other clues, tracing the solver could help figure out a
> workaround.
> The alternative to the "logging" approach, would have been to include
> a precondition check before calling the solver, that would in effect
> duplicate the bracketing check done inside the solver. Given the vast
> amount of cases where the code ran smoothly, this is clearly a
> sub-optimal solution as compared to turning logging on and rerun the
> case that led to a crash.
> 
> What can I say more about the usefulness (for a "low-tech" person
> like me) than the intro

Re: [Math] Utilitzation of SLF4J?


On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:

On 9/26/15 4:56 AM, Thomas Neidhart wrote:

On 09/26/2015 01:11 PM, Gilles wrote:

On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:

On 09/26/2015 02:33 AM, Gilles wrote:

On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
On 25 September 2015 at 16:47, Gilles 


wrote:


On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:


On Fri, Sep 25, 2015 at 5:09 PM, 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".


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.

log4j is not a commons component btw.

Too bad for me. :-/
Case resolved, then, by the argument of authority?

I just pointed out that log4j is not a commons component and did not
imply anything else.


"Commons" is OK but not another Apache project, by virtue of a
document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not to
mention that the "scope" of CM currently goes well beyond "the most
common practical problems not immediately available in the Java
programming language")...

What's the _technical_ rationale for accepting this dependency and
not accepting that dependency?

I have not seen a single example of a useful logging message that 
could
be added to commons-math, but we are already discussing which 
framework

to use.

If it is not useful to you, why would you conclude that it is not
useful to others?

At the cost of repeating myself, once more, the use-case is not
primarily about debugging CM, but sometimes one could need to 
assess
how a "non-obvious" CM algorithm responds to an application's 
request.

I've clearly expressed that use-case in a previous message.

Another example: I have a class that wraps a CM root solver; it is
stuffed with log statements because the message contained in the
"NoBracketingException" was utterly insufficient (and plainly
misleading due the default formatting of numbers) to figure out why
certain calls succeeded and others not.
It's a problem (or a limitation) in the application, but in the
absence of other clues, tracing the solver could help figure out a
workaround.
The alternative to the "logging" approach, would have been to 
include
a precondition check before calling the solver, that would in 
effect
duplicate the bracketing check done inside the solver. Given the 
vast

amount of cases where the code ran smoothly, this is clearly a
sub-optimal solution as compared to turning logging on and rerun 
the

case that led to a crash.

What can I say more about the usefulness (for a "low-tech" person
like me) than the intro here:
  http://logging.apache.org/log4j/2.x/manual/index.html
?

The examples with println debugging are not valid imho, because 
how do
you know in advance what you will need to log in order to 
successfully
debug some piece of code and such low-level information should not 
be

captured in logs anyway.

Why are there several log levels?  Low-level info can be routed to
"DEBUG" or "TRACE".
As Ole put it quite eloquently, logging is a safety net that we 
hope

we'll never need, until we do.

Each layer of an application has its own notion of what is the
appropriate log

Re: [Math] Utilitzation of SLF4J?

2015-09-26 Thread Phil Steitz

On 9/26/15 4:56 AM, Thomas Neidhart wrote:
> On 09/26/2015 01:11 PM, Gilles wrote:
>> On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
>>> On 09/26/2015 02:33 AM, Gilles wrote:
 On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
> On 25 September 2015 at 16:47, Gilles 
> wrote:
>
>> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
>>
>>> On Fri, Sep 25, 2015 at 5:09 PM, 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".


>>> 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.
>>> log4j is not a commons component btw.
>> Too bad for me. :-/
>> Case resolved, then, by the argument of authority?
> I just pointed out that log4j is not a commons component and did not
> imply anything else.
>
>> "Commons" is OK but not another Apache project, by virtue of a
>> document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not to
>> mention that the "scope" of CM currently goes well beyond "the most
>> common practical problems not immediately available in the Java
>> programming language")...
>>
>> What's the _technical_ rationale for accepting this dependency and
>> not accepting that dependency?
>>
>>> I have not seen a single example of a useful logging message that could
>>> be added to commons-math, but we are already discussing which framework
>>> to use.
>> If it is not useful to you, why would you conclude that it is not
>> useful to others?
>>
>> At the cost of repeating myself, once more, the use-case is not
>> primarily about debugging CM, but sometimes one could need to assess
>> how a "non-obvious" CM algorithm responds to an application's request.
>> I've clearly expressed that use-case in a previous message.
>>
>> Another example: I have a class that wraps a CM root solver; it is
>> stuffed with log statements because the message contained in the
>> "NoBracketingException" was utterly insufficient (and plainly
>> misleading due the default formatting of numbers) to figure out why
>> certain calls succeeded and others not.
>> It's a problem (or a limitation) in the application, but in the
>> absence of other clues, tracing the solver could help figure out a
>> workaround.
>> The alternative to the "logging" approach, would have been to include
>> a precondition check before calling the solver, that would in effect
>> duplicate the bracketing check done inside the solver. Given the vast
>> amount of cases where the code ran smoothly, this is clearly a
>> sub-optimal solution as compared to turning logging on and rerun the
>> case that led to a crash.
>>

Re: [Math] Utilitzation of SLF4J?

2015-09-26 Thread Phil Steitz

On 9/26/15 9:42 AM, Gilles wrote:
> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
>> On 9/26/15 4:56 AM, Thomas Neidhart wrote:
>>> On 09/26/2015 01:11 PM, Gilles wrote:
 On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
> On 09/26/2015 02:33 AM, Gilles wrote:
>> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
>>> On 25 September 2015 at 16:47, Gilles
>>> 
>>> wrote:
>>>
 On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:

> On Fri, Sep 25, 2015 at 5:09 PM, 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".
>>
>>
> 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.
> log4j is not a commons component btw.
 Too bad for me. :-/
 Case resolved, then, by the argument of authority?
>>> I just pointed out that log4j is not a commons component and did
>>> not
>>> imply anything else.
>>>
 "Commons" is OK but not another Apache project, by virtue of a
 document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not to
 mention that the "scope" of CM currently goes well beyond "the
 most
 common practical problems not immediately available in the Java
 programming language")...

 What's the _technical_ rationale for accepting this dependency and
 not accepting that dependency?

> I have not seen a single example of a useful logging message
> that could
> be added to commons-math, but we are already discussing which
> framework
> to use.
 If it is not useful to you, why would you conclude that it is not
 useful to others?

 At the cost of repeating myself, once more, the use-case is not
 primarily about debugging CM, but sometimes one could need to
 assess
 how a "non-obvious" CM algorithm responds to an application's
 request.
 I've clearly expressed that use-case in a previous message.

 Another example: I have a class that wraps a CM root solver; it is
 stuffed with log statements because the message contained in the
 "NoBracketingException" was utterly insufficient (and plainly
 misleading due the default formatting of numbers) to figure out
 why
 certain calls succeeded and others not.
 It's a problem (or a

Re: [Math] Utilitzation of SLF4J?


On Sat, 26 Sep 2015 10:02:12 -0700, Phil Steitz wrote:

On 9/26/15 9:42 AM, Gilles wrote:

On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:

On 9/26/15 4:56 AM, Thomas Neidhart wrote:

On 09/26/2015 01:11 PM, Gilles wrote:

On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:

On 09/26/2015 02:33 AM, Gilles wrote:

On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:

On 25 September 2015 at 16:47, Gilles

wrote:


On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:


On Fri, Sep 25, 2015 at 5:09 PM, 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".



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.

log4j is not a commons component btw.

Too bad for me. :-/
Case resolved, then, by the argument of authority?

I just pointed out that log4j is not a commons component and did
not
imply anything else.


"Commons" is OK but not another Apache project, by virtue of a
document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not 
to

mention that the "scope" of CM currently goes well beyond "the
most
common practical problems not immediately available in the Java
programming language")...

What's the _technical_ rationale for accepting this dependency 
and

not accepting that dependency?


I have not seen a single example of a useful logging message
that could
be added to commons-math, but we are already discussing which
framework
to use.

If it is not useful to you, why would you conclude that it is not
useful to others?

At the cost of repeating myself, once more, the use-case is not
primarily about debugging CM, but sometimes one could need to
assess
how a "non-obvious" CM algorithm responds to an application's
request.
I've clearly expressed that use-case in a previous message.

Another example: I have a class that wraps a CM root solver; it 
is

stuffed with log statements because the message contained in the
"NoBracketingException" was utterly insufficient (and plainly
misleading due the default formatting of numbers) to figure out
why
certain calls succeeded and others not.
It's a problem (or a limitation) in the application, but in the
absence of other clues, tracing the solver could help figure out 
a

workaround.
The alternative to the "logging" approach, would have been to
include
a precondition check before calling the solver, that would in
effect
duplicate the bracketing check done inside the solver. Given
the vast
amount of cases where the code ran smoothly, this is clearly a
sub-optimal solution as compared to turning logging on and
rerun the
case that led to a crash.

What can I say more about the usefulness (for a "low-tech" person
like me) than the intro here:
  http://logging.apache.org/log4j/2.x/manual/index.html
?


The examples with println debugging are not valid imho,
because how do
you know in advance what you will need to log in order to
successfully
debug some piece of code and such low-level information should
not be
captured in logs anyway.
Why are there several log levels?  Low-level info can be routed 
to

"DEBUG" or "TRACE".
As Ole put it quite eloquently, logging is a safety net that we
hope
we'll never need, until we do.

Each layer of an

Re: [Math] Utilitzation of SLF4J?

2015-09-26 Thread Dave Brosius


slf4j-api.jar also has no required dependencies.

On 09/26/2015 06:14 PM, Ralph Goers wrote:

The Log4j API has no dependencies.  Log4j-core only requires log4j-api.  It has 
lots of optional features and so has lots of optional dependencies, but none 
are required.

Ralph



On Sep 26, 2015, at 1:09 PM, Luc Maisonobe  wrote:

Le 26/09/2015 21:49, Romain Manni-Bucau a écrit :

Le 26 sept. 2015 12:07, "Luc Maisonobe"  a écrit :

Le 26/09/2015 20:59, Ralph Goers a écrit :

I don’t normally participate in Math but I do feel the need to stick my

nose in here.

1. You are absolutely correct to determine whether you need logging at

all before discussing what to choose.

2. If you do decide logging is required:
  a. Please stay away from java.util.logging. It really would be the

best solution for a framework like math except it is extremely difficult to
redirect efficiently to some other logging framework. The methods used by
SLF4J and Log4j are imperfect to say the least.

  b. Log4j 1.x has reached eol. It effectively has not been supported

for 5 years.

  c. Log4j 2 has an API that can be redirected to another logging

framework if desired.

  d. Commons logging still works but its API is very primitive by

todays standards. That said, it does work.

 From what I have seen, if I ever were to choose a logging framework for
any project, I agree log4j 2 is currently the best choice. I was
impressed by slf4j a few years ago, but think now the step further is
log4j 2 (without any accurate reason, just a rough feeling).


And in 2 years foolog4j will be better. JUL is not perfect for sure but
ensures:
- no dep
- always usable
- allows to let the user integrate with the lib without having to fork it
to get rid of a logging dep - think to tomee which consumes N commons deps,
if all uses a different logging framework it is worse to configure and
highly inconsistent - that is why we chose jul by default

That is for the logging framework choice.
Now commons shouldnt log much IMO otherwise it would start to loose commons
in sense of shareable component cause of the integration issues it
generates in the final application.

Big +1 to this. For the [math] case (and commons at whole), dependencies
should be avoided. In fact looking at log4j pom (even the core pom) one
can notice it depends on several commons components. This makes me think
more and more that commons components are the lowest possible level,
just above java itself.

So I think my message above was already out of scope. It may apply to
some applications, but not to commons.

thanks for reminding me about that, Romain!

best regards,
Luc


- Romain


best regards,
Luc


Ralph



On Sep 26, 2015, at 10:07 AM, Luc Maisonobe  wrote:

Le 26/09/2015 18:42, Gilles a écrit :

On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:

On 9/26/15 4:56 AM, Thomas Neidhart wrote:

On 09/26/2015 01:11 PM, Gilles wrote:

On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:

On 09/26/2015 02:33 AM, Gilles wrote:

On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:

On 25 September 2015 at 16:47, Gilles <

gil...@harfang.homelinux.org>

wrote:


On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:


On Fri, Sep 25, 2015 at 5:09 PM, 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".



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]

Re: [Math] Utilitzation of SLF4J?


On Sat, 26 Sep 2015 22:09:35 +0200, Luc Maisonobe wrote:

Le 26/09/2015 21:49, Romain Manni-Bucau a écrit :
Le 26 sept. 2015 12:07, "Luc Maisonobe"  a écrit 
:


Le 26/09/2015 20:59, Ralph Goers a écrit :
I don’t normally participate in Math but I do feel the need to 
stick my

nose in here.
1. You are absolutely correct to determine whether you need 
logging at

all before discussing what to choose.

2. If you do decide logging is required:
  a. Please stay away from java.util.logging. It really would be 
the
best solution for a framework like math except it is extremely 
difficult to
redirect efficiently to some other logging framework. The methods 
used by

SLF4J and Log4j are imperfect to say the least.
  b. Log4j 1.x has reached eol. It effectively has not been 
supported

for 5 years.

  c. Log4j 2 has an API that can be redirected to another logging

framework if desired.

  d. Commons logging still works but its API is very primitive by

todays standards. That said, it does work.


From what I have seen, if I ever were to choose a logging framework 
for

any project, I agree log4j 2 is currently the best choice. I was
impressed by slf4j a few years ago, but think now the step further 
is

log4j 2 (without any accurate reason, just a rough feeling).



And in 2 years foolog4j will be better. JUL is not perfect for sure 
but

ensures:
- no dep
- always usable
- allows to let the user integrate with the lib without having to 
fork it
to get rid of a logging dep - think to tomee which consumes N 
commons deps,
if all uses a different logging framework it is worse to configure 
and

highly inconsistent - that is why we chose jul by default

That is for the logging framework choice.
Now commons shouldnt log much IMO otherwise it would start to loose 
commons

in sense of shareable component cause of the integration issues it
generates in the final application.


Big +1 to this. For the [math] case (and commons at whole), 
dependencies
should be avoided. In fact looking at log4j pom (even the core pom) 
one
can notice it depends on several commons components. This makes me 
think

more and more that commons components are the lowest possible level,
just above java itself.

So I think my message above was already out of scope. It may apply to
some applications, but not to commons.

thanks for reminding me about that, Romain!


No, you are confusing API (required to write log statements in
the source code) and implementation (required to perform actual
logging at runtime)!
Please see:
 http://logging.apache.org/log4j/2.x/runtime-dependencies.html
which states quite clearly
-
The Log4J API module has no external dependencies.
-

[Same for slf4j-api.]

Gilles



best regards,
Luc



- Romain


best regards,
Luc



Ralph


On Sep 26, 2015, at 10:07 AM, Luc Maisonobe  
wrote:


Le 26/09/2015 18:42, Gilles a écrit :

On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:

On 9/26/15 4:56 AM, Thomas Neidhart wrote:

On 09/26/2015 01:11 PM, Gilles wrote:

On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:

On 09/26/2015 02:33 AM, Gilles wrote:

On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:

On 25 September 2015 at 16:47, Gilles <

gil...@harfang.homelinux.org>

wrote:

On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart 
wrote:



On Fri, Sep 25, 2015 at 5:09 PM, 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".



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

Re: [Math] Utilitzation of SLF4J?

2015-09-26 Thread Ralph Goers

The Log4j API has no dependencies.  Log4j-core only requires log4j-api.  It has 
lots of optional features and so has lots of optional dependencies, but none 
are required.

Ralph


> On Sep 26, 2015, at 1:09 PM, Luc Maisonobe  wrote:
> 
> Le 26/09/2015 21:49, Romain Manni-Bucau a écrit :
>> Le 26 sept. 2015 12:07, "Luc Maisonobe"  a écrit :
>>> 
>>> Le 26/09/2015 20:59, Ralph Goers a écrit :
 I don’t normally participate in Math but I do feel the need to stick my
>> nose in here.
 1. You are absolutely correct to determine whether you need logging at
>> all before discussing what to choose.
 2. If you do decide logging is required:
  a. Please stay away from java.util.logging. It really would be the
>> best solution for a framework like math except it is extremely difficult to
>> redirect efficiently to some other logging framework. The methods used by
>> SLF4J and Log4j are imperfect to say the least.
  b. Log4j 1.x has reached eol. It effectively has not been supported
>> for 5 years.
  c. Log4j 2 has an API that can be redirected to another logging
>> framework if desired.
  d. Commons logging still works but its API is very primitive by
>> todays standards. That said, it does work.
>>> 
>>> From what I have seen, if I ever were to choose a logging framework for
>>> any project, I agree log4j 2 is currently the best choice. I was
>>> impressed by slf4j a few years ago, but think now the step further is
>>> log4j 2 (without any accurate reason, just a rough feeling).
>>> 
>> 
>> And in 2 years foolog4j will be better. JUL is not perfect for sure but
>> ensures:
>> - no dep
>> - always usable
>> - allows to let the user integrate with the lib without having to fork it
>> to get rid of a logging dep - think to tomee which consumes N commons deps,
>> if all uses a different logging framework it is worse to configure and
>> highly inconsistent - that is why we chose jul by default
>> 
>> That is for the logging framework choice.
>> Now commons shouldnt log much IMO otherwise it would start to loose commons
>> in sense of shareable component cause of the integration issues it
>> generates in the final application.
> 
> Big +1 to this. For the [math] case (and commons at whole), dependencies
> should be avoided. In fact looking at log4j pom (even the core pom) one
> can notice it depends on several commons components. This makes me think
> more and more that commons components are the lowest possible level,
> just above java itself.
> 
> So I think my message above was already out of scope. It may apply to
> some applications, but not to commons.
> 
> thanks for reminding me about that, Romain!
> 
> best regards,
> Luc
> 
>> 
>> - Romain
>> 
>>> best regards,
>>> Luc
>>> 
 
 Ralph
 
 
> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe  wrote:
> 
> Le 26/09/2015 18:42, Gilles a écrit :
>> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
>>> On 9/26/15 4:56 AM, Thomas Neidhart wrote:
 On 09/26/2015 01:11 PM, Gilles wrote:
> On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
>> On 09/26/2015 02:33 AM, Gilles wrote:
>>> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
 On 25 September 2015 at 16:47, Gilles <
>> gil...@harfang.homelinux.org>
 wrote:
 
> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
> 
>> On Fri, Sep 25, 2015 at 5:09 PM, 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

Re: [Math] Utilitzation of SLF4J?

2015-09-26 Thread Ralph Goers

Romain, 

Choosing JUL for a framework does a HUGE disservice to the users of your 
framework. JUL is by far the worst logging framework design of anything you 
could choose. It is like the JDK designers purposely chose to use a mechanism 
to map their API to another implementation that really doesn’t work.  SLF4J 
handles this by not bypassing it and using a JUL handler to map everything into 
it, and then uses an “interesting” scheme to try to make that perform well. 
Log4j tries to use the method documented by JUL but it has a few problems.

Ralph

> On Sep 26, 2015, at 12:49 PM, Romain Manni-Bucau  
> wrote:
> 
> Le 26 sept. 2015 12:07, "Luc Maisonobe"  > a écrit :
>> 
>> Le 26/09/2015 20:59, Ralph Goers a écrit :
>>> I don’t normally participate in Math but I do feel the need to stick my
> nose in here.
>>> 1. You are absolutely correct to determine whether you need logging at
> all before discussing what to choose.
>>> 2. If you do decide logging is required:
>>>  a. Please stay away from java.util.logging. It really would be the
> best solution for a framework like math except it is extremely difficult to
> redirect efficiently to some other logging framework. The methods used by
> SLF4J and Log4j are imperfect to say the least.
>>>  b. Log4j 1.x has reached eol. It effectively has not been supported
> for 5 years.
>>>  c. Log4j 2 has an API that can be redirected to another logging
> framework if desired.
>>>  d. Commons logging still works but its API is very primitive by
> todays standards. That said, it does work.
>> 
>> From what I have seen, if I ever were to choose a logging framework for
>> any project, I agree log4j 2 is currently the best choice. I was
>> impressed by slf4j a few years ago, but think now the step further is
>> log4j 2 (without any accurate reason, just a rough feeling).
>> 
> 
> And in 2 years foolog4j will be better. JUL is not perfect for sure but
> ensures:
> - no dep
> - always usable
> - allows to let the user integrate with the lib without having to fork it
> to get rid of a logging dep - think to tomee which consumes N commons deps,
> if all uses a different logging framework it is worse to configure and
> highly inconsistent - that is why we chose jul by default
> 
> That is for the logging framework choice.
> Now commons shouldnt log much IMO otherwise it would start to loose commons
> in sense of shareable component cause of the integration issues it
> generates in the final application.
> 
> - Romain
> 
>> best regards,
>> Luc
>> 
>>> 
>>> Ralph
>>> 
>>> 
 On Sep 26, 2015, at 10:07 AM, Luc Maisonobe  wrote:
 
 Le 26/09/2015 18:42, Gilles a écrit :
> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
>> On 9/26/15 4:56 AM, Thomas Neidhart wrote:
>>> On 09/26/2015 01:11 PM, Gilles wrote:
 On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
> On 09/26/2015 02:33 AM, Gilles wrote:
>> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
>>> On 25 September 2015 at 16:47, Gilles <
> gil...@harfang.homelinux.org>
>>> wrote:
>>> 
 On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
 
> On Fri, Sep 25, 2015 at 5:09 PM, 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

Re: [Math] Utilitzation of SLF4J?

2015-09-26 Thread Luc Maisonobe

Le 26/09/2015 18:42, Gilles a écrit :
> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
>> On 9/26/15 4:56 AM, Thomas Neidhart wrote:
>>> On 09/26/2015 01:11 PM, Gilles wrote:
 On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
> On 09/26/2015 02:33 AM, Gilles wrote:
>> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
>>> On 25 September 2015 at 16:47, Gilles 
>>> wrote:
>>>
 On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:

> On Fri, Sep 25, 2015 at 5:09 PM, 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".
>>
>>
> 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.
> log4j is not a commons component btw.
 Too bad for me. :-/
 Case resolved, then, by the argument of authority?
>>> I just pointed out that log4j is not a commons component and did not
>>> imply anything else.
>>>
 "Commons" is OK but not another Apache project, by virtue of a
 document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not to
 mention that the "scope" of CM currently goes well beyond "the most
 common practical problems not immediately available in the Java
 programming language")...

 What's the _technical_ rationale for accepting this dependency and
 not accepting that dependency?

> I have not seen a single example of a useful logging message that
> could
> be added to commons-math, but we are already discussing which
> framework
> to use.
 If it is not useful to you, why would you conclude that it is not
 useful to others?

 At the cost of repeating myself, once more, the use-case is not
 primarily about debugging CM, but sometimes one could need to assess
 how a "non-obvious" CM algorithm responds to an application's request.
 I've clearly expressed that use-case in a previous message.

 Another example: I have a class that wraps a CM root solver; it is
 stuffed with log statements because the message contained in the
 "NoBracketingException" was utterly insufficient (and plainly
 misleading due the default formatting of numbers) to figure out why
 certain calls succeeded and others not.
 It's a problem (or a limitation) in the application, but in the
 absence of other clues, tracing the solver could help figure out a

Re: [Math] Utilitzation of SLF4J?

2015-09-26 Thread Romain Manni-Bucau

Le 26 sept. 2015 12:07, "Luc Maisonobe"  a écrit :
>
> Le 26/09/2015 20:59, Ralph Goers a écrit :
> > I don’t normally participate in Math but I do feel the need to stick my
nose in here.
> > 1. You are absolutely correct to determine whether you need logging at
all before discussing what to choose.
> > 2. If you do decide logging is required:
> >   a. Please stay away from java.util.logging. It really would be the
best solution for a framework like math except it is extremely difficult to
redirect efficiently to some other logging framework. The methods used by
SLF4J and Log4j are imperfect to say the least.
> >   b. Log4j 1.x has reached eol. It effectively has not been supported
for 5 years.
> >   c. Log4j 2 has an API that can be redirected to another logging
framework if desired.
> >   d. Commons logging still works but its API is very primitive by
todays standards. That said, it does work.
>
> From what I have seen, if I ever were to choose a logging framework for
> any project, I agree log4j 2 is currently the best choice. I was
> impressed by slf4j a few years ago, but think now the step further is
> log4j 2 (without any accurate reason, just a rough feeling).
>

And in 2 years foolog4j will be better. JUL is not perfect for sure but
ensures:
- no dep
- always usable
- allows to let the user integrate with the lib without having to fork it
to get rid of a logging dep - think to tomee which consumes N commons deps,
if all uses a different logging framework it is worse to configure and
highly inconsistent - that is why we chose jul by default

That is for the logging framework choice.
Now commons shouldnt log much IMO otherwise it would start to loose commons
in sense of shareable component cause of the integration issues it
generates in the final application.

- Romain

> best regards,
> Luc
>
> >
> > Ralph
> >
> >
> >> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe  wrote:
> >>
> >> Le 26/09/2015 18:42, Gilles a écrit :
> >>> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
>  On 9/26/15 4:56 AM, Thomas Neidhart wrote:
> > On 09/26/2015 01:11 PM, Gilles wrote:
> >> On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
> >>> On 09/26/2015 02:33 AM, Gilles wrote:
>  On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
> > On 25 September 2015 at 16:47, Gilles <
gil...@harfang.homelinux.org>
> > wrote:
> >
> >> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
> >>
> >>> On Fri, Sep 25, 2015 at 5:09 PM, 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".
> 
> 
> >>> 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.
> >>

Re: [Math] Utilitzation of SLF4J?

2015-09-26 Thread Luc Maisonobe

Le 26/09/2015 21:49, Romain Manni-Bucau a écrit :
> Le 26 sept. 2015 12:07, "Luc Maisonobe"  a écrit :
>>
>> Le 26/09/2015 20:59, Ralph Goers a écrit :
>>> I don’t normally participate in Math but I do feel the need to stick my
> nose in here.
>>> 1. You are absolutely correct to determine whether you need logging at
> all before discussing what to choose.
>>> 2. If you do decide logging is required:
>>>   a. Please stay away from java.util.logging. It really would be the
> best solution for a framework like math except it is extremely difficult to
> redirect efficiently to some other logging framework. The methods used by
> SLF4J and Log4j are imperfect to say the least.
>>>   b. Log4j 1.x has reached eol. It effectively has not been supported
> for 5 years.
>>>   c. Log4j 2 has an API that can be redirected to another logging
> framework if desired.
>>>   d. Commons logging still works but its API is very primitive by
> todays standards. That said, it does work.
>>
>> From what I have seen, if I ever were to choose a logging framework for
>> any project, I agree log4j 2 is currently the best choice. I was
>> impressed by slf4j a few years ago, but think now the step further is
>> log4j 2 (without any accurate reason, just a rough feeling).
>>
> 
> And in 2 years foolog4j will be better. JUL is not perfect for sure but
> ensures:
> - no dep
> - always usable
> - allows to let the user integrate with the lib without having to fork it
> to get rid of a logging dep - think to tomee which consumes N commons deps,
> if all uses a different logging framework it is worse to configure and
> highly inconsistent - that is why we chose jul by default
> 
> That is for the logging framework choice.
> Now commons shouldnt log much IMO otherwise it would start to loose commons
> in sense of shareable component cause of the integration issues it
> generates in the final application.

Big +1 to this. For the [math] case (and commons at whole), dependencies
should be avoided. In fact looking at log4j pom (even the core pom) one
can notice it depends on several commons components. This makes me think
more and more that commons components are the lowest possible level,
just above java itself.

So I think my message above was already out of scope. It may apply to
some applications, but not to commons.

thanks for reminding me about that, Romain!

best regards,
Luc

> 
> - Romain
> 
>> best regards,
>> Luc
>>
>>>
>>> Ralph
>>>
>>>
 On Sep 26, 2015, at 10:07 AM, Luc Maisonobe  wrote:

 Le 26/09/2015 18:42, Gilles a écrit :
> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
>> On 9/26/15 4:56 AM, Thomas Neidhart wrote:
>>> On 09/26/2015 01:11 PM, Gilles wrote:
 On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
> On 09/26/2015 02:33 AM, Gilles wrote:
>> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
>>> On 25 September 2015 at 16:47, Gilles <
> gil...@harfang.homelinux.org>
>>> wrote:
>>>
 On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:

> On Fri, Sep 25, 2015 at 5:09 PM, 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

Re: [Math] Utilitzation of SLF4J?


On Sat, 26 Sep 2015 19:07:53 +0200, Luc Maisonobe wrote:

Le 26/09/2015 18:42, Gilles a écrit :

On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:

On 9/26/15 4:56 AM, Thomas Neidhart wrote:

On 09/26/2015 01:11 PM, Gilles wrote:

On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:

On 09/26/2015 02:33 AM, Gilles wrote:

On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
On 25 September 2015 at 16:47, Gilles 


wrote:


On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:


On Fri, Sep 25, 2015 at 5:09 PM, 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".



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.

log4j is not a commons component btw.

Too bad for me. :-/
Case resolved, then, by the argument of authority?
I just pointed out that log4j is not a commons component and did 
not

imply anything else.


"Commons" is OK but not another Apache project, by virtue of a
document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not 
to
mention that the "scope" of CM currently goes well beyond "the 
most

common practical problems not immediately available in the Java
programming language")...

What's the _technical_ rationale for accepting this dependency 
and

not accepting that dependency?

I have not seen a single example of a useful logging message 
that

could
be added to commons-math, but we are already discussing which
framework
to use.

If it is not useful to you, why would you conclude that it is not
useful to others?

At the cost of repeating myself, once more, the use-case is not
primarily about debugging CM, but sometimes one could need to 
assess
how a "non-obvious" CM algorithm responds to an application's 
request.

I've clearly expressed that use-case in a previous message.

Another example: I have a class that wraps a CM root solver; it 
is

stuffed with log statements because the message contained in the
"NoBracketingException" was utterly insufficient (and plainly
misleading due the default formatting of numbers) to figure out 
why

certain calls succeeded and others not.
It's a problem (or a limitation) in the application, but in the
absence of other clues, tracing the solver could help figure out 
a

workaround.
The alternative to the "logging" approach, would have been to 
include
a precondition check before calling the solver, that would in 
effect
duplicate the bracketing check done inside the solver. Given the 
vast

amount of cases where the code ran smoothly, this is clearly a
sub-optimal solution as compared to turning logging on and rerun 
the

case that led to a crash.

What can I say more about the usefulness (for a "low-tech" person
like me) than the intro here:
  http://logging.apache.org/log4j/2.x/manual/index.html
?

The examples with println debugging are not valid imho, because 
how do
you know in advance what you will need to log in order to 
successfully
debug some piece of code and such low-level information should 
not be

captured in logs anyway.
Why are there several log levels?  Low-level info can be routed 
to

"DEBUG" or "TRACE".
As Ole put it quite eloquently, logging is a safety net that we 
hope

we'll

Re: [Math] Utilitzation of SLF4J?

2015-09-26 Thread Romain Manni-Bucau

Le 26 sept. 2015 15:19, "Ralph Goers"  a écrit :
>
> Romain,
>
> Choosing JUL for a framework does a HUGE disservice to the users of your
framework. JUL is by far the worst logging framework design of anything you
could choose. It is like the JDK designers purposely chose to use a
mechanism to map their API to another implementation that really doesn’t
work.  SLF4J handles this by not bypassing it and using a JUL handler to
map everything into it, and then uses an “interesting” scheme to try to
make that perform well. Log4j tries to use the method documented by JUL but
it has a few problems.
>

It is contextual, slf4j with its classloader handling is the worse for
other users...all analyzis lead to a really "common" lib shouldnt rely on
any logging API IMHO.

> Ralph
>
> > On Sep 26, 2015, at 12:49 PM, Romain Manni-Bucau 
wrote:
> >
> > Le 26 sept. 2015 12:07, "Luc Maisonobe"  a écrit :
> >>
> >> Le 26/09/2015 20:59, Ralph Goers a écrit :
> >>> I don’t normally participate in Math but I do feel the need to stick
my
> > nose in here.
> >>> 1. You are absolutely correct to determine whether you need logging at
> > all before discussing what to choose.
> >>> 2. If you do decide logging is required:
> >>>  a. Please stay away from java.util.logging. It really would be the
> > best solution for a framework like math except it is extremely
difficult to
> > redirect efficiently to some other logging framework. The methods used
by
> > SLF4J and Log4j are imperfect to say the least.
> >>>  b. Log4j 1.x has reached eol. It effectively has not been supported
> > for 5 years.
> >>>  c. Log4j 2 has an API that can be redirected to another logging
> > framework if desired.
> >>>  d. Commons logging still works but its API is very primitive by
> > todays standards. That said, it does work.
> >>
> >> From what I have seen, if I ever were to choose a logging framework for
> >> any project, I agree log4j 2 is currently the best choice. I was
> >> impressed by slf4j a few years ago, but think now the step further is
> >> log4j 2 (without any accurate reason, just a rough feeling).
> >>
> >
> > And in 2 years foolog4j will be better. JUL is not perfect for sure but
> > ensures:
> > - no dep
> > - always usable
> > - allows to let the user integrate with the lib without having to fork
it
> > to get rid of a logging dep - think to tomee which consumes N commons
deps,
> > if all uses a different logging framework it is worse to configure and
> > highly inconsistent - that is why we chose jul by default
> >
> > That is for the logging framework choice.
> > Now commons shouldnt log much IMO otherwise it would start to loose
commons
> > in sense of shareable component cause of the integration issues it
> > generates in the final application.
> >
> > - Romain
> >
> >> best regards,
> >> Luc
> >>
> >>>
> >>> Ralph
> >>>
> >>>
>  On Sep 26, 2015, at 10:07 AM, Luc Maisonobe 
wrote:
> 
>  Le 26/09/2015 18:42, Gilles a écrit :
> > On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
> >> On 9/26/15 4:56 AM, Thomas Neidhart wrote:
> >>> On 09/26/2015 01:11 PM, Gilles wrote:
>  On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
> > On 09/26/2015 02:33 AM, Gilles wrote:
> >> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
> >>> On 25 September 2015 at 16:47, Gilles <
> > gil...@harfang.homelinux.org>
> >>> wrote:
> >>>
>  On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
> 
> > On Fri, Sep 25, 2015 at 5:09 PM, 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?
> 
> 
>

Re: [Math] Utilitzation of SLF4J?


On Sat, 26 Sep 2015 13:56:29 +0200, Thomas Neidhart wrote:

On 09/26/2015 01:11 PM, Gilles wrote:

On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:

On 09/26/2015 02:33 AM, Gilles wrote:

On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
On 25 September 2015 at 16:47, Gilles 


wrote:


On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:


On Fri, Sep 25, 2015 at 5:09 PM, 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".


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.


log4j is not a commons component btw.


Too bad for me. :-/
Case resolved, then, by the argument of authority?


I just pointed out that log4j is not a commons component and did not
imply anything else.


"Commons" is OK but not another Apache project, by virtue of a
document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not to
mention that the "scope" of CM currently goes well beyond "the most
common practical problems not immediately available in the Java
programming language")...

What's the _technical_ rationale for accepting this dependency and
not accepting that dependency?

I have not seen a single example of a useful logging message that 
could
be added to commons-math, but we are already discussing which 
framework

to use.


If it is not useful to you, why would you conclude that it is not
useful to others?

At the cost of repeating myself, once more, the use-case is not
primarily about debugging CM, but sometimes one could need to assess
how a "non-obvious" CM algorithm responds to an application's 
request.

I've clearly expressed that use-case in a previous message.

Another example: I have a class that wraps a CM root solver; it is
stuffed with log statements because the message contained in the
"NoBracketingException" was utterly insufficient (and plainly
misleading due the default formatting of numbers) to figure out why
certain calls succeeded and others not.
It's a problem (or a limitation) in the application, but in the
absence of other clues, tracing the solver could help figure out a
workaround.
The alternative to the "logging" approach, would have been to 
include

a precondition check before calling the solver, that would in effect
duplicate the bracketing check done inside the solver. Given the 
vast

amount of cases where the code ran smoothly, this is clearly a
sub-optimal solution as compared to turning logging on and rerun the
case that led to a crash.

What can I say more about the usefulness (for a "low-tech" person
like me) than the intro here:
  http://logging.apache.org/log4j/2.x/manual/index.html
?

The examples with println debugging are not valid imho, because how 
do
you know in advance what you will need to log in order to 
successfully
debug some piece of code and such low-level information should not 
be

captured in logs anyway.


Why are there several log levels?  Low-level info can be routed to
"DEBUG" or "TRACE".
As Ole put it quite eloquently, logging is a safety net that we hope
we'll never need, until we do.

Each layer of an application has its own notion of what is the
appropriate log level. What is "INFO" for some

Re: [Math] Utilitzation of SLF4J?


On Sat, 26 Sep 2015 21:07:20 +0200, Luc Maisonobe wrote:

Le 26/09/2015 20:59, Ralph Goers a écrit :
I don’t normally participate in Math but I do feel the need to stick 
my nose in here.
1. You are absolutely correct to determine whether you need logging 
at all before discussing what to choose.

2. If you do decide logging is required:
  a. Please stay away from java.util.logging. It really would be the 
best solution for a framework like math except it is extremely 
difficult to redirect efficiently to some other logging framework. The 
methods used by SLF4J and Log4j are imperfect to say the least.
  b. Log4j 1.x has reached eol. It effectively has not been 
supported for 5 years.
  c. Log4j 2 has an API that can be redirected to another logging 
framework if desired.
  d. Commons logging still works but its API is very primitive by 
todays standards. That said, it does work.


From what I have seen, if I ever were to choose a logging framework 
for

any project, I agree log4j 2 is currently the best choice. I was
impressed by slf4j a few years ago, but think now the step further is
log4j 2 (without any accurate reason, just a rough feeling).


Let us not forget that for a library, we would not have to choose
a logger framework, only a logging API.
IIUC both slf4j and Log4j 2 can plug into each other.


Gilles



best regards,
Luc



Ralph


On Sep 26, 2015, at 10:07 AM, Luc Maisonobe  
wrote:


Le 26/09/2015 18:42, Gilles a écrit :

On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:

On 9/26/15 4:56 AM, Thomas Neidhart wrote:

On 09/26/2015 01:11 PM, Gilles wrote:

On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:

On 09/26/2015 02:33 AM, Gilles wrote:

On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
On 25 September 2015 at 16:47, Gilles 


wrote:


On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:


On Fri, Sep 25, 2015 at 5:09 PM, 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".



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.

log4j is not a commons component btw.

Too bad for me. :-/
Case resolved, then, by the argument of authority?
I just pointed out that log4j is not a commons component and did 
not

imply anything else.


"Commons" is OK but not another Apache project, by virtue of a
document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not 
to
mention that the "scope" of CM currently goes well beyond "the 
most

common practical problems not immediately available in the Java
programming language")...

What's the _technical_ rationale for accepting this dependency 
and

not accepting that dependency?

I have not seen a single example of a useful logging message 
that

could
be added to commons-math, but we are already discussing which
framework
to use.
If it is not useful to you, why would you conclude that it is 
not

useful to others?

At the cost of repeating myself, once more, the use-case is not
primarily about debugging CM, but sometimes one could need to 
assess
how a "non-obvious" CM algorithm responds to an application's 
request.

I've clearly expressed that use-case in a previous message.

Re: [Math] Utilitzation of SLF4J?

2015-09-26 Thread Ralph Goers

I don’t normally participate in Math but I do feel the need to stick my nose in 
here.
1. You are absolutely correct to determine whether you need logging at all 
before discussing what to choose.
2. If you do decide logging is required:
  a. Please stay away from java.util.logging. It really would be the best 
solution for a framework like math except it is extremely difficult to redirect 
efficiently to some other logging framework. The methods used by SLF4J and 
Log4j are imperfect to say the least.
  b. Log4j 1.x has reached eol. It effectively has not been supported for 5 
years.
  c. Log4j 2 has an API that can be redirected to another logging framework if 
desired.
  d. Commons logging still works but its API is very primitive by todays 
standards. That said, it does work.

Ralph


> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe  wrote:
> 
> Le 26/09/2015 18:42, Gilles a écrit :
>> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
>>> On 9/26/15 4:56 AM, Thomas Neidhart wrote:
 On 09/26/2015 01:11 PM, Gilles wrote:
> On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
>> On 09/26/2015 02:33 AM, Gilles wrote:
>>> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
 On 25 September 2015 at 16:47, Gilles 
 wrote:
 
> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
> 
>> On Fri, Sep 25, 2015 at 5:09 PM, 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".
>>> 
>>> 
>> 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.
>> log4j is not a commons component btw.
> Too bad for me. :-/
> Case resolved, then, by the argument of authority?
 I just pointed out that log4j is not a commons component and did not
 imply anything else.
 
> "Commons" is OK but not another Apache project, by virtue of a
> document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not to
> mention that the "scope" of CM currently goes well beyond "the most
> common practical problems not immediately available in the Java
> programming language")...
> 
> What's the _technical_ rationale for accepting this dependency and
> not accepting that dependency?
> 
>> I have not seen a single

Re: [Math] Utilitzation of SLF4J?

2015-09-26 Thread Luc Maisonobe

Le 26/09/2015 20:59, Ralph Goers a écrit :
> I don’t normally participate in Math but I do feel the need to stick my nose 
> in here.
> 1. You are absolutely correct to determine whether you need logging at all 
> before discussing what to choose.
> 2. If you do decide logging is required:
>   a. Please stay away from java.util.logging. It really would be the best 
> solution for a framework like math except it is extremely difficult to 
> redirect efficiently to some other logging framework. The methods used by 
> SLF4J and Log4j are imperfect to say the least.
>   b. Log4j 1.x has reached eol. It effectively has not been supported for 5 
> years.
>   c. Log4j 2 has an API that can be redirected to another logging framework 
> if desired.
>   d. Commons logging still works but its API is very primitive by todays 
> standards. That said, it does work.

>From what I have seen, if I ever were to choose a logging framework for
any project, I agree log4j 2 is currently the best choice. I was
impressed by slf4j a few years ago, but think now the step further is
log4j 2 (without any accurate reason, just a rough feeling).

best regards,
Luc

> 
> Ralph
> 
> 
>> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe  wrote:
>>
>> Le 26/09/2015 18:42, Gilles a écrit :
>>> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
 On 9/26/15 4:56 AM, Thomas Neidhart wrote:
> On 09/26/2015 01:11 PM, Gilles wrote:
>> On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
>>> On 09/26/2015 02:33 AM, Gilles wrote:
 On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
> On 25 September 2015 at 16:47, Gilles 
> wrote:
>
>> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
>>
>>> On Fri, Sep 25, 2015 at 5:09 PM, 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".


>>> 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.
>>> log4j is not a commons component btw.
>> Too bad for me. :-/
>> Case resolved, then, by the argument of authority?
> I just pointed out that log4j is not a commons component and did not
> imply anything else.
>
>> "Commons" is OK but not

Re: [Math] Utilitzation of SLF4J?

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 
>> 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: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Utilitzation of SLF4J?

2015-09-25 Thread Gary Gregory

On Fri, Sep 25, 2015 at 8:50 AM, Phil Steitz  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 
> >> 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: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Utilitzation of SLF4J?

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
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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Utilitzation of SLF4J?

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 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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Utilitzation of SLF4J?

2015-09-25 Thread Thomas Neidhart

On Fri, Sep 25, 2015 at 5:09 PM, 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".
>

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 
 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: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Utilitzation of SLF4J?




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

Re: [Math] Utilitzation of SLF4J?

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,
>>

Re: [Math] Utilitzation of SLF4J?

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 
 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: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
> .
>



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Utilitzation of SLF4J?




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 
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:

Re: [Math] Utilitzation of SLF4J?


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

Re: [Math] Utilitzation of SLF4J?

On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
On Fri, Sep 25, 2015 at 5:09 PM, 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,

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.]

(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
wrote:

Hello,

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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Utilitzation of SLF4J?

2015-09-25 Thread Bernd Eckenfels

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 :

> 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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Utilitzation of SLF4J?

2015-09-25 Thread 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  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

Re: [Math] Utilitzation of SLF4J?


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 :


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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Utilitzation of SLF4J?


On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
On 25 September 2015 at 16:47, Gilles  
wrote:



On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:

On Fri, Sep 25, 2015 at 5:09 PM, 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".


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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[Math] Utilitzation of SLF4J?


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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Utilitzation of SLF4J?

2015-09-25 Thread 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  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: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Utilitzation of SLF4J?

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
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

(And probably should use) OSGi to isolate dependencies.

WDYT?

Cheers,
- Ole

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Utilitzation of SLF4J?