RE: Comments on the commons-logging API

[Andrew C. Oliver]

Not to mention the problems of supporting multiple versions of Log4j. 
But I really think this discussion belongs in the commons-dev mail
list.  Ceki is making criticisms against an API etc, that really should
be taken up in the appropriate forum.

On Thu, 2002-03-28 at 20:13, Scott Sanders wrote:
> > -Original Message-
> > From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] 
> > I never suspected (nor suggested) that commons-logging effort 
> > was dishonorable in any way. My contention is that it will 
> > make life harder not easier. Nothing more, nothing less.
> > 
> 
> I think it may make life harder for the commons, Log4J, and LogKit teams, but I have 
>already seen it make life easier for users of jakarta products.  Digester used to 
>have its own configuration mechanism, and it used to System.out.println() all 
>*logging* information.  Try using that in a server framework and see how fast you get 
>angry when everything else uses Log4J.  
> 
> OK, so if Digester uses Log4J, now see how fast all the LogKit zealots will refuse 
>to use it.  Commons-logging was a way to plug into logging frameworks without 
>dictating any of them.  The main point IMHO was to remove System.out.println() calls. 
> It happened to end up usefully wrapping all logging impls IMHO.  That is a win for 
>everyone.
> 
> If we have problems with interoperability (and we will), we fix them.  Yes, someone 
>has to ultimately dictate the logger to use.  As a commons developer, I do not want 
>to force that choice onto anyone.  Let them decide.
> 
> Scott Sanders
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com
http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound
Document 
format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Comments on the commons-logging API

[Ceki Gülcü]

At 15:36 29.03.2002 +, Danny Angus wrote:

> > Now that you can (well, soon) legally implement JSR47's, you
> > might was well
> > support their interfaces and semantics, and then 'embrace and
> > extend'.  Just
> > do the JSR47 stuff better :)
>
>Could Log4J now become an RI of JSR47 ? (I'm still not completely clear
>about all this..)

No, it cannot. JSR47 is not an some network protocol or an abstract
description of an interface, coding rules etc. It is a nuts and bolts
implementation.

Jason Hunter also mentioned some rule about being part of the
JDK 1.4 umbrella JSR which apparently changes things. (Don't
ask me why.)


--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Vladimir Bossicard]

> Wait a minute, I know you... You are the apricot
> (http://sourceforge.net/projects/apricot/) guy. In the fairy tale "The
> Emperor's new clothes," what was the name of the child who calls
> 
> "He's naked. The man in the crown is naked"
> 
> Was it Vladimir Bossicard?


I'm pretty sure I was not in that tale.  And no, I'm not from Russia. :-)

But you're right, I'm the "Apricot guy".  I'm currently looking at 
avalon, commons-loggin and myrmidon to see how they can fit in Apricot 
(or how I can modify Apricot to take advantage of them).

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Geir Magnusson Jr.]

On 3/29/02 11:05 AM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> On Sat, 30 Mar 2002 02:48, Geir Magnusson Jr. wrote:
>> On 3/29/02 10:40 AM, "Peter Donald" <[EMAIL PROTECTED]> wrote:
>>> On Sat, 30 Mar 2002 02:36, Danny Angus wrote:
> Now that you can (well, soon) legally implement JSR47's, you
> might was well
> support their interfaces and semantics, and then 'embrace and
> extend'.  Just
> do the JSR47 stuff better :)
 
 Could Log4J now become an RI of JSR47 ? (I'm still not completely clear
 about all this..)
>>> 
>>> Not really and nor could you "embrace and extend". Soon we will be
>>> allowed access to the TCKs (fingers crossed) which means we can implment
>>> the spec legally. However there has not been any change to any of the
>>> licenses regarding the specification materials which means it is still a
>>> violation of the license if you were to try and "corrupt" a spec or
>>> "embrace and extend" a spec by poorly-implementing it (and failing the
>>> TCK). However now we can at least implement the spec(s).
>> 
>> I can't believe that's true.
>> 
>> I can't see how they can prevent you from extending.  I mean, every J2EE
>> implementation 'embraces and extends' the J2EE spec because the specs leave
>> out a lot.  For example, you can't make a really useful JMS broker until
>> you add proprietary extensions for clustering, load balancing, etc...
>> Anyone that includes any functioning taglibs with a servlet container / jsp
>> implementation is extending the spec as there are no useful tags in the
>> spec.
>> 
>> I can't see how anyone can complain if you pass the TCK.
> 
> Passing the TCK - thats the trick. Given that most (all?) TCKs require that
> the public interface conform exactly to that which is specified and that
> JSR47 is not made up of interfaces but instead made up of classes it would be
> difficult to pass the TCK if you added anything to it.

Of course you would want to implement the API exactly

> You could create new
> output targets/appenders/whatever but they could not be in the java.**
> namespace. 

True.  But you would still be able to offer a better implementation, and
offer extensions if you desired.
 
> JSR47 should not be considered in the same category as the servlet/JMS/ejb
> specs - more in the same category as the Collection API.

That's true but irrelevant - if the JSR47 leaves out features that people
deem necessary, there is no reason why those can't be added as a 'vendor
extension', unless the JSR is so broken you can't extend it w/o violating
the API. (Like hardcoding the possible output targets choices as methods
into the API...)

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting

The cost of synchronization is much less that the cost of stupidity.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Peter Donald]

On Sat, 30 Mar 2002 02:48, Geir Magnusson Jr. wrote:
> On 3/29/02 10:40 AM, "Peter Donald" <[EMAIL PROTECTED]> wrote:
> > On Sat, 30 Mar 2002 02:36, Danny Angus wrote:
> >>> Now that you can (well, soon) legally implement JSR47's, you
> >>> might was well
> >>> support their interfaces and semantics, and then 'embrace and
> >>> extend'.  Just
> >>> do the JSR47 stuff better :)
> >>
> >> Could Log4J now become an RI of JSR47 ? (I'm still not completely clear
> >> about all this..)
> >
> > Not really and nor could you "embrace and extend". Soon we will be
> > allowed access to the TCKs (fingers crossed) which means we can implment
> > the spec legally. However there has not been any change to any of the
> > licenses regarding the specification materials which means it is still a
> > violation of the license if you were to try and "corrupt" a spec or
> > "embrace and extend" a spec by poorly-implementing it (and failing the
> > TCK). However now we can at least implement the spec(s).
>
> I can't believe that's true.
>
> I can't see how they can prevent you from extending.  I mean, every J2EE
> implementation 'embraces and extends' the J2EE spec because the specs leave
> out a lot.  For example, you can't make a really useful JMS broker until
> you add proprietary extensions for clustering, load balancing, etc... 
> Anyone that includes any functioning taglibs with a servlet container / jsp
> implementation is extending the spec as there are no useful tags in the
> spec.
>
> I can't see how anyone can complain if you pass the TCK.

Passing the TCK - thats the trick. Given that most (all?) TCKs require that 
the public interface conform exactly to that which is specified and that 
JSR47 is not made up of interfaces but instead made up of classes it would be 
difficult to pass the TCK if you added anything to it. You could create new 
output targets/appenders/whatever but they could not be in the java.** 
namespace. 

JSR47 should not be considered in the same category as the servlet/JMS/ejb 
specs - more in the same category as the Collection API.

-- 
Cheers,

Pete

*-*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof."   *
*  - John Kenneth Galbraith   *
*-*

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Geir Magnusson Jr.]

On 3/29/02 10:40 AM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> On Sat, 30 Mar 2002 02:36, Danny Angus wrote:
>>> Now that you can (well, soon) legally implement JSR47's, you
>>> might was well
>>> support their interfaces and semantics, and then 'embrace and
>>> extend'.  Just
>>> do the JSR47 stuff better :)
>> 
>> Could Log4J now become an RI of JSR47 ? (I'm still not completely clear
>> about all this..)
> 
> Not really and nor could you "embrace and extend". Soon we will be allowed
> access to the TCKs (fingers crossed) which means we can implment the spec
> legally. However there has not been any change to any of the licenses
> regarding the specification materials which means it is still a violation of
> the license if you were to try and "corrupt" a spec or "embrace and extend" a
> spec by poorly-implementing it (and failing the TCK). However now we can at
> least implement the spec(s).

I can't believe that's true.

I can't see how they can prevent you from extending.  I mean, every J2EE
implementation 'embraces and extends' the J2EE spec because the specs leave
out a lot.  For example, you can't make a really useful JMS broker until you
add proprietary extensions for clustering, load balancing, etc...  Anyone
that includes any functioning taglibs with a servlet container / jsp
implementation is extending the spec as there are no useful tags in the
spec.

I can't see how anyone can complain if you pass the TCK.

geir

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Be a giant.  Take giant steps.  Do giant things...


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Geir Magnusson Jr.]

On 3/29/02 10:36 AM, "Danny Angus" <[EMAIL PROTECTED]> wrote:

> 
>> Now that you can (well, soon) legally implement JSR47's, you
>> might was well
>> support their interfaces and semantics, and then 'embrace and
>> extend'.  Just
>> do the JSR47 stuff better :)
> 
> Could Log4J now become an RI of JSR47 ? (I'm still not completely clear
> about all this..)

Ceki is the guy to really talk to this but as I understand the process, it
always *could* have.  For example, the JSTL RI is Apache licensed OSS that
is being done in the Jakarta Taglibs project.  (Of course, they have have
the sticky situation that until the spec license is changed, they
technically can't distribute it but that is being solved with the recent JCP
changes.)

However, given the 'differences' between the spec lead and Ceki, I can't
imagine this ever happening, nor could I imagine log4j's package structure
getting changed to java.*, which it would have to be as 47 is part of
JDK1.4...

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting

Age and treachery will always triumph over youth and talent


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Peter Donald]

On Sat, 30 Mar 2002 02:36, Danny Angus wrote:
> > Now that you can (well, soon) legally implement JSR47's, you
> > might was well
> > support their interfaces and semantics, and then 'embrace and
> > extend'.  Just
> > do the JSR47 stuff better :)
>
> Could Log4J now become an RI of JSR47 ? (I'm still not completely clear
> about all this..)

Not really and nor could you "embrace and extend". Soon we will be allowed 
access to the TCKs (fingers crossed) which means we can implment the spec 
legally. However there has not been any change to any of the licenses 
regarding the specification materials which means it is still a violation of 
the license if you were to try and "corrupt" a spec or "embrace and extend" a 
spec by poorly-implementing it (and failing the TCK). However now we can at 
least implement the spec(s).

-- 
Cheers,

Pete

-
 We shall not cease from exploration, and the 
  end of all our exploring will be to arrive 
 where we started and know the place for the 
first time -- T.S. Eliot
-

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Comments on the commons-logging API

[Danny Angus]

> Now that you can (well, soon) legally implement JSR47's, you
> might was well
> support their interfaces and semantics, and then 'embrace and
> extend'.  Just
> do the JSR47 stuff better :)

Could Log4J now become an RI of JSR47 ? (I'm still not completely clear
about all this..)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Geir Magnusson Jr.]

On 3/28/02 5:14 PM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:

> 
> Possible but I would not be that sure.  We will have very strong new
> features in log4j 1.3 (the release after 1.2) which will leave JDK 1.4
> logging even further behind.  Just as importantly, log4j documentation
> is going to get a massive boost with the upcoming log4j book.
> 
> Sun's me-too strategy is bound to fail. The question is whether the
> bigger jakarta community is going to help us defeat JSR47 or stand in
> the way.

Got your back...

