RE: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Comments on the commons-logging API
+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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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/standardization/
--
To unsubscribe, e-mail:
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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. 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
- 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
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]
Re: Comments on the commons-logging API
- 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ü [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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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
- 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
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Comments on the commons-logging API
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
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Comments on the commons-logging API
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
-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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Comments on the commons-logging API
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 *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
Re: Comments on the commons-logging API
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 implemented. Obviously, there is
still a cost for the wrapping but it won't be of a huge factor.
The
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. 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
- 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 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
RE: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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). 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comments on the commons-logging API
- 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
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