:)

One way to 'defeat' it is being able to innovate faster and support user
requirements rapidly as change in the J2xE specs seem to be rather slow
moving.  For example, you won't be able to iterate in JSP in a
spec-compliant way until 2005 or something... Think about that - that's
something like 6 years after you could do it in WebMacro, on which Velocity
was modeled.  Anyway...


Now that you can (well, soon) legally implement JSR47's, you might was well
support their interfaces and semantics, and then 'embrace and extend'.  Just
do the JSR47 stuff better :)

geir

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"We will be judged not by the monuments we build, but by the monuments we
destroy" - Ada Louise Huxtable


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Ceki Gülcü]

At 18:28 28.03.2002 -0800, you wrote:
>>god no. The avalon group was already using a facade logger long before 
>>commons was for much the same reason commons adopted one.
>
>
>Is Avalon still using its own facade logger or changed to commons-logging?
>
>I'm just wondering: How many Jakarta projects use this common-logging 
>package?  What's the advantage of having a common logging package if it's 
>not widely used even within the Jakarta community?
>
>One solution: all Jakarta projects must support both LogKit and Log4J (as 
>they are both part of the family) by using commons-logging if they want to 
>(but as logging is not the core business of many Jakarta projects, using 
>the common-logging package makes sense).
>
>Another solution : drop one logger (don't shoot me!) and stand beside the 
>winner.  Users willing to use Jakarta projects will *have* to use the 
>Jakarta logger.  Sound M$-ish, doesn't it?
>
>Last solution : everyone stands where they are: pro-choice vs. pro-one-logger.

Your allusion to Microsoft is interesting as much as it is troubling. For 
some reason
everybody here takes the development of good software for granted. It takes 
a lot of
energy and time. We waste much of it bickering among ourselves. Initially I was
very saddened by this but now have grown accustomed to it. I do not expect
to change anyones's mind. I am pretty sick of the politics and have much work
to do.


--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Ceki Gülcü]

Good point, except that the loop length was 100'000'000 so the cost of the
first 10'000 calls would be dwarfed by the remaining 99'990'000. Of course
there is also:

~/>java Indirect 1
log4j: Parsing threshold string [WARN]
log4j: Could not find root logger information. Is this OK?
log4j: Finished configuring.
Total: 0.0 in microseconds.
Average time: 0.0 in microseconds.

Point well taken nonetheless.

At 22:01 29.03.2002 +1100, you wrote:
>Try changing your code to loop 10,000 times or so before you start the real
>test. This will make sure the JVMs are warmed up and all systems are
>configured properly. That should drop the difference even more in theory.

--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Peter Donald]

Try changing your code to loop 10,000 times or so before you start the real 
test. This will make sure the JVMs are warmed up and all systems are 
configured properly. That should drop the difference even more in theory.

On Fri, 29 Mar 2002 21:48, Ceki Gülcü wrote:
> The interesting case is of course measuring performance when logging is
> turned off. Here is a little experiment.
>
> My CLASSPATH:
>
> CLASSPATH=.;/java/jdk1.3.1/jre/lib/rt.jar;/home/cgu/ASF/jakarta-log4j-1.2be
>ta4/dist/lib/log4j-1.2beta4.jar;commons-logging-1.0/commons-logging.jar
>
>
> I have written two short programs that log in a loop. One called
> Direct.java log that directly uses log4j. The other, called Indirect.java,
> logs indirectly using commons-logging.
>
> -
> import org.apache.log4j.Logger;
> import org.apache.log4j.Level;
>
> public class Direct {
>
>public static void main(String args[]) {
>
>  if(args.length != 1) {
>System.err.println("Usage: java Direct runLength\n" +
>"  where runLength is an int representing the run length of
> loops\n"+ "I suggest a runLength of at least 100'000.");
>  }
>
>  int runLength = Integer.parseInt(args[0]);
>
>  Logger logger = Logger.getLogger("bandicoot");
>
>  // disable all logging below INFO.
>  logger.getLoggerRepository().setThreshold(Level.INFO);
>
>  long begin = System.currentTimeMillis();
>  for(int i = 0; i < runLength; i++) {
>if(logger.isDebugEnabled()) {
>  logger.debug("This is message "+ i);
>}
>  }
>
>  long end = System.currentTimeMillis();
>  double totalMicros = (end-begin)*1000.0;
>  System.out.println("Average time: "+totalMicros/runLength+" in
> microseconds.");
>}
> }
> ---
>
> Here is Indirect.java
>
> ---
> import org.apache.commons.logging.LogFactory;
> import org.apache.commons.logging.Log;
>
> public class Indirect {
>
>public static void main(String args[]) {
>
>  if(args.length != 1) {
>System.err.println("Usage: java Indirect runLength\n" +
>"  where runLength is an int representing the run length of
> loops\n"+ "I suggest a runLength of at least 100'000.");
>  }
>
>  int runLength = Integer.parseInt(args[0]);
>
>  Log log = LogFactory.getFactory().getInstance("bandicoot");
>
>  // notice that in this example there is no code to set the level
>  // of the repository.
>
>  long begin = System.currentTimeMillis();
>  for(int i = 0; i < runLength; i++) {
>if(log.isDebugEnabled()) {
>  log.debug("This is message "+ i);
>}
>  }
>
>  long end = System.currentTimeMillis();
>  double totalMicros = (end-begin)*1000.0;
>  System.out.println("Average time: "+totalMicros/runLength+" in
> microseconds.");
>}
> }
> ---
>
> Running Direct I get:
>
> ~/> java Direct 1
> Average time: 0.01903 in microseconds.
>
> Running Indirect I get:
>
> ~/> java Indirect 1
> log4j:WARN No appenders could be found for logger (bandicoot).
> log4j:WARN Please initialize the log4j system properly.
> Average time: 1.15155 in microseconds.
>
> That's a factor of 60 and not in percents!
>
> Of course, I cheated because Indirect.java does not configure
> the repository threshold.
>
> Placing a file called "log4j.properties" with the following contents
>
>log4j.threshold=WARN
>log4j.debug=true
>
> in the *current* directory (remember I have '.' as the first entry in
> my CLASSPATH) and running Indirect java I get:
>
> ~/>  java Indirect 1
> log4j: Parsing threshold string [WARN]
> log4j: Could not find root logger information. Is this OK?
> log4j: Finished configuring.
> Average time: 0.02854 in microseconds.
>
> That's an increase of 50, but in percents this time. Interestingly,
> enough the results are very similar in JDK 1.2.2; the numbers change
> but the proportions don't.
>
> Moral of the story? You are essentially right if the user knows what
> she is doing.
>
> It would be interesting to see if changing
>
>   private Category category = null;
>
> to
>
>   final private Category category;
>
> in org.apache.commons.logging.impl.Log4JCategoryLog would
> change anything. It would be a nice experiment.
>
> At 12:46 29.03.2002 +1100, you wrote:
> >On Fri, 29 Mar 2002 12:38, Ceki Gülcü wrote:
> > > 1) logging calls are made thousands of times so the indirection through
> > > an equalizer API (like commons-logging) has a performance impact
> >
> >Not in modern JVMs (read most almost all jdk1.3 impls).
> >
> >As long as the underlying indirection (ie between commons and Log4j) is
> > done via a final variable then the cost is zero due to JVM optimizations.
> > Theres still the cost of the dynamic dispatch between user land code and
> > commons

Re: Comments on the commons-logging API

[Ceki Gülcü]

The interesting case is of course measuring performance when logging is
turned off. Here is a little experiment.

My CLASSPATH:

CLASSPATH=.;/java/jdk1.3.1/jre/lib/rt.jar;/home/cgu/ASF/jakarta-log4j-1.2beta4/dist/lib/log4j-1.2beta4.jar;commons-logging-1.0/commons-logging.jar


I have written two short programs that log in a loop. One called
Direct.java log that directly uses log4j. The other, called Indirect.java,
logs indirectly using commons-logging.

-
import org.apache.log4j.Logger;
import org.apache.log4j.Level;

public class Direct {

   public static void main(String args[]) {

 if(args.length != 1) {
   System.err.println("Usage: java Direct runLength\n" +
   "  where runLength is an int representing the run length of loops\n"+
   "I suggest a runLength of at least 100'000.");
 }

 int runLength = Integer.parseInt(args[0]);

 Logger logger = Logger.getLogger("bandicoot");

 // disable all logging below INFO.
 logger.getLoggerRepository().setThreshold(Level.INFO);

 long begin = System.currentTimeMillis();
 for(int i = 0; i < runLength; i++) {
   if(logger.isDebugEnabled()) {
 logger.debug("This is message "+ i);
   }
 }

 long end = System.currentTimeMillis();
 double totalMicros = (end-begin)*1000.0;
 System.out.println("Average time: "+totalMicros/runLength+" in 
microseconds.");
   }
}
---

Here is Indirect.java

---
import org.apache.commons.logging.LogFactory;
import org.apache.commons.logging.Log;

public class Indirect {

   public static void main(String args[]) {

 if(args.length != 1) {
   System.err.println("Usage: java Indirect runLength\n" +
   "  where runLength is an int representing the run length of loops\n"+
   "I suggest a runLength of at least 100'000.");
 }

 int runLength = Integer.parseInt(args[0]);

 Log log = LogFactory.getFactory().getInstance("bandicoot");

 // notice that in this example there is no code to set the level
 // of the repository.

 long begin = System.currentTimeMillis();
 for(int i = 0; i < runLength; i++) {
   if(log.isDebugEnabled()) {
 log.debug("This is message "+ i);
   }
 }

 long end = System.currentTimeMillis();
 double totalMicros = (end-begin)*1000.0;
 System.out.println("Average time: "+totalMicros/runLength+" in 
microseconds.");
   }
}
---

Running Direct I get:

~/> java Direct 1
Average time: 0.01903 in microseconds.

Running Indirect I get:

~/> java Indirect 1
log4j:WARN No appenders could be found for logger (bandicoot).
log4j:WARN Please initialize the log4j system properly.
Average time: 1.15155 in microseconds.

That's a factor of 60 and not in percents!

Of course, I cheated because Indirect.java does not configure
the repository threshold.

Placing a file called "log4j.properties" with the following contents

   log4j.threshold=WARN
   log4j.debug=true

in the *current* directory (remember I have '.' as the first entry in
my CLASSPATH) and running Indirect java I get:

~/>  java Indirect 1
log4j: Parsing threshold string [WARN]
log4j: Could not find root logger information. Is this OK?
log4j: Finished configuring.
Average time: 0.02854 in microseconds.

That's an increase of 50, but in percents this time. Interestingly,
enough the results are very similar in JDK 1.2.2; the numbers change
but the proportions don't.

Moral of the story? You are essentially right if the user knows what
she is doing.

It would be interesting to see if changing

  private Category category = null;

to

  final private Category category;

in org.apache.commons.logging.impl.Log4JCategoryLog would
change anything. It would be a nice experiment.

At 12:46 29.03.2002 +1100, you wrote:
>On Fri, 29 Mar 2002 12:38, Ceki Gülcü wrote:
> > 1) logging calls are made thousands of times so the indirection through
> > an equalizer API (like commons-logging) has a performance impact
>
>Not in modern JVMs (read most almost all jdk1.3 impls).
>
>As long as the underlying indirection (ie between commons and Log4j) is done
>via a final variable then the cost is zero due to JVM optimizations. Theres
>still the cost of the dynamic dispatch between user land code and commons
>code but that cost is very very minimal compared to the rest of the logging
>operations.
>
>The cost comes in constructing the string objects (which is literally
>thousands times more expensive than a dynamic dispatch) and routing the log
>message.
>
>As long as the API supports functions like isDebugEnabled() (which I believe
>commons does? or at least did) then the performance cost is so negligable to
>be unimportant.

In one word? Yes.


--
Ceki
My link of the month: http://java.sun.com/aboutJava/st

RE: Comments on the commons-logging API

[Danny Angus]

+1 We have to be Pro Choice. For better or worse its part of the way things are done. 
If there is to be one logging API it will emerge with least pain through natural 
wasteage.
Abbot of Citeaux, leading the 13th Century crusade against the Albigensians thundered: 
“Kill them all, God will know his own”

> > Last solution : everyone stands where they are: pro-choice vs.
> > pro-one-logger.
> 
> thats the only way forward.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Ceki Gülcü]

Wait a minute, I know you... You are the apricot
(http://sourceforge.net/projects/apricot/) guy. In the fairy tale "The
Emperor's new clothes," what was the name of the child who calls

 "He's naked. The man in the crown is naked"

Was it Vladimir Bossicard?


At 18:28 28.03.2002 -0800, you wrote:
>>god no. The avalon group was already using a facade logger long before 
>>commons was for much the same reason commons adopted one.
>
>
>Is Avalon still using its own facade logger or changed to commons-logging?
>
>I'm just wondering: How many Jakarta projects use this common-logging 
>package?  What's the advantage of having a common logging package if it's 
>not widely used even within the Jakarta community?
>
>One solution: all Jakarta projects must support both LogKit and Log4J (as 
>they are both part of the family) by using commons-logging if they want to 
>(but as logging is not the core business of many Jakarta projects, using 
>the common-logging package makes sense).
>
>Another solution : drop one logger (don't shoot me!) and stand beside the 
>winner.  Users willing to use Jakarta projects will *have* to use the 
>Jakarta logger.  Sound M$-ish, doesn't it?
>
>Last solution : everyone stands where they are: pro-choice vs. pro-one-logger.
>
>-Vladimir
>
>--
>Vladimir Bossicard
>www.bossicard.com

--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Peter Donald]

On Fri, 29 Mar 2002 13:28, Vladimir Bossicard wrote:
> > god no. The avalon group was already using a facade logger long before
> > commons was for much the same reason commons adopted one.
>
> Is Avalon still using its own facade logger or changed to commons-logging?

its own. The commons logger does not support our use case.

> I'm just wondering: How many Jakarta projects use this common-logging
> package?  What's the advantage of having a common logging package if
> it's not widely used even within the Jakarta community?

good question. It is used by struts and will soon be adopted by turbine I 
suspect and those two groups give the package wide-enough usage. 

> Another solution : drop one logger (don't shoot me!) and stand beside
> the winner.  Users willing to use Jakarta projects will *have* to use
> the Jakarta logger.  Sound M$-ish, doesn't it?

Some people would like that ;)

> Last solution : everyone stands where they are: pro-choice vs.
> pro-one-logger.

thats the only way forward.

-- 
Cheers,

Pete

"There's a frood who really knows where his towel is."

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[costinm]

On Fri, 29 Mar 2002, Ceki Gülcü wrote:

> The problem with logging is different because:
> 
> 1) logging calls are made thousands of times so the indirection through
> an equalizer API (like commons-logging) has a performance impact

Only for the logger that do not implement the interface :-) If LogKit will 
implement commons-logging directly - the impact will be 0. Same for log4j, 
just add an implement. 

In addition any decent JIT will get rid of the extra indirection - you may 
notice a lot of wrappers are final.

> 2) logging requires a configuration step. Currently this crucial step is
> ignored in commons-logging.

getAttribute/setAttribute allows same kind of configuration as SAX.
No attribute is defined or standardised - in time we'll see what patterns
emerge.

Again - we want an API for logging, not configuration. There are 
some good APIs for configuration, no need to invent another one, and 
the configuration can/should be integrated in the 'main' application,
not in components.

> 3) In container based environments, it is important for the user to control
> logging by carefully placing the log4j.jar file and its configuration file. By
> introducing an extra indirection step (commons-logging detection mechanism)
> this is  made hopelessly complex.

It's as complex as it was before - if you place commons-logging and log4j
in the same place. 

However since commons-logging will be used in tomcat at a low level, and
is likely to be in the common class loader - it will probably create 
some complications, especially in sandbox mode. 

But we are here to solve the problems and make things simpler :-)


> 4) In future versions of Application Servers, it will be the job of the 
> application
> server to *impose* the (log4j) hierarchy and the specific Logger 
> implementation.
> This simply can not be achieved with commons-logging.

Wrong :-)

I think this has been discussed at length before releasing 
commons-logging, and use in an application server was one of the 
driving factors in designing the API.


> The point is that logging in some respects is more complex than XML parsing.

Just read the schema spec :-)


> By the way, I am just curious, how many vendors (outside xml.apache.org)
> implement JAXP? This has no direct bearing to the discussion.

There are not so many parsers/xslt translators in wide use, it seems 
crimson/xerces/xalan/saxon have most of the users. I don't know any 
vendor of a parser/xslt that doesn't implement jaxp, and I don't 
know too many applications having xerces or crimson deps hardcoded in
the code.

BTW, JAXP is probably a wrong example - take SAX for example. 

Costin





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Vladimir Bossicard]

> god no. The avalon group was already using a facade logger long before 
> commons was for much the same reason commons adopted one.


Is Avalon still using its own facade logger or changed to commons-logging?

I'm just wondering: How many Jakarta projects use this common-logging 
package?  What's the advantage of having a common logging package if 
it's not widely used even within the Jakarta community?

One solution: all Jakarta projects must support both LogKit and Log4J 
(as they are both part of the family) by using commons-logging if they 
want to (but as logging is not the core business of many Jakarta 
projects, using the common-logging package makes sense).

Another solution : drop one logger (don't shoot me!) and stand beside 
the winner.  Users willing to use Jakarta projects will *have* to use 
the Jakarta logger.  Sound M$-ish, doesn't it?

Last solution : everyone stands where they are: pro-choice vs. 
pro-one-logger.

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Peter Donald]

On Fri, 29 Mar 2002 12:38, Ceki Gülcü wrote:
> 1) logging calls are made thousands of times so the indirection through
> an equalizer API (like commons-logging) has a performance impact

Not in modern JVMs (read most almost all jdk1.3 impls). 

As long as the underlying indirection (ie between commons and Log4j) is done 
via a final variable then the cost is zero due to JVM optimizations. Theres 
still the cost of the dynamic dispatch between user land code and commons 
code but that cost is very very minimal compared to the rest of the logging 
operations.

The cost comes in constructing the string objects (which is literally 
thousands times more expensive than a dynamic dispatch) and routing the log 
message. 

As long as the API supports functions like isDebugEnabled() (which I believe 
commons does? or at least did) then the performance cost is so negligable to 
be unimportant.

-- 
Cheers,

Pete

---
If your life passes before your eyes when you die, 
 does that include the part where your life passes before 
your eyes?
---

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Ceki Gülcü]

At 16:56 28.03.2002 -0800, you wrote:
>On Fri, 29 Mar 2002, Ceki Gülcü wrote:
>
> > I think you have done a pretty good job on the log4j wrapper. However,
> > I am pretty stretched out as it is, so I can't really help with something
> > I don't particularly like. Besides, if people find commons-logging really
> > useful
> > they will build a community around it. What I say or think won't matter.
>
>First, I'm not the author of log4j wrapper - it's Scott Sanders, Rod, etc.
>( to give credits to who deserve :-)

OK, I had meant the whole bunch not just you. :-)

>And what you say, think and do does matter.
>
>In particular maintaining and helping with the log4j wrapper, and making
>sure commons-logging works best with log4j will help all users of
>log4j that also use components that log with commons-logging.
>
>It may also get more people and components to use commons-logging
>API instead of logger-specific APIs - and that may mean they'll be able to
>choose the logger impl based on quality.

The source of our argument seems to be that JAXP is the model to follow.
Although there are similarities between the selection of an XML parser and
a logging library, the problem with logging is far more complicated.
With an XML parser, you get a parser, parse the document and it is over.
The problem with logging is different because:

1) logging calls are made thousands of times so the indirection through
an equalizer API (like commons-logging) has a performance impact

2) logging requires a configuration step. Currently this crucial step is
ignored in commons-logging.

3) In container based environments, it is important for the user to control
logging by carefully placing the log4j.jar file and its configuration file. By
introducing an extra indirection step (commons-logging detection mechanism)
this is  made hopelessly complex.

4) In future versions of Application Servers, it will be the job of the 
application
server to *impose* the (log4j) hierarchy and the specific Logger 
implementation.
This simply can not be achieved with commons-logging.

The point is that logging in some respects is more complex than XML parsing.

By the way, I am just curious, how many vendors (outside xml.apache.org)
implement JAXP? This has no direct bearing to the discussion.

Regards, Ceki





--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Peter Donald]

On Fri, 29 Mar 2002 12:13, Scott Sanders wrote:
> > -Original Message-
> > From: Ceki Glc [mailto:[EMAIL PROTECTED]]
> > I never suspected (nor suggested) that commons-logging effort
> > was dishonorable in any way. My contention is that it will
> > make life harder not easier. Nothing more, nothing less.
>
> I think it may make life harder for the commons, Log4J, and LogKit teams,

god no. The avalon group was already using a facade logger long before 
commons was for much the same reason commons adopted one. It also makes it 
much easier to have a "slim" logging system that just prints out to standard 
out or whatever when thats all you need.

> If we have problems with interoperability (and we will), we fix them.  Yes,
> someone has to ultimately dictate the logger to use.  As a commons
> developer, I do not want to force that choice onto anyone.  Let them
> decide.

Well I have got a bug report recently wrt LogKit integration. Apparently you 
removed support for it recently in a reorg or it is no longer detected or 
something (not sure I didn't really understand) which annoyed a couple of 
people. Dunno if this is still relevent though ;)

-- 
Cheers,

Pete

 "There is only one good - knowledge; and one evil - ignorance."
 Socrates

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Comments on the commons-logging API

[Scott Sanders]

> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] 
> I never suspected (nor suggested) that commons-logging effort 
> was dishonorable in any way. My contention is that it will 
> make life harder not easier. Nothing more, nothing less.
> 

I think it may make life harder for the commons, Log4J, and LogKit teams, but I have 
already seen it make life easier for users of jakarta products.  Digester used to have 
its own configuration mechanism, and it used to System.out.println() all *logging* 
information.  Try using that in a server framework and see how fast you get angry when 
everything else uses Log4J.  

OK, so if Digester uses Log4J, now see how fast all the LogKit zealots will refuse to 
use it.  Commons-logging was a way to plug into logging frameworks without dictating 
any of them.  The main point IMHO was to remove System.out.println() calls.  It 
happened to end up usefully wrapping all logging impls IMHO.  That is a win for 
everyone.

If we have problems with interoperability (and we will), we fix them.  Yes, someone 
has to ultimately dictate the logger to use.  As a commons developer, I do not want to 
force that choice onto anyone.  Let them decide.

Scott Sanders

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[costinm]

On Fri, 29 Mar 2002, Ceki Gülcü wrote:

> I think you have done a pretty good job on the log4j wrapper. However,
> I am pretty stretched out as it is, so I can't really help with something
> I don't particularly like. Besides, if people find commons-logging really 
> useful
> they will build a community around it. What I say or think won't matter.

First, I'm not the author of log4j wrapper - it's Scott Sanders, Rod, etc.
( to give credits to who deserve :-)

And what you say, think and do does matter. 

In particular maintaining and helping with the log4j wrapper, and making 
sure commons-logging works best with log4j will help all users of 
log4j that also use components that log with commons-logging.

It may also get more people and components to use commons-logging 
API instead of logger-specific APIs - and that may mean they'll be able to 
choose the logger impl based on quality.

Costin






> 
> At 15:17 28.03.2002 -0800, you wrote:
> >On Thu, 28 Mar 2002, Ceki Gülcü wrote:
> >
> > > True. It does encourage it, but only initially. On the long run,
> > > however, people will run into problems with their logging (as is
> > > happening now). They will say this commons-logging+log4j stuff is too
> > > complicated, we'll switch to JDK 1.4 logging, at least that does not
> >
> >And you are the only one who can make commons-logging + log4j to be
> >the best solution on the long run.
> >
> >By implementing and maintaining the log4j implementation of
> >commons-logging.
> >
> >The API is a subset of log4j, and if you really want to help the users
> >all you have to do is take ownership of a log4j implementation of
> >commons-logging.
> >
> >It doesn't even have to be included in commons-logging, it is
> >better if each log4j impl. had it's own implementation of the wrapper,
> >possibly taking advantage of new features, etc.
> >
> >Costin
> 
> --
> Ceki
> My link of the month: http://java.sun.com/aboutJava/standardization/
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Comments on the commons-logging API

[Ceki Gülcü]

At 00:57 29.03.2002 +0100, Paulo Gaspar wrote:
>Ceki,
>
>What about making clear that commons-logging is only supposed to be
>used by other components so that the application developer picks
>the logging API that suits him best?

That seems to be the intent of commons-logging. I have pointed out
the problems with that approach.

>Do you really believe that all application developers will use
>Log4J? Or do you want to force them into doing that?

I can't force people to do anything.

>Do you have any doubt that lots of companies will follow the policy
>of using the JDK 1.4 Logging API just "because it is the one that
>comes with Java"?

Yes, I have my doubts. It still takes a human brain to program a
computer. This is not different in Java. This fact is to remain valid for the
foreseeable future.

>Do you really think that the persons imposing such decision will
>care about what is good and what is bad?

Yes. People have brains.

>And then the ones getting the mess will be the developers and the
>commons-logging will help those. And will also help them to use
>the components/libs that use it.

Possibly.

>This sounds like just another of your pro-log4j-anti-anything-else
>campaigns, containing the usual amount of FUD of any blind campaign.

Please avoid making generalizations.

>A "blind campaign" is one where the single motivation of the
>campaigner is defending some interest/belief against all others...
>without really trying to SEE or get precise information on what
>those others really are.

I have a right to speak my mind as much as you do.

>The blindness towards the other alternatives tends to grow a
>considerable amount of misinformation on the blind campaigner and,
>then, he vigorously spreads it - hence the resulting spread of FUD.
>
>You seem to be following a pattern here, since you are doing just
>the same as you usually do against LogKit, including the
>misinformation bit.
>
>Although both you and Peter turn a bit silly when under the
>influence of another-logger-war, I always notice that you know much
>less about LogKit than Peter knows about log4j. (And yes, I know
>both well enough to clearly notice that).

The issue with LogKit is entirely different. The current debate is
perhaps tense  but well within the bounds of mutual respect and
civility. I made my reservations about the commons-logging API
and its developers presented their counter arguments.

>It is sad that you show to be more interested on destroying the
>"competition" than on learning from it. Well, at least you did not
>accuse the commons-logging guys from plagiarism just yet, as you
>did about the LogKit guys.

I never suspected (nor suggested) that commons-logging effort was
dishonorable in any way. My contention is that it will make life harder
not easier. Nothing more, nothing less.

 > -Original Message-----
> > From: Ceki Gulcu [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, March 28, 2002 11:14 PM
> > To: Jakarta General List
> > Subject: Re: Comments on the commons-logging API
> >
> >
> > At 15:30 28.03.2002 -0600, Morgan Delagrange wrote:
> >
> > >I am pro-Log4J.  I wish I lived in that Log4J-only world (until/unless
> > >something better came along).  Generally, commons-logging
> > neither encourages
> > >nor discourages use of Log4J.  However, I would argue that it _does_
> > >encourage Log4J a bit by not forcing a logging implementation war.
> >
> > True. It does encourage it, but only initially. On the long run,
> > however, people will run into problems with their logging (as is
> > happening now). They will say this commons-logging+log4j stuff is too
> > complicated, we'll switch to JDK 1.4 logging, at least that does not
> > have any CLASSPATH problems.
> >
> > >The fact is, JDK 1.4 logging in particular is going to become
> > more and more
> > >common over time, and unless someone can summon forth a magic
> > recantation of
> > >that JSR, then a component-level interface with popular loggers is
> > >necessary.  Otherwise you have to pick, which only services us at the
> > >expense of those who use other logger implementations.
> >
> > Possible but I would not be that sure.  We will have very strong new
> > features in log4j 1.3 (the release after 1.2) which will leave JDK 1.4
> > logging even further behind.  Just as importantly, log4j documentation
> > is going to get a massive boost with the upcoming log4j book.
> >
> > Sun's me-too strategy is bound to fail. The question is whether the
> > bigger jakarta community is going to help us defeat JSR47 or stand in
> > the way.
> >
> > --
> > Ceki
> > My link of the month: http://java.sun.com/aboutJava/standardization/
> >
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Comments on the commons-logging API

[Ceki Gülcü]

Costin,

I think you have done a pretty good job on the log4j wrapper. However,
I am pretty stretched out as it is, so I can't really help with something
I don't particularly like. Besides, if people find commons-logging really 
useful
they will build a community around it. What I say or think won't matter.

At 15:17 28.03.2002 -0800, you wrote:
>On Thu, 28 Mar 2002, Ceki Gülcü wrote:
>
> > True. It does encourage it, but only initially. On the long run,
> > however, people will run into problems with their logging (as is
> > happening now). They will say this commons-logging+log4j stuff is too
> > complicated, we'll switch to JDK 1.4 logging, at least that does not
>
>And you are the only one who can make commons-logging + log4j to be
>the best solution on the long run.
>
>By implementing and maintaining the log4j implementation of
>commons-logging.
>
>The API is a subset of log4j, and if you really want to help the users
>all you have to do is take ownership of a log4j implementation of
>commons-logging.
>
>It doesn't even have to be included in commons-logging, it is
>better if each log4j impl. had it's own implementation of the wrapper,
>possibly taking advantage of new features, etc.
>
>Costin

--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[costinm]

On Fri, 29 Mar 2002, Ceki Gülcü wrote:

> At 16:33 28.03.2002 -0600, you wrote:
> > > Sun's me-too strategy is bound to fail. The question is whether the
> > > bigger jakarta community is going to help us defeat JSR47 or stand in
> > > the way.
> >
> >That's a bit harsh, isn't it?
> 
> Hmm, maybe it is. What I am trying to say is that I would have liked
> to see jakarta present a more united front. Well, too bad...

That's what we are trying to do with commons-logging. A logging API 
that 'unites' the various logging implementations and allow the user to
choose the implementation.


Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Ceki Gülcü]

At 16:33 28.03.2002 -0600, you wrote:
> > Sun's me-too strategy is bound to fail. The question is whether the
> > bigger jakarta community is going to help us defeat JSR47 or stand in
> > the way.
>
>That's a bit harsh, isn't it?

Hmm, maybe it is. What I am trying to say is that I would have liked
to see jakarta present a more united front. Well, too bad...

--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Comments on the commons-logging API

[Paulo Gaspar]

Ceki,


What about making clear that commons-logging is only supposed to be
used by other components so that the application developer picks 
the logging API that suits him best?

Do you really believe that all application developers will use 
Log4J? Or do you want to force them into doing that?

Do you have any doubt that lots of companies will follow the policy 
of using the JDK 1.4 Logging API just "because it is the one that 
comes with Java"? 

Do you really think that the persons imposing such decision will 
care about what is good and what is bad?

And then the ones getting the mess will be the developers and the
commons-logging will help those. And will also help them to use
the components/libs that use it.


This sounds like just another of your pro-log4j-anti-anything-else 
campaigns, containing the usual amount of FUD of any blind campaign.


A "blind campaign" is one where the single motivation of the 
campaigner is defending some interest/belief against all others... 
without really trying to SEE or get precise information on what 
those others really are.

The blindness towards the other alternatives tends to grow a 
considerable amount of misinformation on the blind campaigner and,
then, he vigorously spreads it - hence the resulting spread of FUD.


You seem to be following a pattern here, since you are doing just 
the same as you usually do against LogKit, including the 
misinformation bit.

Although both you and Peter turn a bit silly when under the 
influence of another-logger-war, I always notice that you know much
less about LogKit than Peter knows about log4j. (And yes, I know 
both well enough to clearly notice that).

It is sad that you show to be more interested on destroying the 
"competition" than on learning from it. Well, at least you did not
accuse the commons-logging guys from plagiarism just yet, as you 
did about the LogKit guys.


Ceki, I know you are quite smart, constructive and helpful and I 
respect you for that. But when you get in these logging wars, you
don't seem to be the same person.

You could at least try to be well informed and inform well when you
talk about other logging APIs.


Have fun,
Paulo Gaspar



> -Original Message-
> From: Ceki Gulcu [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 28, 2002 11:14 PM
> To: Jakarta General List
> Subject: Re: Comments on the commons-logging API
> 
> 
> At 15:30 28.03.2002 -0600, Morgan Delagrange wrote:
> 
> >I am pro-Log4J.  I wish I lived in that Log4J-only world (until/unless
> >something better came along).  Generally, commons-logging 
> neither encourages
> >nor discourages use of Log4J.  However, I would argue that it _does_
> >encourage Log4J a bit by not forcing a logging implementation war.
> 
> True. It does encourage it, but only initially. On the long run,
> however, people will run into problems with their logging (as is
> happening now). They will say this commons-logging+log4j stuff is too
> complicated, we'll switch to JDK 1.4 logging, at least that does not
> have any CLASSPATH problems.
> 
> >The fact is, JDK 1.4 logging in particular is going to become 
> more and more
> >common over time, and unless someone can summon forth a magic 
> recantation of
> >that JSR, then a component-level interface with popular loggers is
> >necessary.  Otherwise you have to pick, which only services us at the
> >expense of those who use other logger implementations.
> 
> Possible but I would not be that sure.  We will have very strong new
> features in log4j 1.3 (the release after 1.2) which will leave JDK 1.4
> logging even further behind.  Just as importantly, log4j documentation
> is going to get a massive boost with the upcoming log4j book.
> 
> Sun's me-too strategy is bound to fail. The question is whether the
> bigger jakarta community is going to help us defeat JSR47 or stand in
> the way.
> 
> --
> Ceki
> My link of the month: http://java.sun.com/aboutJava/standardization/
> 
 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Comments on the commons-logging API

[costinm]

On Thu, 28 Mar 2002, Ceki Gülcü wrote:

> True. It does encourage it, but only initially. On the long run,
> however, people will run into problems with their logging (as is
> happening now). They will say this commons-logging+log4j stuff is too
> complicated, we'll switch to JDK 1.4 logging, at least that does not

And you are the only one who can make commons-logging + log4j to be
the best solution on the long run.

By implementing and maintaining the log4j implementation of 
commons-logging.

The API is a subset of log4j, and if you really want to help the users
all you have to do is take ownership of a log4j implementation of 
commons-logging.

It doesn't even have to be included in commons-logging, it is  
better if each log4j impl. had it's own implementation of the wrapper, 
possibly taking advantage of new features, etc.



Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Comments on the commons-logging API

[Paulo Gaspar]

Now your motivation is becoming clear.

Have fun,
Paulo

> -Original Message-
> From: Ceki Gulcu [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 28, 2002 10:18 PM
> To: Jakarta General List
> Subject: Re: Comments on the commons-logging API
> 
> 
> At 15:10 28.03.2002 -0600, Morgan Delagrange wrote:
> >Where is this world where "everyone" uses Log4J?
> 
> That world = (world - jakarta)
> 
> 
> --
> Ceki
> My link of the month: http://java.sun.com/aboutJava/standardization/
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Comments on the commons-logging API

[Morgan Delagrange]

- Original Message -
From: "Ceki Gülcü" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Thursday, March 28, 2002 4:14 PM
Subject: Re: Comments on the commons-logging API


> At 15:30 28.03.2002 -0600, Morgan Delagrange wrote:
>
> >I am pro-Log4J.  I wish I lived in that Log4J-only world (until/unless
> >something better came along).  Generally, commons-logging neither
encourages
> >nor discourages use of Log4J.  However, I would argue that it _does_
> >encourage Log4J a bit by not forcing a logging implementation war.
>
> True. It does encourage it, but only initially. On the long run,
> however, people will run into problems with their logging (as is
> happening now). They will say this commons-logging+log4j stuff is too
> complicated, we'll switch to JDK 1.4 logging, at least that does not
> have any CLASSPATH problems.

I'm not convinced.  These sound like minor, temporary issues, not
showstoppers.  Classpaths do get a little complicated, but it's only one
additional JAR.

> >The fact is, JDK 1.4 logging in particular is going to become more and
more
> >common over time, and unless someone can summon forth a magic recantation
of
> >that JSR, then a component-level interface with popular loggers is
> >necessary.  Otherwise you have to pick, which only services us at the
> >expense of those who use other logger implementations.
>
> Possible but I would not be that sure.  We will have very strong new
> features in log4j 1.3 (the release after 1.2) which will leave JDK 1.4
> logging even further behind.  Just as importantly, log4j documentation
> is going to get a massive boost with the upcoming log4j book.

I hope you're right.  Log4J is a great tool.  Still, you cannot dictate
preference.

> Sun's me-too strategy is bound to fail. The question is whether the
> bigger jakarta community is going to help us defeat JSR47 or stand in
> the way.

That's a bit harsh, isn't it?

- Morgan

> --
> Ceki




_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Comments on the commons-logging API

[Ceki Gülcü]

At 15:30 28.03.2002 -0600, Morgan Delagrange wrote:

>I am pro-Log4J.  I wish I lived in that Log4J-only world (until/unless
>something better came along).  Generally, commons-logging neither encourages
>nor discourages use of Log4J.  However, I would argue that it _does_
>encourage Log4J a bit by not forcing a logging implementation war.

True. It does encourage it, but only initially. On the long run,
however, people will run into problems with their logging (as is
happening now). They will say this commons-logging+log4j stuff is too
complicated, we'll switch to JDK 1.4 logging, at least that does not
have any CLASSPATH problems.

>The fact is, JDK 1.4 logging in particular is going to become more and more
>common over time, and unless someone can summon forth a magic recantation of
>that JSR, then a component-level interface with popular loggers is
>necessary.  Otherwise you have to pick, which only services us at the
>expense of those who use other logger implementations.

Possible but I would not be that sure.  We will have very strong new
features in log4j 1.3 (the release after 1.2) which will leave JDK 1.4
logging even further behind.  Just as importantly, log4j documentation
is going to get a massive boost with the upcoming log4j book.

Sun's me-too strategy is bound to fail. The question is whether the
bigger jakarta community is going to help us defeat JSR47 or stand in
the way.

--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Pier Fumagalli]

"Ceki Gülcü" <[EMAIL PROTECTED]> wrote:
> At 15:10 28.03.2002 -0600, Morgan Delagrange wrote:
>
>> Where is this world where "everyone" uses Log4J?
> 
> That world = (world - jakarta)

I tend to agree with Ceki! :) I never used it until I didn't move on from
Jakarta and went to do some real work for my current employer, and basically
every package we use uses Log4J... Pretty scary, huh? :)

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Morgan Delagrange]

- Original Message -
From: "Ceki Gülcü" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Thursday, March 28, 2002 3:18 PM
Subject: Re: Comments on the commons-logging API


> At 15:10 28.03.2002 -0600, Morgan Delagrange wrote:
> >Where is this world where "everyone" uses Log4J?
>
> That world = (world - jakarta)
>

I am pro-Log4J.  I wish I lived in that Log4J-only world (until/unless
something better came along).  Generally, commons-logging neither encourages
nor discourages use of Log4J.  However, I would argue that it _does_
encourage Log4J a bit by not forcing a logging implementation war.

The fact is, JDK 1.4 logging in particular is going to become more and more
common over time, and unless someone can summon forth a magic recantation of
that JSR, then a component-level interface with popular loggers is
necessary.  Otherwise you have to pick, which only services us at the
expense of those who use other logger implementations.



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Comments on the commons-logging API

[Ceki Gülcü]

At 15:10 28.03.2002 -0600, Morgan Delagrange wrote:
>Where is this world where "everyone" uses Log4J?

That world = (world - jakarta)


--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Morgan Delagrange]

- Original Message -
From: "Jeff Schnitzer" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Thursday, March 28, 2002 2:12 PM
Subject: RE: Comments on the commons-logging API


> > From: Morgan Delagrange [mailto:[EMAIL PROTECTED]]
> >
> > Yes, the defining advantage to the commons-logging API that I see is
that
> > it
> > allows users to adopt a single logging implementation, which confers
real
>
> What needs to be appended to that statement is "...if everyone codes to
> the commons-logging API".

Every component that uses the Commons Logging proxy will play well with
every other component using the proxy, _plus_ all code using a single logger
implementation of your choice.

Saying that everyone must code to the commons-logging API is an
oversimplification.  More accurately, coding to commons-logging facilitates
integration with a single arbitrary logging implementation.  Any environment
that uses a combination of the logging facade and a single logging
implementation will work well.  Any environment that uses more than one
logging implementation will not work as well.

> The exact same statement can be reconstructed
> using "Log4J API" and it is equally true.

If you can guarantee that:

  1) All Jakarta developers will use Log4J in their code,
 eschewing even LogKit, another logging implementation
 under the Jakarta umbrella.

and

  2) All Jakarta _users_ will use Log4J in their code.

then there is no need for a proxy logger.

> If everyone uses commons-logging, then only one logger must be
> configured.  If everyone uses Log4J, then only one logger must be
> configured.

Where is this world where "everyone" uses Log4J?

> If third-party software is using different loggers, then
> you have to configure multiple loggers no matter what API your code
> uses.

Unless that third-party is Jakarta, and that software is utilizing a proxy
logger like commons-logging.  That's the whole point, we can't (and
shouldn't) dictate what implementations others may choose to use.  We can,
however, facilitate integration with their implementation.  Or we can leave
them to the wolves.

> It seems to me that the commons-logging API just adds Yet Another
> Logging API... especially when someone gets the bright idea to make a
> "native" implementation of the API for performance reasons.
>
> At least with Turbine, Struts, (Maverick :-), etc, there are some
> fundamentally different approaches to the problem of how to publish a
> web application.  Logging doesn't seem that complicated.  The massive
> duplication of this basic feature in the Jakarta codebase is silly, and
> trying to build an abstraction layer on top of it seems even sillier.

I'm not sure what "massive duplication" you're referring to, but you seem to
believe that an abstraction layer is unimportant because you think everyone
should use Log4J.  I think the LogKit folks would disagree.  I do too; for
simple logging in a JDK 1.4 environment, using the built-in logger should be
perfectly acceptable.  Because I made that choice, does that mean I should
not get any output from Jakarta components in my log?

- Morgan

> Jeff Schnitzer
> [EMAIL PROTECTED]

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Comments on the commons-logging API

[costinm]

On Thu, 28 Mar 2002, Jeff Schnitzer wrote:

> > From: Morgan Delagrange [mailto:[EMAIL PROTECTED]]
> > 
> > Yes, the defining advantage to the commons-logging API that I see is
> that
> > it
> > allows users to adopt a single logging implementation, which confers
> real
> 
> What needs to be appended to that statement is "...if everyone codes to
> the commons-logging API".  The exact same statement can be reconstructed
> using "Log4J API" and it is equally true.

Not true. If part of the code is using commons-logging, and part is using
LogKit - you still have a single logger to configure ( LogKit ).

All the code written with commons-logging API will 'adapt' to whatever
logging implementation you use. If you code with log4j APIs and use the 
code with components using LogKit - you have 2 loggers to configure.


> If everyone uses commons-logging, then only one logger must be
> configured.  If everyone uses Log4J, then only one logger must be
> configured.  If third-party software is using different loggers, then
> you have to configure multiple loggers no matter what API your code
> uses.

Commons-logging doesn't impose any logging implementation - if the 
third-party software is using log4j, logkit, jdk1.4 - or a logger that 
can implement commons-logging APIs - you have to configure a single 
logger.

Using log4j ( or a specific logger ) is the action creating the dependency 
between your code and the logger implementation.

It's exactly like SAX and Xerces - if you code with SAX/DOM - your code 
will work with any parser. If some code is using Xerces or Crimson APIs -
it'll require that specific parser. 


> It seems to me that the commons-logging API just adds Yet Another
> Logging API... especially when someone gets the bright idea to make a
> "native" implementation of the API for performance reasons.

There is already a 'native' implementation - if no other logger is found 
it'll just do println().

> At least with Turbine, Struts, (Maverick :-), etc, there are some
> fundamentally different approaches to the problem of how to publish a
> web application.  Logging doesn't seem that complicated.  The massive
> duplication of this basic feature in the Jakarta codebase is silly, and
> trying to build an abstraction layer on top of it seems even sillier.

The duplication of the basic feature may be silly, but building an 
abstraction layer is IMHO the only possible solution. 

I see no problem with having multiple logger implementations - 
having a different API on each one is the problem.

What else do you propose ? There are at least 3 different loggers, 
little chance to see 2 go away - and people using all of them.
Commons-logging allows to write code that will not be 'tied' to any
particular logger implementation - and that's a very good thing.

Costin
 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Comments on the commons-logging API

[Jeff Schnitzer]

> From: Morgan Delagrange [mailto:[EMAIL PROTECTED]]
> 
> Yes, the defining advantage to the commons-logging API that I see is
that
> it
> allows users to adopt a single logging implementation, which confers
real

What needs to be appended to that statement is "...if everyone codes to
the commons-logging API".  The exact same statement can be reconstructed
using "Log4J API" and it is equally true.

If everyone uses commons-logging, then only one logger must be
configured.  If everyone uses Log4J, then only one logger must be
configured.  If third-party software is using different loggers, then
you have to configure multiple loggers no matter what API your code
uses.

It seems to me that the commons-logging API just adds Yet Another
Logging API... especially when someone gets the bright idea to make a
"native" implementation of the API for performance reasons.

At least with Turbine, Struts, (Maverick :-), etc, there are some
fundamentally different approaches to the problem of how to publish a
web application.  Logging doesn't seem that complicated.  The massive
duplication of this basic feature in the Jakarta codebase is silly, and
trying to build an abstraction layer on top of it seems even sillier.

Jeff Schnitzer
[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Andrew C. Oliver]

If you ask me I rather think it should be entirely there.

Paulo Gaspar wrote:

>Shouldn't this be posted at the commons-dev list?
>Or, at least, ALSO at commons-dev list?
>
>Have fun,
>Paulo Gaspar
>
>>-Original Message-
>>From: Ceki Gulcu [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, March 27, 2002 5:11 AM
>>To: [EMAIL PROTECTED]
>>Subject: Comments on the commons-logging API
>>
>>
>>
>>Hello all,
>>
>>Given that log4j is such a low-level library, most organizations are
>>suspicious to tie their code to log4j, especially considering the new
>>logging API in JDK 1.4.
>>
>>Before going forward, it is appropriate to mention that these two APIs
>>are very similar.  The classical usage pattern for log4j is:
>>
>>---
>>
>>import org.apache.log4j.Logger;
>>
>>public class MyClass {
>>   final static Logger logger = Logger.getLogger("some.name");
>>
>>public void foo1() {
>>  logger.debug("Hello world.");
>>}
>>
>>public void foo2() {
>>  logger.info("Another message.");
>>  logger.error("Stop that!", new Exception("The earth is getting
>>warmer."));
>>}
>>}
>>---
>>
>>As you are well aware by now, one of the important benefits of log4j
>>is that it can be configured at run time using configuration scripts.
>>You can have hundreds or thousands of log statement but only one or
>>two lines of code to configure log4j.
>>
>>The usage pattern for the JDK 1.4 logging API is:
>>
>>---
>>import java.util.logging.Logger;
>>
>>public class MyClass {
>>final static Logger logger = Logger.getLogger("test");
>>
>>public void foo1() {
>>  logger.debug("Hello world.");
>>}
>>
>>public void foo2() {
>>  logger.info("Another message.");
>>  logger.error("Stop that!", new Exception("The earth is getting
>>warmer."));
>>}
>>}
>>---
>>
>>Do you notice anything similar? The JDK 1.4 logging API also admits
>>configuration scripts. Being part of the JDK, the common guess that
>>this API will supplant log4j some time in the future.
>>
>>It is not so easy to write a complete logging API. Users
>>come to realize they need the features present in log4j but absent in
>>JDK 1.4 logging API.  Moreover, log4j runs with JDK 1.1 or later whereas
>>the JDK 1.4 logging API, requires, well, JDK 1.4.  Most users can't
>>afford to tie their code to JDK 1.4.
>>
>>But they need logging and they need it now. A common strategy for
>>protecting against future changes and at the same time to benefit from
>>existing log4j features is to *wrap* log4j with a custom logging
>>API. Log4j actually has support to facilitate such wrappers.
>>
>>It turns out that such wrappers are not that trivial to write. I
>>frequently
>>receive email where a user runs into a problem with their wrapper and
>>requests help. More often than not, these wrappers are of poor quality
>>such that the cost of inactive (or disabled) logging statements is
>>multiplied by a factor of 1'000.
>>
>>Of course, not all wrappers are of poor quality. For example, the
>>commons-logging API is rather well implemented. Obviously, there is
>>still a cost for the wrapping but it won't be of a huge factor.
>>
>>The commons-logging API will try to use the JDK 1.4 API if present, or
>>the log4j API. The *current* preference is log4j I believe. Neat!
>>
>>Now, it just happens that the part where most users have difficulty is the
>>initialization of the log4j API. Where should the log4j.jar go? Where
>>do I put the log4j.properties files?  Can I have different
>>web-applications have different log4j configurations?  How do I
>>initialize log4j in an application server?  Although there is ample
>>literature on the subject, much confusion remains.
>>
>>The commons-logging API as it wraps multiple logging APIs such
>>as Avalon's LogKit, log4j, JDK 1.4 has its own "discovery process".
>>Things were confusing before, they will be even more when
>>commons-logging API enters "common" usage. With some effort, it might
>>start making sense to you. Ho

Re: Comments on the commons-logging API

[Ceki Gülcü]

Costin, Morgan, Rodney,

Thanks for the lively discussion and sharing your points of view. My intent
was to warn users of the dangers of using common-logging. I have done
my bit. Cheers, Ceki

At 16:31 27.03.2002 -0600, Morgan wrote:
>I believe the order of precedence is well documented.  I think the logging
>component would benefit from warning messages when a default implementation
>is selected (like Log4J warns you when there is no log4j.properties file
>available), but this doesn't require any fundamental change to the API.
>
>If you want to take about confusion and despair, look at the environment
>that's running three logging implementations simultaneously.
>
>- Morgan

--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Morgan Delagrange]

- Original Message -
From: "Ceki Gülcü" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 27, 2002 4:20 PM
Subject: Re: Comments on the commons-logging API


> At 15:18 27.03.2002 -0600, Morgan Delagrange wrote:
> >Here's the problem, as I see it.
> >
> >Suppose Commons component A decides to adopt Log4J, Commons component B
> >decides to adopt LogKit, and Commons component C adopts JDK1.4 logging.
> >They will all minimally function with the right jars in the classpath.
> >However you (the end-user) are left with maintaining configuration for 3
> >different logging APIs, which is tedious at best.  When you take into
> >account cool features like variable log levels, Log4J appenders and the
> >like, you're pretty much guaranteed to swallow up useful configuration
> >options because sophisticated configurations are too difficult to
maintain
> >over mutiple logging implementations.
> >
> >Contrarily, if all three Commons components use a logging facade, you can
> >focus all your configuration efforts on one logging implementation.
Sure,
> >there is a trade-off; you don't have access to all the features, and the
> >interface between the facade and the implementation must be maintained.
But
> >the benefits are not just political; they potentially make the end-users
> >configuration much easier.
>
> So, if I understand correctly the reason for adopting commons-logging
> API is for convenience rather than non-intrusiveness as a library
> (with respect to logging).

Yes, the defining advantage to the commons-logging API that I see is that it
allows users to adopt a single logging implementation, which confers real
benefits particularly with regard to configuration.  Easy transitions from
one logging implementation to another are not particularly important; the
tangible benefit is to let disparate components have the _option_ to use the
same log without complicated bridges between logging implementations.

> With commons-logging, the end user will only have to configure the
> logging API that common-logging selects (or detects) but the selection
> mechanism is dynamic such that there are many ways and reasons for
> which the selected API will be the wrong one. This is the uncertainty
> factor I am talking about.  Uncertainty breeds confusion and confusion
> breeds despair.
>

I believe the order of precedence is well documented.  I think the logging
component would benefit from warning messages when a default implementation
is selected (like Log4J warns you when there is no log4j.properties file
available), but this doesn't require any fundamental change to the API.

If you want to take about confusion and despair, look at the environment
that's running three logging implementations simultaneously.

- Morgan


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Comments on the commons-logging API

[costinm]

On Wed, 27 Mar 2002, Ceki Gülcü wrote:

> So, if I understand correctly the reason for adopting commons-logging
> API is for convenience rather than non-intrusiveness as a library
> (with respect to logging).

The goals of commons-logging ( as I understand them ):
- non-intrusiveness
- convenience
- multiple implementations
- simple to use
- secure 
- useable in container environment 
( and probably more )

Each of those goals is important. 



> With commons-logging, the end user will only have to configure the
> logging API that common-logging selects (or detects) but the selection
> mechanism is dynamic such that there are many ways and reasons for
> which the selected API will be the wrong one. This is the uncertainty
> factor I am talking about.  Uncertainty breeds confusion and confusion
> breeds despair.

Not quite - it's the same mechansim used for JAXP detection. You can
set a logging API explicitely if you want ( system property - no 
confusion here ). 

Detection is used to simplify users' life and reduce the number of 
required settings. The only possible problem is if the user has
multiple loggers installed ( in which case he should use the explicit 
setting if he feels the need) . 


Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[costinm]

On Wed, 27 Mar 2002, Ceki Gülcü wrote:

> At 10:15 27.03.2002 -0800, [EMAIL PROTECTED] wrote:
> >The goal is not to be able to change the logger at compile time, but to be
> >able to detect the platform logger and use it. The only way to do that is
> >via a standard API - and commons-logging seems to be the only standard for
> >logging that we have, supported ( mostly unwillingly :-) on all logging
> >implementations. If you are concerned about the user experience with
> >commons-logging and log4j, the best way to resolve that is by
> >participating in commons-logging and implementing it in log4j so that
> >log4j will work best with commons-logging.
> 
> Rodney argued that the goal was to make commons components
> non-intrusive with respect to logging.

Well, there are more than 2 goals :-)


> If the goal is to detect (or guess) at run time the logging API to
> use, then this will only increase uncertainty and confusion. I know of
> a few frameworks (no, I won't tell you the names) that do this and it
> does not provide for a pleasant experience. Even I had trouble to set
> up logging and just gave up.

No, 'detecting/guessing' is not a goal - it's just one possible 
implementation - for the goal of allowing multiple implementations.

The goal here is to support multiple logging _implemementations_,
and provide a common/standard API for components to use.

By 'standard API' I mean the same thing as SAX - if you use SAX
your code will work with any parser that implements the SAX API.

It's certain that each parser ( and logger ) may have some better
internal APIs.


> To be brutally honest, I think the commons-logging approach is counter
> productive. It may seem like the politically correct thing to do but
> it will increase complexity and prove to be unproductive in the long
> run.  I thank you for the invitation to participate in the

I don't know any alternative to commons-logging. If you know any, I would
be happy to learn about it. Without an alternative, the only possible
approach is to improve commons-logging. 

Using log4j API and doing 'string replace' if you want to use another 
logger is absurd, I hope you weren't serious about proposing that. 

Unfortunately JDK1.4 logging API is not useable as a 'standard' for 
logging, and no other accepted standard exist (AFAIK). 

We have multiple logging implementations, and the only solution I know
is to use an API that works will all of them. I don't know what's
'conter productive' about it, it worked fine for SAX.

Costin




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Ceki Gülcü]

At 15:18 27.03.2002 -0600, Morgan Delagrange wrote:
>Here's the problem, as I see it.
>
>Suppose Commons component A decides to adopt Log4J, Commons component B
>decides to adopt LogKit, and Commons component C adopts JDK1.4 logging.
>They will all minimally function with the right jars in the classpath.
>However you (the end-user) are left with maintaining configuration for 3
>different logging APIs, which is tedious at best.  When you take into
>account cool features like variable log levels, Log4J appenders and the
>like, you're pretty much guaranteed to swallow up useful configuration
>options because sophisticated configurations are too difficult to maintain
>over mutiple logging implementations.
>
>Contrarily, if all three Commons components use a logging facade, you can
>focus all your configuration efforts on one logging implementation.  Sure,
>there is a trade-off; you don't have access to all the features, and the
>interface between the facade and the implementation must be maintained.  But
>the benefits are not just political; they potentially make the end-users
>configuration much easier.

So, if I understand correctly the reason for adopting commons-logging
API is for convenience rather than non-intrusiveness as a library
(with respect to logging).

With commons-logging, the end user will only have to configure the
logging API that common-logging selects (or detects) but the selection
mechanism is dynamic such that there are many ways and reasons for
which the selected API will be the wrong one. This is the uncertainty
factor I am talking about.  Uncertainty breeds confusion and confusion
breeds despair.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Comments on the commons-logging API

[costinm]

On Wed, 27 Mar 2002, Ceki Gülcü wrote:

> If your library chooses to use logging API XYZ, this does not impose
> XYZ to the clients of your library. Your clients can use the logging
> library they prefer (if they are using logging API) and your library
> can use XYZ. 

And the user will have to configure and use 2 loggers. Or maybe 3, 4 or 
more - depending on how many libraries he uses.

If I write an application and I choose log4j, I would like a single config 
file and a consistent behavior for all the components. Same if I choose 
logkit or jdk1.4. The user ( or tomcat, etc ) may have scripts, UI, 
security settings etc.


> One choice does not necessarily influence the other. For
> example, the fact that JBoss uses log4j does not impose a logging
> library to the bean developer. Similarly, Tomcat's logging library
> does not prevent web-app developers from using log4j.

If the bean developer is using commons-logging, he'll benefit of whatever 
user interface/setting/controls Jboss or tomcat provides.


Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[Morgan Delagrange]

- Original Message -
From: "Ceki Gülcü" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 27, 2002 2:43 PM
Subject: RE: Comments on the commons-logging API


> At 11:49 27.03.2002 -0600,  Rodney Waldhoff wrote:
>
> >But this isn't really the reason commons-logging was created.  Note that
> >most of the commons components are just that--tiny libraries meant to be
> >integrated/incorporated into larger frameworks and larger applications.
> >Some of these components need/want logging capabilities, or at least some
> >people need/want some components to have logging capabilities.  But it
seems
> >a obtrusive for some tiny library to dictate the logging framework (if
any)
> >that should be used by the larger application that contains it.  So the
> >component is stuck with a decision between not using logging at all, or
> >forcing some "standard" logging implementation upon the larger framework,
> >and the containing application is stuck with either converting everything
to
> >this "standard" logging implementation (and hoping that each component
> >agrees on what that is) or having a heterogeneous set of logs and logging
> >implementations.  Search-and-replace code switching isn't really an
option
> >for the commons components, or at least not a terribly good one.
>
> If your library chooses to use logging API XYZ, this does not impose
> XYZ to the clients of your library. Your clients can use the logging
> library they prefer (if they are using logging API) and your library
> can use XYZ. One choice does not necessarily influence the other. For
> example, the fact that JBoss uses log4j does not impose a logging
> library to the bean developer. Similarly, Tomcat's logging library
> does not prevent web-app developers from using log4j.

But it doesn't facilitate it either.

Here's the problem, as I see it.

Suppose Commons component A decides to adopt Log4J, Commons component B
decides to adopt LogKit, and Commons component C adopts JDK1.4 logging.
They will all minimally function with the right jars in the classpath.
However you (the end-user) are left with maintaining configuration for 3
different logging APIs, which is tedious at best.  When you take into
account cool features like variable log levels, Log4J appenders and the
like, you're pretty much guaranteed to swallow up useful configuration
options because sophisticated configurations are too difficult to maintain
over mutiple logging implementations.

Contrarily, if all three Commons components use a logging facade, you can
focus all your configuration efforts on one logging implementation.  Sure,
there is a trade-off; you don't have access to all the features, and the
interface between the facade and the implementation must be maintained.  But
the benefits are not just political; they potentially make the end-users
configuration much easier.

Even if all Commons components used the same logging implementation (Log4J
for example), other projects in Jakarta-land may choose otherwise.  If you
add enough Jakarta projects to your environment, you eventually end up with
the scenario described above.  It's a worthwhile effort to attempt a logging
solution that plays well with the Jakarta community at large.  I think in
many cases the Commons Logging component can fill that role.

To take your analogy of trading a nickel's worth of functionality for a
penny payoff later (only because I'm dying to play off of it, FEEL FREE TO
IGNORE THIS PARAGRAPH :), yes each logger implementation delivers that
nickel.  However Log4J is delivering a US nickel, LogKit a Canadian nickel,
and JDK 1.4 a wooden nickel.  Each end-user becomes a bank that must
constantly monitor the exchange rate between those nickels, including those
wooden nickels which aren't worth a damn.  Some banks would prefer the
guarantee of a good penny than deal with the hassle of all those nickels.
:)

> In other words, the argument about (jakarta-commons) components
> dictating a logging API to the containing application is widely
> accepted although very dubious in my opinion.
>

I don't know if the word "dictate" quite captures it.

>
> Anyway, I think we have been through all this already. I do not expect
> to be able to convince anyone altough I suspect uncertainty and the
> bug reports will, slowly but surely.

It may be difficult to maintain.  The most we can do to mitigate it is
frequent releases and careful version management.

> >Commons-Logging is meant to provide an alternative solution: create a
> >facade/adapter around an arbitrary logging API, use it at the common
> >component level, and allow the user (the containing application) to
select
> >which specific 

RE: Comments on the commons-logging API

[Ceki Gülcü]

At 11:49 27.03.2002 -0600,  Rodney Waldhoff wrote:

>But this isn't really the reason commons-logging was created.  Note that
>most of the commons components are just that--tiny libraries meant to be
>integrated/incorporated into larger frameworks and larger applications.
>Some of these components need/want logging capabilities, or at least some
>people need/want some components to have logging capabilities.  But it seems
>a obtrusive for some tiny library to dictate the logging framework (if any)
>that should be used by the larger application that contains it.  So the
>component is stuck with a decision between not using logging at all, or
>forcing some "standard" logging implementation upon the larger framework,
>and the containing application is stuck with either converting everything to
>this "standard" logging implementation (and hoping that each component
>agrees on what that is) or having a heterogeneous set of logs and logging
>implementations.  Search-and-replace code switching isn't really an option
>for the commons components, or at least not a terribly good one.

If your library chooses to use logging API XYZ, this does not impose
XYZ to the clients of your library. Your clients can use the logging
library they prefer (if they are using logging API) and your library
can use XYZ. One choice does not necessarily influence the other. For
example, the fact that JBoss uses log4j does not impose a logging
library to the bean developer. Similarly, Tomcat's logging library
does not prevent web-app developers from using log4j.

In other words, the argument about (jakarta-commons) components
dictating a logging API to the containing application is widely
accepted although very dubious in my opinion.

Anyway, I think we have been through all this already. I do not expect
to be able to convince anyone altough I suspect uncertainty and the
bug reports will, slowly but surely.

>Commons-Logging is meant to provide an alternative solution: create a
>facade/adapter around an arbitrary logging API, use it at the common
>component level, and allow the user (the containing application) to select
>which specific logging implementation (if any) to use.  Then the same binary
>works everywhere, and in many (most?) cases, the commons-logging will just
>quietly do what you hope it would. (If you've got log4j, it uses it. If
>you've got JDK 1.4, it uses that. If all else fails, it doesn't do
>anything.)

I don't think "hoping quitely" and computers get along very well.

>An arbitrary application or system shouldn't feel compelled nor even
>(necessarily) encouraged to use commons-logging. That's not what it's there
>for.  It's there to allow the library components to delegate that decision
>to the containing application.

I understand your argument. I have already exposed mine. Thanks for your
attention. Ceki



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comments on the commons-logging API

[costinm]

Ceki,

I'm not sure I understand very well this. 

I think we have a consensus on few items ( and you seem to just repeat 
them ):

- JDK1.4 logging is not useable as a 'standard logging API' ( even if it 
is released under JCP )

- log4j is the best logger ( for Peter and few others: logkit is the best 
logger, and I doubt too many people will argue that JDK1.4 logging is the 
best ). The consensus here is that everyone has a favorite logger 
implementation. 

- there are other logger implementations in use - JDK1.4, logkit, log4j, 
probably many others ( for example tomcat3.3 and tomcat4.0 each has a 
logger ).

- it is better for a user program to code using a single API and beeing 
able to choose the implemntation.

The commons-logging API is implementable by each logger, and it's the 
closest to a 'standard API for logging' that you can get. 

If the wrapping performance worries you - there's a very simple solution, 
at your disposal - just make log4j.Logger implement commons.Logger, 
create and maintain a log4j factory that is consistent with the rest of 
log4j and you'll have no wrapper :-)

With the current discovery mechnism, if you implement commons-logger 
factory and include the manifest entry in log4j, it'll automatically be 
used ( instead of the wrapper ). 

Replacing the package name is a silly sugestion - you realize most people 
want to release a single package and have it work, you can't ask the 
user to do a replace and recompile if they want a different logger.
 
The goal is not to be able to change the logger at compile time, but to be 
able to detect the platform logger and use it. The only way to do that is 
via a standard API - and commons-logging seems to be the only standard for 
logging that we have, supported ( mostly unwillingly :-) on all logging 
implementations. If you are concerned about the user experience with 
commons-logging and log4j, the best way to resolve that is by 
participating in commons-logging and implementing it in log4j so that 
log4j will work best with commons-logging.


Costin


On Wed, 27 Mar 2002, Ceki Gülcü wrote:

> 
> Hello all,
> 
> Given that log4j is such a low-level library, most organizations are
> suspicious to tie their code to log4j, especially considering the new
> logging API in JDK 1.4.
> 
> Before going forward, it is appropriate to mention that these two APIs
> are very similar.  The classical usage pattern for log4j is:
> 
> ---
> 
> import org.apache.log4j.Logger;
> 
> public class MyClass {
>final static Logger logger = Logger.getLogger("some.name");
> 
> public void foo1() {
>   logger.debug("Hello world.");
> }
> 
> public void foo2() {
>   logger.info("Another message.");
>   logger.error("Stop that!", new Exception("The earth is getting 
> warmer."));
> }
> }
> ---
> 
> As you are well aware by now, one of the important benefits of log4j
> is that it can be configured at run time using configuration scripts.
> You can have hundreds or thousands of log statement but only one or
> two lines of code to configure log4j.
> 
> The usage pattern for the JDK 1.4 logging API is:
> 
> ---
> import java.util.logging.Logger;
> 
> public class MyClass {
> final static Logger logger = Logger.getLogger("test");
> 
> public void foo1() {
>   logger.debug("Hello world.");
> }
> 
> public void foo2() {
>   logger.info("Another message.");
>   logger.error("Stop that!", new Exception("The earth is getting 
> warmer."));
> }
> }
> ---
> 
> Do you notice anything similar? The JDK 1.4 logging API also admits
> configuration scripts. Being part of the JDK, the common guess that
> this API will supplant log4j some time in the future.
> 
> It is not so easy to write a complete logging API. Users
> come to realize they need the features present in log4j but absent in
> JDK 1.4 logging API.  Moreover, log4j runs with JDK 1.1 or later whereas
> the JDK 1.4 logging API, requires, well, JDK 1.4.  Most users can't
> afford to tie their code to JDK 1.4.
> 
> But they need logging and they need it now. A common strategy for
> protecting against future changes and at the same time to benefit from
> existing log4j features is to *wrap* log4j with a custom logging
> API. Log4j actually has support to facilitate such wrappers.
> 
> It turns out that such wrappers are not that trivial to write. I frequently
> receive email where a user runs into a problem with their wrapper and
> requests help. More often than not, these wrappers are of poor quality
> such that the cost of inactive (or disabled) logging statements is
> multiplied by a factor of 1'000.
> 
> Of course, not all wrappers are of poor quality. For example, the
> commons-logging API is rather well implemente

RE: Comments on the commons-logging API

[Waldhoff, Rodney]

I'm quoting Ceki's entire message here because I think he raises a number of
interesting and valid points.

But I think this misinterprets what (in my mind) is the main point of
commons-logging.

One can use commons-logging, as you state, as a implementation-independent
logging wrapper in hopes of reducing the cost of  switching between log4j
and JDK 1.4 (or logkit or whatever else comes along). But as you say, for
some changes the switching cost is already quite low.  (It's not clear to me
that the switching cost between, say, logkit and log4j is similarly low, but
maybe it is, I really don't know.)

But this isn't really the reason commons-logging was created.  Note that
most of the commons components are just that--tiny libraries meant to be
integrated/incorporated into larger frameworks and larger applications.
Some of these components need/want logging capabilities, or at least some
people need/want some components to have logging capabilities.  But it seems
a obtrusive for some tiny library to dictate the logging framework (if any)
that should be used by the larger application that contains it.  So the
component is stuck with a decision between not using logging at all, or
forcing some "standard" logging implementation upon the larger framework,
and the containing application is stuck with either converting everything to
this "standard" logging implementation (and hoping that each component
agrees on what that is) or having a heterogeneous set of logs and logging
implementations.  Search-and-replace code switching isn't really an option
for the commons components, or at least not a terribly good one.

Commons-Logging is meant to provide an alternative solution: create a
facade/adapter around an arbitrary logging API, use it at the common
component level, and allow the user (the containing application) to select
which specific logging implementation (if any) to use.  Then the same binary
works everywhere, and in many (most?) cases, the commons-logging will just
quietly do what you hope it would. (If you've got log4j, it uses it. If
you've got JDK 1.4, it uses that. If all else fails, it doesn't do
anything.)

An arbitrary application or system shouldn't feel compelled nor even
(necessarily) encouraged to use commons-logging. That's not what it's there
for.  It's there to allow the library components to delegate that decision
to the containing application.

 - Rod

-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 26, 2002 10:11 PM
To: [EMAIL PROTECTED]
Subject: Comments on the commons-logging API



Hello all,

Given that log4j is such a low-level library, most organizations are
suspicious to tie their code to log4j, especially considering the new
logging API in JDK 1.4.

Before going forward, it is appropriate to mention that these two APIs
are very similar.  The classical usage pattern for log4j is:

---

import org.apache.log4j.Logger;

public class MyClass {
   final static Logger logger = Logger.getLogger("some.name");

public void foo1() {
  logger.debug("Hello world.");
}

public void foo2() {
  logger.info("Another message.");
  logger.error("Stop that!", new Exception("The earth is getting 
warmer."));
}
}
---

As you are well aware by now, one of the important benefits of log4j
is that it can be configured at run time using configuration scripts.
You can have hundreds or thousands of log statement but only one or
two lines of code to configure log4j.

The usage pattern for the JDK 1.4 logging API is:

---
import java.util.logging.Logger;

public class MyClass {
final static Logger logger = Logger.getLogger("test");

public void foo1() {
  logger.debug("Hello world.");
}

public void foo2() {
  logger.info("Another message.");
  logger.error("Stop that!", new Exception("The earth is getting 
warmer."));
}
}
---

Do you notice anything similar? The JDK 1.4 logging API also admits
configuration scripts. Being part of the JDK, the common guess that
this API will supplant log4j some time in the future.

It is not so easy to write a complete logging API. Users
come to realize they need the features present in log4j but absent in
JDK 1.4 logging API.  Moreover, log4j runs with JDK 1.1 or later whereas
the JDK 1.4 logging API, requires, well, JDK 1.4.  Most users can't
afford to tie their code to JDK 1.4.

But they need logging and they need it now. A common strategy for
protecting against future changes and at the same time to benefit from
existing log4j features is to *wra

RE: Comments on the commons-logging API

[Paulo Gaspar]

Shouldn't this be posted at the commons-dev list?
Or, at least, ALSO at commons-dev list?

Have fun,
Paulo Gaspar

> -Original Message-
> From: Ceki Gulcu [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 27, 2002 5:11 AM
> To: [EMAIL PROTECTED]
> Subject: Comments on the commons-logging API
>
>
>
> Hello all,
>
> Given that log4j is such a low-level library, most organizations are
> suspicious to tie their code to log4j, especially considering the new
> logging API in JDK 1.4.
>
> Before going forward, it is appropriate to mention that these two APIs
> are very similar.  The classical usage pattern for log4j is:
>
> ---
>
> import org.apache.log4j.Logger;
>
> public class MyClass {
>final static Logger logger = Logger.getLogger("some.name");
>
> public void foo1() {
>   logger.debug("Hello world.");
> }
>
> public void foo2() {
>   logger.info("Another message.");
>   logger.error("Stop that!", new Exception("The earth is getting
> warmer."));
> }
> }
> ---
>
> As you are well aware by now, one of the important benefits of log4j
> is that it can be configured at run time using configuration scripts.
> You can have hundreds or thousands of log statement but only one or
> two lines of code to configure log4j.
>
> The usage pattern for the JDK 1.4 logging API is:
>
> ---
> import java.util.logging.Logger;
>
> public class MyClass {
> final static Logger logger = Logger.getLogger("test");
>
> public void foo1() {
>   logger.debug("Hello world.");
> }
>
> public void foo2() {
>   logger.info("Another message.");
>   logger.error("Stop that!", new Exception("The earth is getting
> warmer."));
> }
> }
> ---
>
> Do you notice anything similar? The JDK 1.4 logging API also admits
> configuration scripts. Being part of the JDK, the common guess that
> this API will supplant log4j some time in the future.
>
> It is not so easy to write a complete logging API. Users
> come to realize they need the features present in log4j but absent in
> JDK 1.4 logging API.  Moreover, log4j runs with JDK 1.1 or later whereas
> the JDK 1.4 logging API, requires, well, JDK 1.4.  Most users can't
> afford to tie their code to JDK 1.4.
>
> But they need logging and they need it now. A common strategy for
> protecting against future changes and at the same time to benefit from
> existing log4j features is to *wrap* log4j with a custom logging
> API. Log4j actually has support to facilitate such wrappers.
>
> It turns out that such wrappers are not that trivial to write. I
> frequently
> receive email where a user runs into a problem with their wrapper and
> requests help. More often than not, these wrappers are of poor quality
> such that the cost of inactive (or disabled) logging statements is
> multiplied by a factor of 1'000.
>
> Of course, not all wrappers are of poor quality. For example, the
> commons-logging API is rather well implemented. Obviously, there is
> still a cost for the wrapping but it won't be of a huge factor.
>
> The commons-logging API will try to use the JDK 1.4 API if present, or
> the log4j API. The *current* preference is log4j I believe. Neat!
>
> Now, it just happens that the part where most users have difficulty is the
> initialization of the log4j API. Where should the log4j.jar go? Where
> do I put the log4j.properties files?  Can I have different
> web-applications have different log4j configurations?  How do I
> initialize log4j in an application server?  Although there is ample
> literature on the subject, much confusion remains.
>
> The commons-logging API as it wraps multiple logging APIs such
> as Avalon's LogKit, log4j, JDK 1.4 has its own "discovery process".
> Things were confusing before, they will be even more when
> commons-logging API enters "common" usage. With some effort, it might
> start making sense to you. However, your users will not show the same
> perseverance nor enthusiasm.
>
> There will be also unexpected interactions between log4j and the
> commons-logging API. For example, log4j 1.2alpha1 through alpha4 had a
> very subtle bug which caused client code compiled with log4j version
> 1.1.3 to throw exceptions when ran with log4j 1.2alpha. Inversely,
> code compiled with 1.2alpha would crash when ran usin

Comments on the commons-logging API

[Ceki Gülcü]

Hello all,

Given that log4j is such a low-level library, most organizations are
suspicious to tie their code to log4j, especially considering the new
logging API in JDK 1.4.

Before going forward, it is appropriate to mention that these two APIs
are very similar.  The classical usage pattern for log4j is:

---

import org.apache.log4j.Logger;

public class MyClass {
   final static Logger logger = Logger.getLogger("some.name");

public void foo1() {
  logger.debug("Hello world.");
}

public void foo2() {
  logger.info("Another message.");
  logger.error("Stop that!", new Exception("The earth is getting 
warmer."));
}
}
---

As you are well aware by now, one of the important benefits of log4j
is that it can be configured at run time using configuration scripts.
You can have hundreds or thousands of log statement but only one or
two lines of code to configure log4j.

The usage pattern for the JDK 1.4 logging API is:

---
import java.util.logging.Logger;

public class MyClass {
final static Logger logger = Logger.getLogger("test");

public void foo1() {
  logger.debug("Hello world.");
}

public void foo2() {
  logger.info("Another message.");
  logger.error("Stop that!", new Exception("The earth is getting 
warmer."));
}
}
---

Do you notice anything similar? The JDK 1.4 logging API also admits
configuration scripts. Being part of the JDK, the common guess that
this API will supplant log4j some time in the future.

It is not so easy to write a complete logging API. Users
come to realize they need the features present in log4j but absent in
JDK 1.4 logging API.  Moreover, log4j runs with JDK 1.1 or later whereas
the JDK 1.4 logging API, requires, well, JDK 1.4.  Most users can't
afford to tie their code to JDK 1.4.

But they need logging and they need it now. A common strategy for
protecting against future changes and at the same time to benefit from
existing log4j features is to *wrap* log4j with a custom logging
API. Log4j actually has support to facilitate such wrappers.

It turns out that such wrappers are not that trivial to write. I frequently
receive email where a user runs into a problem with their wrapper and
requests help. More often than not, these wrappers are of poor quality
such that the cost of inactive (or disabled) logging statements is
multiplied by a factor of 1'000.

Of course, not all wrappers are of poor quality. For example, the
commons-logging API is rather well implemented. Obviously, there is
still a cost for the wrapping but it won't be of a huge factor.

The commons-logging API will try to use the JDK 1.4 API if present, or
the log4j API. The *current* preference is log4j I believe. Neat!

Now, it just happens that the part where most users have difficulty is the
initialization of the log4j API. Where should the log4j.jar go? Where
do I put the log4j.properties files?  Can I have different
web-applications have different log4j configurations?  How do I
initialize log4j in an application server?  Although there is ample
literature on the subject, much confusion remains.

The commons-logging API as it wraps multiple logging APIs such
as Avalon's LogKit, log4j, JDK 1.4 has its own "discovery process".
Things were confusing before, they will be even more when
commons-logging API enters "common" usage. With some effort, it might
start making sense to you. However, your users will not show the same
perseverance nor enthusiasm.

There will be also unexpected interactions between log4j and the
commons-logging API. For example, log4j 1.2alpha1 through alpha4 had a
very subtle bug which caused client code compiled with log4j version
1.1.3 to throw exceptions when ran with log4j 1.2alpha. Inversely,
code compiled with 1.2alpha would crash when ran using log4j 1.1.3.
This problem was fixed in log4j beta.

It is now sufficient for client code to be compiled with 1.1.x and to
run with 1.2 beta without problems and vice versa. Of course if
commons-logging compiled with log4j 1.2alpha the problem would be
sticky. It would not go away by compiling client code but only by replacing
the commons-logging API.

In the recent weeks I have also started to receive disturbing bug reports
where components using commons-logging API behave strangely.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7484
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6764

I suspect that these problems will only worsen in the future. The
commons-logging developers will suspect a log4j bug and we will
suspect a commons-logging API bug. By increasing the number of
components required for logging you have doubled the probability of
bugs while the difficulty of resolving them has increased by a higher
multiple.

Remember that the