Re: [logging] Enterprise Common Logging... dare we say 2.0?
Robert, Richard, Thank you both. On 2005-02-07 18:27:31, Richard Sitze wrote: System ClassLoader | +--+-+ || Host --- creates -- Sub -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On Mon, 2005-02-07 at 18:57, Ceki Gülcü wrote: Robert, Richard, Thank you both. i think richard's explanation wins, though :) On 2005-02-07 18:27:31, Richard Sitze wrote: System ClassLoader | +--+-+ || Host --- creates -- Sub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Well I've had a few days to cool off, and my head feels better too. I acknowledge that there are problems with the discovery process in JCL. We aim to fix that, it is one of the tenants of what is being proposed for JCL version 'next'. I wish it were as simple to resolve these issues in the more difficult environments [of which J2EE is a prime example], so the bottom line is that the UGLI solution doesn't *solve* the problems, it just doesn't complain as much... which admittedly might be considered a step forward depending on your point of view [silently operate in an unexpected manner vs. loudly proclaiming that a problem exists]. For JCL 'next' I'm looking for something of a middle ground that really solves the problems... all of them [alternate notes have/will discuss this]. I'm thrilled that Log4J mapped their interface to an independent interface. I'm sorry we couldn't coordinate that better between Log4J and JCL way back before JCL 1.0. What concerns me is that we have competing abstractions that are intended to be layered above interfaces. I also recognize the value of an interface not tied to Log4J, that we can grow forward and continue to layer above the implementations. So... let me toss out a not-so-random thought, and let's see how we all feel about this after some discussion: Can we bring these two together? Ceki, would your team be willing to make some concessions in the UGLI implementation, in the interest of supporting a common abstraction? Thoughts include: - Leaving JCL 1.0.x alone... and retiring it altogether in favor of an UGLI based approach. - Adopting the UGLI style interface as the base interface. - Layering in the JCL Log methods [support backwards compatibility] as deprecated methods where they differ from the UGLI interface? - We proposed a separate jar file per impl approach, in line with yours, to help minimize the JCL problems for JCL 'next'... so we're in sync with the fundamental advantages that offers - Adopting a more sophisticated discovery that allows the separate jar file per impl approach to work in a defined way for class hierarchies [such as J2EE] that might include multiple/different UGLI jar files [and yes, I'm talking about a *FIXED* process, not the current broken process]. - Log4J MUST be willing to accept extentions to UGLI [via interfaces that extend] that might go over and beyond the Log4J native supported methods [i.e., open to the types of discussions that are occuring now with JCL]. If I'm out of line here, set me straight.. but Ceki I still see Log4J as being under your thumb, and there are others in the community with valid differences of opinions that are looking for a voice. I'd like to point out that the JCL interface has been rigid, we've resisted change, and are only recently proposing any new change as extensions... I don't see this being a common occurance. dream on In short, can we merge these two in one fashion or another, and still accomplish our goals? dream off ras news [EMAIL PROTECTED] wrote on 01/25/2005 03:43:54 PM: I'm sorry, I didn't mean for my post to sound angry, and I'm sorry if anyone took offense. I was just asking :) Ceki, thanks for that link. You have many excellent points, and I may migrate my projects away from commons-logging. Matt Vic wrote: Matt Sgarlata wrote: You've spent a lot of time discussing commons-logging on this list, while at the same time supporting development of UGLI. Which component is your favorite? How come you're working on 2? Simmer down now. Lets act intelligent. Many people work on many things and share code across projects its a friendly license. Look at Struts, it has JSF subprojects under it, or lets play how many duplicate projects we can name under ASF. Its all good. Much duplication in Apache, all of it good. Choice = = good. What was that platform where they have the ONE true way? ..V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Richard A. Sitze IBM WebSphere WebServices Development
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Richard Sitze wrote: Can we bring these two together? Ceki, would your team be willing to make some concessions in the UGLI implementation, in the interest of supporting a common abstraction? Thoughts include: - Leaving JCL 1.0.x alone... and retiring it altogether in favor of an UGLI based approach. - Adopting the UGLI style interface as the base interface. Hey, that sounds good to me as a user. Even cross merging teams? .V -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Richard Sitze wrote:
news [EMAIL PROTECTED] wrote on 12/21/2004 08:04:09 AM:
+1, I agree with you and Ceki. TRACE is debatable (I personally like
it), more than TRACE is silly.
Well... call them what you will, I want em'!! lol
And yes, I'm leaning towards EXPLICITLY naming methods to encourage best
practices. To use the distinction made by Curt, I'm pushing the trace
level methods towards diagnostic logger function, and stepping away from
other uses entirely. I'm going to refrain from doing a full brain dump on
all the fun thoughts now running through my head... [separating trace
level methods and messaging/admin level methods into seperate interfaces..
ok I lied].
I think we can pretty much lay to rest the argument that including
ENTER/EXIT is a best practice. There have been so many arguments on
both sides of the issue that it's pretty clear we're not going to reach
a concensus. A best practice is something like database connection
pooling, which everyone agrees is a good idea. ENTER/EXIT is a highly
contentious issue, given that this debate has been raging for weeks.
I still don't understand why if you want enter/exit methods you can't
just do it in your own static method somewhere like shown below.
MyLoggingUtils.enter(MyClass.class, myMethodName, new Object[] { arg1,
arg2, arg3 }).
Does JDK 1.4 logging do something really fancy with ENTER/EXIT methods
that makes you argue so strongly for them? Or is there something in
that IBM alphaworks project that depends on the enter/exit methods?
Couldn't it be rewritten to filter TRACE level logging that began with
the text Entering or Exiting?
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
I kind of think that maybe commons-logging should be deprecated in
favor of:
http://logging.apache.org/log4j/docs/ugli.html
See UGLI does same thing. But competitions is a good thing; my projects
will ship w/ Log4j instead and ugli. One less jar is good.
.V
Matt Sgarlata wrote:
Richard Sitze wrote:
news [EMAIL PROTECTED] wrote on 12/21/2004 08:04:09 AM:
+1, I agree with you and Ceki. TRACE is debatable (I personally
like it), more than TRACE is silly.
Well... call them what you will, I want em'!! lol
And yes, I'm leaning towards EXPLICITLY naming methods to encourage
best practices. To use the distinction made by Curt, I'm pushing the
trace level methods towards diagnostic logger function, and stepping
away from other uses entirely. I'm going to refrain from doing a
full brain dump on all the fun thoughts now running through my
head... [separating trace level methods and messaging/admin level
methods into seperate interfaces.. ok I lied].
I think we can pretty much lay to rest the argument that including
ENTER/EXIT is a best practice. There have been so many arguments on
both sides of the issue that it's pretty clear we're not going to
reach a concensus. A best practice is something like database
connection pooling, which everyone agrees is a good idea. ENTER/EXIT
is a highly contentious issue, given that this debate has been raging
for weeks.
I still don't understand why if you want enter/exit methods you can't
just do it in your own static method somewhere like shown below.
MyLoggingUtils.enter(MyClass.class, myMethodName, new Object[] {
arg1, arg2, arg3 }).
Does JDK 1.4 logging do something really fancy with ENTER/EXIT methods
that makes you argue so strongly for them? Or is there something in
that IBM alphaworks project that depends on the enter/exit methods?
Couldn't it be rewritten to filter TRACE level logging that began with
the text Entering or Exiting?
Matt
--
Forums, Boards, Blogs and News in RiA http://www.boardVU.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Well now... that IS interesting.
flames on
How in the WORLD did this happen? I approached Ceki about aligning JCL
with Log4J... and was turned down, he simply wasn't interested and
wouldn't acknowledge the value of the abstraction [at that time].
This feels like 'not-invented-here' and some backstabbing. How can we
POSSIBLY accomplish our goals if we simply refuse to acknowledge that
other projects have value?! What can we achieve with competing
abstractions at this level?
Frankly, I expected better of the Apache Logging Services community.
Excuse me while I go find a wall and beat my head against it for a
while...
flames off
ras
news [EMAIL PROTECTED] wrote on 01/25/2005 01:21:24 PM:
I kind of think that maybe commons-logging should be deprecated in
favor of:
http://logging.apache.org/log4j/docs/ugli.html
See UGLI does same thing. But competitions is a good thing; my projects
will ship w/ Log4j instead and ugli. One less jar is good.
.V
Matt Sgarlata wrote:
Richard Sitze wrote:
news [EMAIL PROTECTED] wrote on 12/21/2004 08:04:09 AM:
+1, I agree with you and Ceki. TRACE is debatable (I personally
like it), more than TRACE is silly.
Well... call them what you will, I want em'!! lol
And yes, I'm leaning towards EXPLICITLY naming methods to encourage
best practices. To use the distinction made by Curt, I'm pushing the
trace level methods towards diagnostic logger function, and stepping
away from other uses entirely. I'm going to refrain from doing a
full brain dump on all the fun thoughts now running through my
head... [separating trace level methods and messaging/admin level
methods into seperate interfaces.. ok I lied].
I think we can pretty much lay to rest the argument that including
ENTER/EXIT is a best practice. There have been so many arguments on
both sides of the issue that it's pretty clear we're not going to
reach a concensus. A best practice is something like database
connection pooling, which everyone agrees is a good idea. ENTER/EXIT
is a highly contentious issue, given that this debate has been raging
for weeks.
I still don't understand why if you want enter/exit methods you can't
just do it in your own static method somewhere like shown below.
MyLoggingUtils.enter(MyClass.class, myMethodName, new Object[] {
arg1, arg2, arg3 }).
Does JDK 1.4 logging do something really fancy with ENTER/EXIT methods
that makes you argue so strongly for them? Or is there something in
that IBM alphaworks project that depends on the enter/exit methods?
Couldn't it be rewritten to filter TRACE level logging that began with
the text Entering or Exiting?
Matt
--
Forums, Boards, Blogs and News in RiA http://www.boardVU.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
***
Richard A. Sitze
IBM WebSphere WebServices Development
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 2005-01-25 19:40:35, Richard Sitze wrote: How in the WORLD did this happen? UGLI did not happen overnight. The idea was discussed on this list among others over 6 months ago. http://marc.theaimsgroup.com/?t=10865459724r=1w=2 This feels like 'not-invented-here' and some backstabbing. How can we POSSIBLY accomplish our goals if we simply refuse to acknowledge that other projects have value?! What can we achieve with competing abstractions at this level? The answer can be summarized in a few words: look Ma, no class loaders! Frankly, I expected better of the Apache Logging Services community. Agreed. How dare Apache Logging Services write a logging interface? Moreover, they never complained about JCL before. Seriously, aren't you sick of JCL exploding with an LogConfigurationException at the most inappropriate times? Excuse me while I go find a wall and beat my head against it for a while... No problem. You'll thank us later. :-) -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
I'm confused Ceki. You've spent a lot of time discussing commons-logging on this list, while at the same time supporting development of UGLI. Which component is your favorite? How come you're working on 2? Matt Ceki Gülcü wrote: On 2005-01-25 19:40:35, Richard Sitze wrote: How in the WORLD did this happen? UGLI did not happen overnight. The idea was discussed on this list among others over 6 months ago. http://marc.theaimsgroup.com/?t=10865459724r=1w=2 This feels like 'not-invented-here' and some backstabbing. How can we POSSIBLY accomplish our goals if we simply refuse to acknowledge that other projects have value?! What can we achieve with competing abstractions at this level? The answer can be summarized in a few words: look Ma, no class loaders! Frankly, I expected better of the Apache Logging Services community. Agreed. How dare Apache Logging Services write a logging interface? Moreover, they never complained about JCL before. Seriously, aren't you sick of JCL exploding with an LogConfigurationException at the most inappropriate times? Excuse me while I go find a wall and beat my head against it for a while... No problem. You'll thank us later. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 2005-01-25 20:45:34, Matt Sgarlata wrote: I'm confused Ceki. You've spent a lot of time discussing commons-logging on this list, while at the same time supporting development of UGLI. Which component is your favorite? How come you're working on 2? As far as I knew, swearing allegiance to commons-logging was not a prerequisite for participation in this list. Moreover, my position on JCL was always publicly known [1]. [1] http://www.qos.ch/logging/thinkAgain.jsp Matt -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Matt Sgarlata wrote: You've spent a lot of time discussing commons-logging on this list, while at the same time supporting development of UGLI. Which component is your favorite? How come you're working on 2? Simmer down now. Lets act intelligent. Many people work on many things and share code across projects its a friendly license. Look at Struts, it has JSF subprojects under it, or lets play how many duplicate projects we can name under ASF. Its all good. Much duplication in Apache, all of it good. Choice = = good. What was that platform where they have the ONE true way? .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
I'm sorry, I didn't mean for my post to sound angry, and I'm sorry if anyone took offense. I was just asking :) Ceki, thanks for that link. You have many excellent points, and I may migrate my projects away from commons-logging. Matt Vic wrote: Matt Sgarlata wrote: You've spent a lot of time discussing commons-logging on this list, while at the same time supporting development of UGLI. Which component is your favorite? How come you're working on 2? Simmer down now. Lets act intelligent. Many people work on many things and share code across projects its a friendly license. Look at Struts, it has JSF subprojects under it, or lets play how many duplicate projects we can name under ASF. Its all good. Much duplication in Apache, all of it good. Choice = = good. What was that platform where they have the ONE true way? ..V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Enterprise Common Logging... dare we say 2.0?
Richard:
You might find the attached GIF handy ;-)
Gary
-Original Message-
From: Richard Sitze [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 25, 2005 11:41 AM
To: Jakarta Commons Developers List
Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?
Well now... that IS interesting.
flames on
How in the WORLD did this happen? I approached Ceki about aligning JCL
with Log4J... and was turned down, he simply wasn't interested and
wouldn't acknowledge the value of the abstraction [at that time].
This feels like 'not-invented-here' and some backstabbing. How can we
POSSIBLY accomplish our goals if we simply refuse to acknowledge that
other projects have value?! What can we achieve with competing
abstractions at this level?
Frankly, I expected better of the Apache Logging Services community.
Excuse me while I go find a wall and beat my head against it for a
while...
flames off
ras
news [EMAIL PROTECTED] wrote on 01/25/2005 01:21:24 PM:
I kind of think that maybe commons-logging should be deprecated in
favor of:
http://logging.apache.org/log4j/docs/ugli.html
See UGLI does same thing. But competitions is a good thing; my
projects
will ship w/ Log4j instead and ugli. One less jar is good.
.V
Matt Sgarlata wrote:
Richard Sitze wrote:
news [EMAIL PROTECTED] wrote on 12/21/2004 08:04:09 AM:
+1, I agree with you and Ceki. TRACE is debatable (I personally
like it), more than TRACE is silly.
Well... call them what you will, I want em'!! lol
And yes, I'm leaning towards EXPLICITLY naming methods to encourage
best practices. To use the distinction made by Curt, I'm pushing
the
trace level methods towards diagnostic logger function, and
stepping
away from other uses entirely. I'm going to refrain from doing a
full brain dump on all the fun thoughts now running through my
head... [separating trace level methods and messaging/admin level
methods into seperate interfaces.. ok I lied].
I think we can pretty much lay to rest the argument that including
ENTER/EXIT is a best practice. There have been so many arguments
on
both sides of the issue that it's pretty clear we're not going to
reach a concensus. A best practice is something like database
connection pooling, which everyone agrees is a good idea.
ENTER/EXIT
is a highly contentious issue, given that this debate has been
raging
for weeks.
I still don't understand why if you want enter/exit methods you
can't
just do it in your own static method somewhere like shown below.
MyLoggingUtils.enter(MyClass.class, myMethodName, new Object[] {
arg1, arg2, arg3 }).
Does JDK 1.4 logging do something really fancy with ENTER/EXIT
methods
that makes you argue so strongly for them? Or is there something in
that IBM alphaworks project that depends on the enter/exit methods?
Couldn't it be rewritten to filter TRACE level logging that began
with
the text Entering or Exiting?
Matt
--
Forums, Boards, Blogs and News in RiA http://www.boardVU.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
***
Richard A. Sitze
IBM WebSphere WebServices Development
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 3 Jan 2005, at 17:03, Ceki Gülcü wrote: At 05:53 PM 1/3/2005, robert burrell donkin wrote: nope (but don't ask me to find the references). distributing an api jar which requires runtime dependencies was a mistake. this issue hasn't arisen for quite a while since we try to keep quiet about the existing of the api jar. I do not understand. How can JCL *not* require runtime dependencies given that it is a wrapper around various logging APIs? In other words, how can JCL wrap API x without runtime dependencies on API x? a minimal core should have robust behaviour when deployed without any support (rather than die horribly). for example, IIRC log4j prints up a message to System.err and then silently swallows all messages when it cannot configure itself. JCL core should do something similar (though i'd advocate logging fatal - and possibly error level messages - to System.err for the reasons explained well in james strachan's blog http://radio.weblogs.com/0112098/2004/10/06.html). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 27 Dec 2004, at 23:52, Ceki Gülcü wrote: On 2004-12-16 18:09:36, Richard Sitze wrote: ok, without going back to review exactly what I said in an earlier note, I had in mind something like: commons-logging-core.jar - core interface factory class, NO config commons-logging.jar- core + all helpers, NO config commons-logging-impl.jar - core + ONE helper, ONE config With this scheme, I believe we can scrub the code from LogFactory that looks for an attempts to load specific logger impls [Log4J, Avalon, ?], and instead depend entirely on the config. In commons-logging-impl.jar, I suppose by ONE helper, ONE config you mean the necessary wiring to let commons-logging know that it should use impl and skip automatic discovery. This simple and robust approach would probably alleviate many of the classloader problems users have been hitting. i'm in definitely agreement with craig's assessment (a long while ago) that one of the fundamental flaws with the current JCL is that we ship an unusable API distribution with runtime dependencies. as far as i'm concerned the only solution is to create a useable core API distribution with minimal portable configuration (system property only) and no discovery (except as required for backward compatibility in a combined distribution ie no classloader magic). upon configuration failure rather than throwing an exception, it should default to logging fatal and error messages to system.err. IIUC the helper performs discovery and only one discovery helper can be picked by the fundamental configuration mechanism. this would indeed allow solutions to be provided for most of the most common troublesome use cases. (apologies for prolonging the military metaphor.) i suspect that we might all be marching in the same direction now. am i correct? if so, then i do think it would work and i am confident that it can be done without breaking backwards compatibility. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
news [EMAIL PROTECTED] wrote on 12/27/2004 06:40:16 PM: I think often JCL will be used as you describe, but not always. Not always is of less concern. Matt, the PRIMARY focus of JCL is as Ceki described. There are no if/ands/buts about it. If you choose to use it in any other fashion, you are certainly welcome too. However, from a design standpoint, this one point is critical. We make decisions that direct the development of JCL on this point. For example, let's say I am developing a component that monitors database activity and monitors usage statistics (this is a hypothetical example). The main purpose of this component is to log messages to be processed later by a human. I use JCL and put a commons-logging.properties in my org.dbmonitor package that says use Log4J and display INFO and higher messages. This component may be deployed in many different environments. Here are two examples: 1) Standalone on a server. In this case, the default settings specified at the component level should be used. 2) As a component of another application. In this case, the overall application specifies logging properties that overwrite those in the component. To do this, the application specifies a commons-logging.properties in the default package, which overwrites the properties specified at the component level. In this example, the application chooses it only wants WARN and higher messages and that it wants the messages rendered with JDK 1.4 logging. My point is that one overall configuration of logging for the entire JVM may be too restrictive. I think we could benefit from multiple JCL configurations, each targeted at different parts of a system. Matt Ceki Gülcü wrote: Matt, JCL exists mainly for the purpose of libraries wishing to *integrate* with the logging API chosen by the user by deferring the selection of the logging impl to runtime. The author of library net.sf.morph probably does *not* wish to impose any logging related property on the end-user. Consequently, it does not make sense to have package specific properties at the JCL level. Would you agree? At 08:26 PM 12/27/2004, Matt Sgarlata wrote: Couldn't this be refined even further by incorporating a change to JCL I proposed earlier? Here's a copy of my original post: I have an idea... All logging implementations for Java configure logging by package, right? What if we allow component developers to include their own commons-logging.properties that's not at the root of the source tree? For example, if Morph suddenly decided it was very important to have certain messages logged, I just drop a commons-logging.properties in net.sf.morph that specifies the logging settings for net.sf.morph and all subpackages (e.g. which log factory to use, whether my messages *must* be heard, etc). If JCL detects such a file it ensure the component that the logging it specifies is happening. If an application developer, assembler or deployer decides later that Morph really isn't as important as I'd like, then they just delete the commons-logging.properties or put their own version in the WEB-INF/classes directory. (Forgive me if this is a great show of my ignorance of classloading, but I think this is at least how things work for Tomcat). Searching for a file like this on the classpath would certainly have performance implications. However, search cost is incurred only on startup and there is precedent (see below), so it can't be too bad. It's certainly worth a try. http://java.sun.com/j2se/1.4. 2/docs/api/java/beans/PropertyEditorManager.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Ceki Gülcü [EMAIL PROTECTED] wrote on 12/27/2004 05:31:23 PM:
At 2004-12-16 16:51:31, Richard Sitze wrote:
I do not advocate a fail-on-no-config or fail-on-ambiguous-config.
I advocate a *warn* or *error* on either, using the simple default
logger.
The warning will be visible on the console, which suffices for my
immediate concerns. How that warning/error (in general) is managed
is up
to the application environment.
Log4j 1.3 can use itself for its own logging. So, when appender A
fails, it can report errors using appender B. Appender B could alert the
system admin if that is the desired behavior.
The same goes for configuration errors which are also accessible
programmatically. For example,
Configurator c = new SomeLog4jConfigurator();
c.configure(some file);
List el = c.getErrorList();
if(el.size 0) {
if(analyzeErrors(el)) {
// errors during logging configuration
throw new IllegalStateException(Can't proceed withour logging);
}
}
boolean analyzeErrors(List el) {
// custom analysis of the errors go here
return true/false;
}
It seems to me that log4j already fulfills Richard's requirements wrt
logging errors and logging configuration.
It lends it's self well to this, but it's not sufficient. The requirement
is for this behavior to be exhibited by JCL, for example when Log4j is
configuted, but not available on the classpath.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
***
Richard A. Sitze
IBM WebSphere WebServices Development
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Richard, The commons-logging-impl.jar approach you suggested earlier will throw an exception if impl is not available which should be perfectly fine because if the user explicitly puts commons-logging-impl.jar in her classpath, then it means that she wants impl around. I quite like it. It lends it's self well to this, but it's not sufficient. The requirement is for this behavior to be exhibited by JCL, for example when Log4j is configuted, but not available on the classpath. -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
Charles Daniels [EMAIL PROTECTED] writes: -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Sunday, December 26, 2004 11:24 AM To: commons-dev@jakarta.apache.org Subject: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0? Simon et al. Log4j is slowly migrating to a model where there will be only a single log4j.jar installed per Application Server. This single copy will be installed under the ./common/lib or ./lib/ directories. See [1, 2, 3] for further details. Consider the case of single log4j.jar placed in ./common/lib, and two web-applications called 'A' and 'B' both built on top of Struts. Also assume that user of 'A' wishes to use JDK logging (j.u.l) whereas the user of application 'B' wishes to use log4j. Since Struts uses JCL, there is no way for user of application 'A' to direct the logs generated by Struts to go to j.u.l and at the same time to have Struts in application 'B' direct its logging output to log4j. (Setting the org.apache.commons.logging.LogFactory system property will not help because system properties are shared by all applications.) This simple example shows that the current JCL discovery mechanism will not always work as intended. If I understand the JCL discovery mechanism correctly, it actually should work just fine in the scenario you describe above. For it to Yep. Which once again shows, that using JCL in a component is a _good_ thing, even though Ceki will never cease to argue against it. :-) Regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
At 03:05 AM 12/27/2004, Charles Daniels wrote: If I understand the JCL discovery mechanism correctly, it actually should work just fine in the scenario you describe above. For it to work, you would not set the org.apache.commons.logging.LogFactory system property, because, as you pointed out, system properties are JVM-wide. Rather, for individual applications to use distinct underlying logging implementations, you can simply place a commons-logging.properties file in each application context (in WEB-INF/classes), setting the org.apache.commons.logging.LogFactory property as appropriate in each distinct commons-logging.properties file. Since these properties files will be loaded via distinct context class loaders, each application can use distinct logging implementations. Good point. This will require some understanding by the user about the classloader delegation mechanism used by the app server, which varies from vendor to vendor or even from version to version of an app server by the same vendor. Nevertheless, I stand corrected. -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
On Mon, 27 Dec 2004 12:49:45 +0100, Ceki Gülcü [EMAIL PROTECTED] wrote: At 03:05 AM 12/27/2004, Charles Daniels wrote: If I understand the JCL discovery mechanism correctly, it actually should work just fine in the scenario you describe above. For it to work, you would not set the org.apache.commons.logging.LogFactory system property, because, as you pointed out, system properties are JVM-wide. Rather, for individual applications to use distinct underlying logging implementations, you can simply place a commons-logging.properties file in each application context (in WEB-INF/classes), setting the org.apache.commons.logging.LogFactory property as appropriate in each distinct commons-logging.properties file. Since these properties files will be loaded via distinct context class loaders, each application can use distinct logging implementations. Good point. This will require some understanding by the user about the classloader delegation mechanism used by the app server, which varies from vendor to vendor or even from version to version of an app server by the same vendor. Nevertheless, I stand corrected. Given that making web applications self-contained, such that everything required by the app is incorporated in the war file, is a standard best practice, I don't think there will be that much of a need to educate people further with respect to class loader mechanisms in order to understand how to use logging properly. -- Martin Cooper -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
Ceki Gülcü [EMAIL PROTECTED] wrote on 12/27/2004 05:49:45 AM: At 03:05 AM 12/27/2004, Charles Daniels wrote: If I understand the JCL discovery mechanism correctly, it actually should work just fine in the scenario you describe above. For it to work, you would not set the org.apache.commons.logging.LogFactory system property, because, as you pointed out, system properties are JVM-wide. Rather, for individual applications to use distinct underlying logging implementations, you can simply place a commons-logging.properties file in each application context (in WEB-INF/classes), setting the org.apache.commons.logging.LogFactory property as appropriate in each distinct commons-logging.properties file. Since these properties files will be loaded via distinct context class loaders, each application can use distinct logging implementations. Good point. This will require some understanding by the user about the classloader delegation mechanism used by the app server, which varies from vendor to vendor or even from version to version of an app server by the same vendor. Nevertheless, I stand corrected. I wish :-( In fact, this works ONLY if JCL is *not* available in a common classloader higher up the hierarchy. In that case, the config file packaged in commons-logging.jar is found and used. If JCL *is* packaged as a shared library in a parent classloader, then the work around is typically a non-standard feature offered by some J2EE hosts, for switching the search order within the classloader hierarchy from parent first to parent last. This allows the config file packaged with the app to be located first. Part of the proposal for new discovery is to circumvent the classloader hierarchy [at a cost] and for picking up configs from the lowest point in the hierarchy. -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
Henning P. Schmiedehausen [EMAIL PROTECTED] wrote on 12/27/2004 02:57:45 AM: Charles Daniels [EMAIL PROTECTED] writes: -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Sunday, December 26, 2004 11:24 AM To: commons-dev@jakarta.apache.org Subject: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0? Simon et al. Log4j is slowly migrating to a model where there will be only a single log4j.jar installed per Application Server. This single copy will be installed under the ./common/lib or ./lib/ directories. See [1, 2, 3] for further details. Consider the case of single log4j.jar placed in ./common/lib, and two web-applications called 'A' and 'B' both built on top of Struts. Also assume that user of 'A' wishes to use JDK logging (j.u.l) whereas the user of application 'B' wishes to use log4j. Since Struts uses JCL, there is no way for user of application 'A' to direct the logs generated by Struts to go to j.u.l and at the same time to have Struts in application 'B' direct its logging output to log4j. (Setting the org.apache.commons.logging.LogFactory system property will not help because system properties are shared by all applications.) This simple example shows that the current JCL discovery mechanism will not always work as intended. If I understand the JCL discovery mechanism correctly, it actually should work just fine in the scenario you describe above. For it to Not to mention within a J2EE environment, you can bind properties [such as org.apache.commons.logging.LogFactory] to the ClassLoader. This has to be done by the J2EE application prior to any invocation of LogFactory, but it's do-able. Hmm not so sure this works in JCL, but it does with JCDiscovery. Yep. Which once again shows, that using JCL in a component is a _good_ thing, even though Ceki will never cease to argue against it. :-) Humor aside, Ceki has taken a very reasonable view of JCL. Please, let's not incite to humor-wars here. Regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
On Mon, 27 Dec 2004 12:41:56 -0600, Richard Sitze [EMAIL PROTECTED] wrote: Ceki Gülcü [EMAIL PROTECTED] wrote on 12/27/2004 05:49:45 AM: At 03:05 AM 12/27/2004, Charles Daniels wrote: If I understand the JCL discovery mechanism correctly, it actually should work just fine in the scenario you describe above. For it to work, you would not set the org.apache.commons.logging.LogFactory system property, because, as you pointed out, system properties are JVM-wide. Rather, for individual applications to use distinct underlying logging implementations, you can simply place a commons-logging.properties file in each application context (in WEB-INF/classes), setting the org.apache.commons.logging.LogFactory property as appropriate in each distinct commons-logging.properties file. Since these properties files will be loaded via distinct context class loaders, each application can use distinct logging implementations. Good point. This will require some understanding by the user about the classloader delegation mechanism used by the app server, which varies from vendor to vendor or even from version to version of an app server by the same vendor. Nevertheless, I stand corrected. I wish :-( In fact, this works ONLY if JCL is *not* available in a common classloader higher up the hierarchy. In that case, the config file packaged in commons-logging.jar is found and used. If JCL *is* packaged as a shared library in a parent classloader, then the work around is typically a non-standard feature offered by some J2EE hosts, for switching the search order within the classloader hierarchy from parent first to parent last. This allows the config file packaged with the app to be located first. I think you have this backwards. The standard J2EE class loader lookup order is local first and then parents (i.e. parent last), as opposed to the standard Java 2 order, which is the reverse. The non-standard feature provided by some containers is to use the Java 2 order instead of the J2EE order. See: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html -- Martin Cooper Part of the proposal for new discovery is to circumvent the classloader hierarchy [at a cost] and for picking up configs from the lowest point in the hierarchy. -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
Ceki Gülcü wrote: At 03:05 AM 12/27/2004, Charles Daniels wrote: If I understand the JCL discovery mechanism correctly, it actually should work just fine in the scenario you describe above. For it to work, you would not set the org.apache.commons.logging.LogFactory system property, because, as you pointed out, system properties are JVM-wide. Rather, for individual applications to use distinct underlying logging implementations, you can simply place a commons-logging.properties file in each application context (in WEB-INF/classes), setting the org.apache.commons.logging.LogFactory property as appropriate in each distinct commons-logging.properties file. Since these properties files will be loaded via distinct context class loaders, each application can use distinct logging implementations. Good point. This will require some understanding by the user about the classloader delegation mechanism used by the app server, which varies from vendor to vendor or even from version to version of an app server by the same vendor. Nevertheless, I stand corrected. Couldn't this be refined even further by incorporating a change to JCL I proposed earlier? Here's a copy of my original post: I have an idea... All logging implementations for Java configure logging by package, right? What if we allow component developers to include their own commons-logging.properties that's not at the root of the source tree? For example, if Morph suddenly decided it was very important to have certain messages logged, I just drop a commons-logging.properties in net.sf.morph that specifies the logging settings for net.sf.morph and all subpackages (e.g. which log factory to use, whether my messages *must* be heard, etc). If JCL detects such a file it ensure the component that the logging it specifies is happening. If an application developer, assembler or deployer decides later that Morph really isn't as important as I'd like, then they just delete the commons-logging.properties or put their own version in the WEB-INF/classes directory. (Forgive me if this is a great show of my ignorance of classloading, but I think this is at least how things work for Tomcat). Searching for a file like this on the classpath would certainly have performance implications. However, search cost is incurred only on startup and there is precedent (see below), so it can't be too bad. It's certainly worth a try. http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditorManager.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
Martin Cooper [EMAIL PROTECTED] wrote on 12/27/2004 01:07:28 PM: On Mon, 27 Dec 2004 12:41:56 -0600, Richard Sitze [EMAIL PROTECTED] wrote: Ceki Gülcü [EMAIL PROTECTED] wrote on 12/27/2004 05:49:45 AM: At 03:05 AM 12/27/2004, Charles Daniels wrote: If I understand the JCL discovery mechanism correctly, it actually should work just fine in the scenario you describe above. For it to work, you would not set the org.apache.commons.logging.LogFactory system property, because, as you pointed out, system properties are JVM-wide. Rather, for individual applications to use distinct underlying logging implementations, you can simply place a commons-logging.properties file in each application context (in WEB-INF/classes), setting the org.apache.commons.logging.LogFactory property as appropriate in each distinct commons-logging.properties file. Since these properties files will be loaded via distinct context class loaders, each application can use distinct logging implementations. Good point. This will require some understanding by the user about the classloader delegation mechanism used by the app server, which varies from vendor to vendor or even from version to version of an app server by the same vendor. Nevertheless, I stand corrected. I wish :-( In fact, this works ONLY if JCL is *not* available in a common classloader higher up the hierarchy. In that case, the config file packaged in commons-logging.jar is found and used. If JCL *is* packaged as a shared library in a parent classloader, then the work around is typically a non-standard feature offered by some J2EE hosts, for switching the search order within the classloader hierarchy from parent first to parent last. This allows the config file packaged with the app to be located first. I think you have this backwards. The standard J2EE class loader lookup order is local first and then parents (i.e. parent last), as opposed to the standard Java 2 order, which is the reverse. The non-standard feature provided by some containers is to use the Java 2 order instead of the J2EE order. See: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html Excellent point. However, these are recommendations, not requirements. The problem, as described, is real enough. Also, more importantly, I tend to use J2EE to demonstrate the issues surrounding more sophisticated ClassLoader hierarchies, but it should never be assumed that it is the only one. We all agree that the problem is real enough in various environments. -- Martin Cooper Part of the proposal for new discovery is to circumvent the classloader hierarchy [at a cost] and for picking up configs from the lowest point in the hierarchy. -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
Matt, JCL exists mainly for the purpose of libraries wishing to *integrate* with the logging API chosen by the user by deferring the selection of the logging impl to runtime. The author of library net.sf.morph probably does *not* wish to impose any logging related property on the end-user. Consequently, it does not make sense to have package specific properties at the JCL level. Would you agree? At 08:26 PM 12/27/2004, Matt Sgarlata wrote: Couldn't this be refined even further by incorporating a change to JCL I proposed earlier? Here's a copy of my original post: I have an idea... All logging implementations for Java configure logging by package, right? What if we allow component developers to include their own commons-logging.properties that's not at the root of the source tree? For example, if Morph suddenly decided it was very important to have certain messages logged, I just drop a commons-logging.properties in net.sf.morph that specifies the logging settings for net.sf.morph and all subpackages (e.g. which log factory to use, whether my messages *must* be heard, etc). If JCL detects such a file it ensure the component that the logging it specifies is happening. If an application developer, assembler or deployer decides later that Morph really isn't as important as I'd like, then they just delete the commons-logging.properties or put their own version in the WEB-INF/classes directory. (Forgive me if this is a great show of my ignorance of classloading, but I think this is at least how things work for Tomcat). Searching for a file like this on the classpath would certainly have performance implications. However, search cost is incurred only on startup and there is precedent (see below), so it can't be too bad. It's certainly worth a try. http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditorManager.html -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
At 2004-12-16 16:51:31, Richard Sitze wrote:
I do not advocate a fail-on-no-config or fail-on-ambiguous-config.
I advocate a *warn* or *error* on either, using the simple default logger.
The warning will be visible on the console, which suffices for my
immediate concerns. How that warning/error (in general) is managed is up
to the application environment.
Log4j 1.3 can use itself for its own logging. So, when appender A
fails, it can report errors using appender B. Appender B could alert the
system admin if that is the desired behavior.
The same goes for configuration errors which are also accessible
programmatically. For example,
Configurator c = new SomeLog4jConfigurator();
c.configure(some file);
List el = c.getErrorList();
if(el.size 0) {
if(analyzeErrors(el)) {
// errors during logging configuration
throw new IllegalStateException(Can't proceed withour logging);
}
}
boolean analyzeErrors(List el) {
// custom analysis of the errors go here
return true/false;
}
It seems to me that log4j already fulfills Richard's requirements wrt
logging errors and logging configuration.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 2004-12-16 18:09:36, Richard Sitze wrote: ok, without going back to review exactly what I said in an earlier note, I had in mind something like: commons-logging-core.jar - core interface factory class, NO config commons-logging.jar- core + all helpers, NO config commons-logging-impl.jar - core + ONE helper, ONE config With this scheme, I believe we can scrub the code from LogFactory that looks for an attempts to load specific logger impls [Log4J, Avalon, ?], and instead depend entirely on the config. In commons-logging-impl.jar, I suppose by ONE helper, ONE config you mean the necessary wiring to let commons-logging know that it should use impl and skip automatic discovery. This simple and robust approach would probably alleviate many of the classloader problems users have been hitting. -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
I think often JCL will be used as you describe, but not always. For example, let's say I am developing a component that monitors database activity and monitors usage statistics (this is a hypothetical example). The main purpose of this component is to log messages to be processed later by a human. I use JCL and put a commons-logging.properties in my org.dbmonitor package that says use Log4J and display INFO and higher messages. This component may be deployed in many different environments. Here are two examples: 1) Standalone on a server. In this case, the default settings specified at the component level should be used. 2) As a component of another application. In this case, the overall application specifies logging properties that overwrite those in the component. To do this, the application specifies a commons-logging.properties in the default package, which overwrites the properties specified at the component level. In this example, the application chooses it only wants WARN and higher messages and that it wants the messages rendered with JDK 1.4 logging. My point is that one overall configuration of logging for the entire JVM may be too restrictive. I think we could benefit from multiple JCL configurations, each targeted at different parts of a system. Matt Ceki Gülcü wrote: Matt, JCL exists mainly for the purpose of libraries wishing to *integrate* with the logging API chosen by the user by deferring the selection of the logging impl to runtime. The author of library net.sf.morph probably does *not* wish to impose any logging related property on the end-user. Consequently, it does not make sense to have package specific properties at the JCL level. Would you agree? At 08:26 PM 12/27/2004, Matt Sgarlata wrote: Couldn't this be refined even further by incorporating a change to JCL I proposed earlier? Here's a copy of my original post: I have an idea... All logging implementations for Java configure logging by package, right? What if we allow component developers to include their own commons-logging.properties that's not at the root of the source tree? For example, if Morph suddenly decided it was very important to have certain messages logged, I just drop a commons-logging.properties in net.sf.morph that specifies the logging settings for net.sf.morph and all subpackages (e.g. which log factory to use, whether my messages *must* be heard, etc). If JCL detects such a file it ensure the component that the logging it specifies is happening. If an application developer, assembler or deployer decides later that Morph really isn't as important as I'd like, then they just delete the commons-logging.properties or put their own version in the WEB-INF/classes directory. (Forgive me if this is a great show of my ignorance of classloading, but I think this is at least how things work for Tomcat). Searching for a file like this on the classpath would certainly have performance implications. However, search cost is incurred only on startup and there is precedent (see below), so it can't be too bad. It's certainly worth a try. http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditorManager.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
Simon et al. Log4j is slowly migrating to a model where there will be only a single log4j.jar installed per Application Server. This single copy will be installed under the ./common/lib or ./lib/ directories. See [1, 2, 3] for further details. Consider the case of single log4j.jar placed in ./common/lib, and two web-applications called 'A' and 'B' both built on top of Struts. Also assume that user of 'A' wishes to use JDK logging (j.u.l) whereas the user of application 'B' wishes to use log4j. Since Struts uses JCL, there is no way for user of application 'A' to direct the logs generated by Struts to go to j.u.l and at the same time to have Struts in application 'B' direct its logging output to log4j. (Setting the org.apache.commons.logging.LogFactory system property will not help because system properties are shared by all applications.) This simple example shows that the current JCL discovery mechanism will not always work as intended. [1] http://wiki.custine.com/display/ENV/Log4j+1.3+and+Tomcat5 [2] http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/tiny-webapp/ [3] http://www.qos.ch/logging/sc.jsp On 2004-12-10 0:29:15, Simon Kitching wrote: == discovery Regarding changes to the commons-log discovery process, I'm far less convinced. I personally like the fact that commons-logging works fine without any commons-logging-specific configuration. Essentially, a person deploying an application built with commons-logging doesn't need to know that commons-logging is used by the application. They just configure whatever logging library is available in the environment the application is being deployed into, and commons-logging auto-detects that library and uses it. -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
-Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Sunday, December 26, 2004 11:24 AM To: commons-dev@jakarta.apache.org Subject: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0? Simon et al. Log4j is slowly migrating to a model where there will be only a single log4j.jar installed per Application Server. This single copy will be installed under the ./common/lib or ./lib/ directories. See [1, 2, 3] for further details. Consider the case of single log4j.jar placed in ./common/lib, and two web-applications called 'A' and 'B' both built on top of Struts. Also assume that user of 'A' wishes to use JDK logging (j.u.l) whereas the user of application 'B' wishes to use log4j. Since Struts uses JCL, there is no way for user of application 'A' to direct the logs generated by Struts to go to j.u.l and at the same time to have Struts in application 'B' direct its logging output to log4j. (Setting the org.apache.commons.logging.LogFactory system property will not help because system properties are shared by all applications.) This simple example shows that the current JCL discovery mechanism will not always work as intended. If I understand the JCL discovery mechanism correctly, it actually should work just fine in the scenario you describe above. For it to work, you would not set the org.apache.commons.logging.LogFactory system property, because, as you pointed out, system properties are JVM-wide. Rather, for individual applications to use distinct underlying logging implementations, you can simply place a commons-logging.properties file in each application context (in WEB-INF/classes), setting the org.apache.commons.logging.LogFactory property as appropriate in each distinct commons-logging.properties file. Since these properties files will be loaded via distinct context class loaders, each application can use distinct logging implementations. [1] http://wiki.custine.com/display/ENV/Log4j+1.3+and+Tomcat5 [2] http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/tiny-webapp/ [3] http://www.qos.ch/logging/sc.jsp On 2004-12-10 0:29:15, Simon Kitching wrote: == discovery Regarding changes to the commons-log discovery process, I'm far less convinced. I personally like the fact that commons-logging works fine without any commons-logging-specific configuration. Essentially, a person deploying an application built with commons-logging doesn't need to know that commons-logging is used by the application. They just configure whatever logging library is available in the environment the application is being deployed into, and commons-logging auto-detects that library and uses it. -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT][logging] politics [WAS Re: [logging] Enterprise Common Logging... dare we say 2.0?]
At 11:56 PM 12/21/2004, robert burrell donkin wrote: FWIW AFAIK the committers who feel victimized are outside jakarta. IMHO committers who are vocally critical of the ASF (as an organization) are something about which the membership should be concerned. some of them simply have an obvious axe to grind but for others, a few humble and kind words were all would have been required. certainly, threats by members to communities (especially without adequate ASF representation) at a time such as this seems to play a little too much into their hands. i hope and trust that this wasn't the intent of your previous post. JCL shows indications of mission creep. I believe this to be a factual observation independent of ASF representation. (conversely, if you do think that JCL is out of scope for the commons or is at danger of becoming so - and that it's a big enough issue to consider things such as appealing to the members, then please tell me and i'd be glad to nominate you - and any other logging services pmc members who are interested - as committers for the commons and give you a free hand to sort out the problem as you best see fit. at least that way, myself and the rest of the JCL community will have a voice and some sort of vote. that would seem to me to be much more in the old apache spirit, at least as far as i can remember it...) Thank you for this offer. We need to consider it carefully and check whether we can participate in a meaningful manner. I am forwarding it to the LS PMC. - robert -- Ceki Gülcü - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT][logging] politics [WAS Re: [logging] Enterprise Common Logging... dare we say 2.0?]
Ceki Gülcü [EMAIL PROTECTED] wrote on 12/22/2004 04:53:49 AM: snip/ JCL shows indications of mission creep. I believe this to be a factual observation independent of ASF representation. Just to help clarify your concern, would you please define mission creep. (conversely, if you do think that JCL is out of scope for the commons or is at danger of becoming so - and that it's a big enough issue to consider things such as appealing to the members, then please tell me and i'd be glad to nominate you - and any other logging services pmc members who are interested - as committers for the commons and give you a free hand to sort out the problem as you best see fit. at least that way, myself and the rest of the JCL community will have a voice and some sort of vote. that would seem to me to be much more in the old apache spirit, at least as far as i can remember it...) Thank you for this offer. We need to consider it carefully and check whether we can participate in a meaningful manner. I am forwarding it to the LS PMC. Interesting indeed, not a bad idea. IMHO, any LS PMC member granted committer status on JCL needs a firm rational grasp on the distinctly different goals between JCL and Log4J. Ceki, I believe, understands this distinction well. I trust anyone else nominated for this role would understand and respect these differences as well. - robert -- Ceki Gülcü *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
robert burrell donkin [EMAIL PROTECTED] writes: the question i pose is: are we trying for a JCL 2.0 which in my mind would be a compatible evolution of JCL 1.0 aiming to solve all the major JCL 1.0 itches or are we aiming for a JCL 1.1 (better discover and factoring) plus additional pluggable modules...? Personally, I'd like to aim for 1.1. These goals are already a good step on the way to 2.0 and also address most of the PITAs (PsITA?) that we currently have. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 20 Dec 2004, at 23:13, Tim O'Brien wrote: Robert, we've got some issues to work through and infrastructure wants to wait until at least next week. Don't delay anything on account of the svn migration. From what I see, the transition should be seemless - just a few hours downtime. So, commit away. might have to set up branchs and stuff. there's no real rush so probably wiser to wait till after the migration. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
At 12:01 AM 12/21/2004, robert burrell donkin wrote: exactly (and that was the intended joke) I know. My response was intended for the rest of the group. ISTM it hasn't really started out so political this time (or did i miss it...) My comment about political vs. technical considerations was quite off topic. Please ignore it. - robert -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 21 Dec 2004, at 08:07, Henning P. Schmiedehausen wrote: robert burrell donkin [EMAIL PROTECTED] writes: the question i pose is: are we trying for a JCL 2.0 which in my mind would be a compatible evolution of JCL 1.0 aiming to solve all the major JCL 1.0 itches or are we aiming for a JCL 1.1 (better discover and factoring) plus additional pluggable modules...? Personally, I'd like to aim for 1.1. These goals are already a good step on the way to 2.0 and also address most of the PITAs (PsITA?) that we currently have. IMHO addressing all of richard's goals properly at once on a single track would mean aiming for a 2.0 release. i wouldn't be happy shipping a 1.1 based on the 1.0 code with the extras tacked on since many of the existing issues will simply be magnified. JCL has numerous users and critics so it's important that what we release is right. by aiming for a 1.1 release i mean evolution and modularity as opposed to a big bang. as soon as the repository has been converted, we would start a release process for 1.0.5 (the work done to plug memory leaks with Brian Stansberry is important) and then implement the discovery revisions. JCL 1.1 should feature just the improved, modular discovery and it should be possible quickly to start a release process for that release. we may wish to consider adopting a release process more similar to struts and tomcat. more modular discovery would allow the various parts of the proposal to be progressed either separately or as a unit (as appears best) without effecting the core. i suspect that the method tracing is more controversial in design terms but easy to implement whereas there are a lot of details about the i18n support which may need some work and thought. opinions? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 18 Dec 2004, at 23:07, Scott Deboy wrote: Enter and exit should not be defined as severities. This is useful information, but orthogonal to a logging event's severity attribute. One way to provide entry/exit information is to overload the logger methods to take a map, and require the user to adhere to use-case specific conventions for keys and values. For example, to track entry and exit as we cross component boundaries, these entries might be sufficient to identify an event: Key Name Value - boundary.type component boundary.stateentry Similarly, to track entry and exit as we cross class boundaries: Key Name Value - boundary.type class boundary.stateexit This provides a general mechanism for extending what information an event provides - without codifying use-case specific attributes as methods in commons-logging. Again, the user would be responsible for conforming to naming conventions for the map entries (possibly with the aid of helper methods to build the map) in order to discover these use-case specific events. interesting :) this is a classic component design dilemma: more specific, strongly contracted methods or fewer, more generic ones. i'm not really convinced either way as yet. JCL has benefitted from a compact, strongly contracted API and it would be good to keep it that way. IIRC ceki (in the past) convinced me (and probably a lot of others too) that there really isn't very much use in a plethura of logging levels. applications shouldn't really need anything much lower than debug. even for components, trace is more than a little debatable (though we went for it). a load of severities may look good in a policy document but are much less useful in practice and their usage patterns do not really generalize well. so, i don't really see the need for any more severities in JCL. richard's proposal to add symantic methods (rather than severities) is therefore interesting. exit and entry tracing is common. at the moment, this works rather poorly when JCP is used with log4j: most people log these at trace which is mapped to debug by the bridge. unfortunately, this has the effect of making debug level almost unusable. separate, symantically meaningful methods would have the advantage that the bridge will know enough to make better choices. (so, i'm a little unsure about this issue at the moment.) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
robert burrell donkin wrote: On 18 Dec 2004, at 23:07, Scott Deboy wrote: Enter and exit should not be defined as severities. This is useful information, but orthogonal to a logging event's severity attribute. Good point. I think this would be an excellent distinction for a logging implementation (e.g. Log4J to make). Until such a distinction is already implemented in an existing logging framework, I don't think JCL has any business doing work (i.e. - implementations! bad!) in this area. One way to provide entry/exit information is to overload the logger methods to take a map, and require the user to adhere to use-case specific conventions for keys and values. For example, to track entry and exit as we cross component boundaries, these entries might be sufficient to identify an event: Key Name Value - boundary.type component boundary.stateentry Similarly, to track entry and exit as we cross class boundaries: Key Name Value - boundary.type class boundary.stateexit This provides a general mechanism for extending what information an event provides - without codifying use-case specific attributes as methods in commons-logging. Again, the user would be responsible for conforming to naming conventions for the map entries (possibly with the aid of helper methods to build the map) in order to discover these use-case specific events. Again, something a logging implementation may decide is appropriate, but something I don't think sould be in JCL. interesting :) this is a classic component design dilemma: more specific, strongly contracted methods or fewer, more generic ones. i'm not really convinced either way as yet. JCL has benefitted from a compact, strongly contracted API and it would be good to keep it that way. IIRC ceki (in the past) convinced me (and probably a lot of others too) that there really isn't very much use in a plethura of logging levels. applications shouldn't really need anything much lower than debug. even for components, trace is more than a little debatable (though we went for it). a load of severities may look good in a policy document but are much less useful in practice and their usage patterns do not really generalize well. so, i don't really see the need for any more severities in JCL. +1, I agree with you and Ceki. TRACE is debatable (I personally like it), more than TRACE is silly. richard's proposal to add symantic methods (rather than severities) is therefore interesting. exit and entry tracing is common. at the moment, this works rather poorly when JCP is used with log4j: most people log these at trace which is mapped to debug by the bridge. unfortunately, this has the effect of making debug level almost unusable. separate, symantically meaningful methods would have the advantage that the bridge will know enough to make better choices. -0. This is moving JCL out of the realm of bridging logging APIs and into the realm of providing logging implementations. For Log4J, enter/exit methods will end up being mapped to Log4J's DEBUG level. This means that JCL will have to provide the implementation that converts the enter/exit calls into DEBUG calls with a specific format. What format should be used? Are we going to force one on users of Log4J or make it configurable? And if it's configurable, that stinks of JCL becoming a logging *implementation* rather than *bridge*. Yuck! If I was a committer (you're probably glad I'm not!) I would probably -1 the enter/exit methods. (so, i'm a little unsure about this issue at the moment.) - robert Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
robert burrell donkin [EMAIL PROTECTED] writes: On 21 Dec 2004, at 08:07, Henning P. Schmiedehausen wrote: robert burrell donkin [EMAIL PROTECTED] writes: the question i pose is: are we trying for a JCL 2.0 which in my mind would be a compatible evolution of JCL 1.0 aiming to solve all the major JCL 1.0 itches or are we aiming for a JCL 1.1 (better discover and factoring) plus additional pluggable modules...? Personally, I'd like to aim for 1.1. These goals are already a good step on the way to 2.0 and also address most of the PITAs (PsITA?) that we currently have. IMHO addressing all of richard's goals properly at once on a single track would mean aiming for a 2.0 release. i wouldn't be happy shipping a 1.1 based on the 1.0 code with the extras tacked on since many of the existing issues will simply be magnified. JCL has numerous users and critics so it's important that what we release is right. by aiming for a 1.1 release i mean evolution and modularity as opposed to a big bang. as soon as the repository has been converted, we would start a release process for 1.0.5 (the work done to plug memory leaks with Brian Stansberry is important) and then implement the discovery revisions. JCL 1.1 should feature just the improved, modular discovery and it should be possible quickly to start a release process for that release. we may wish to consider adopting a release process more similar to struts and tomcat. more modular discovery would allow the various parts of the proposal to be progressed either separately or as a unit (as appears best) without effecting the core. i suspect that the method tracing is more controversial in design terms but easy to implement whereas there are a lot of details about the i18n support which may need some work and thought. opinions? Sounds good, I like it. Especially with a brick like JCL, which is used under the hood in many places, it is important that we get this right. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
At 10:31 PM 12/20/2004, robert burrell donkin wrote: IIRC we're never really gone for official consultations here at apache (or at least the bits i've been involved with): too much committee, too little community. i alerted ceki (who i've know and respected for too many years even though we don't always agree) soon after i discovered this thread and hoped that other interested folks from the logging project. jakarta commons has a slightly different focus and expertise. we're more interested in bricks (small, compact reusable components with minimal dependencies) than logging systems. the extensions proposed by richard would allow components with enhanced logging requirements (such as i18nable messages) to be added to the commons. so, in many ways it doesn't matter whether existing logging systems offer these capabilities or not: what matters is whether there is a need for this kind of enhanced logging for the kind of bricks built by the jakarta commons. it's good people that logging experts have shown up to the party but (so long as a need for this exists), the party would have happened anyway. Official consultations at Apache might be a drag, but the last time I checked, Jakarta Commons was part of the Apache Software Foundation. It might not be a concern to this group, but keep in mind that the ASF frowns upon mission-creep. No doubt that your party would have happened without the participation of LS. Unfortunately, LS often gets stuck cleaning up after your party ends. - robert -- Ceki Gülcü, Chairman of Apache Logging Services - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Enterprise Common Logging... dare we say 2.0?
Semantic methods (other than severity) belong somewhere other than Log. Entry and exit (and other to-be-determined semantic methods) can be supported right now without changing commons-logging at all, by passing in a POJO or Map in as the event's message and relying on the enterprise logging framework to provide extension points in the event processing and mechanism for adding user-defined attributes to the logging event. Log4j can provide this support now. See MapFilter and ReflectionFilter: http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/log4j/varia/ I'm sure this is the exact opposite of what others had in mind - they'd like a stronger contract - but at least this gives folks something to look at and think about. Scott -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Tue 12/21/2004 5:39 AM To: Jakarta Commons Developers List Cc: Subject:Re: [logging] Enterprise Common Logging... dare we say 2.0? On 18 Dec 2004, at 23:07, Scott Deboy wrote: Enter and exit should not be defined as severities. This is useful information, but orthogonal to a logging event's severity attribute. One way to provide entry/exit information is to overload the logger methods to take a map, and require the user to adhere to use-case specific conventions for keys and values. For example, to track entry and exit as we cross component boundaries, these entries might be sufficient to identify an event: Key Name Value - boundary.type component boundary.stateentry Similarly, to track entry and exit as we cross class boundaries: Key Name Value - boundary.type class boundary.stateexit This provides a general mechanism for extending what information an event provides - without codifying use-case specific attributes as methods in commons-logging. Again, the user would be responsible for conforming to naming conventions for the map entries (possibly with the aid of helper methods to build the map) in order to discover these use-case specific events. interesting :) this is a classic component design dilemma: more specific, strongly contracted methods or fewer, more generic ones. i'm not really convinced either way as yet. JCL has benefitted from a compact, strongly contracted API and it would be good to keep it that way. IIRC ceki (in the past) convinced me (and probably a lot of others too) that there really isn't very much use in a plethura of logging levels. applications shouldn't really need anything much lower than debug. even for components, trace is more than a little debatable (though we went for it). a load of severities may look good in a policy document but are much less useful in practice and their usage patterns do not really generalize well. so, i don't really see the need for any more severities in JCL. richard's proposal to add symantic methods (rather than severities) is therefore interesting. exit and entry tracing is common. at the moment, this works rather poorly when JCP is used with log4j: most people log these at trace which is mapped to debug by the bridge. unfortunately, this has the effect of making debug level almost unusable. separate, symantically meaningful methods would have the advantage that the bridge will know enough to make better choices. (so, i'm a little unsure about this issue at the moment.) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
[mutters something about keeping OUR troups in line..] robert burrell donkin [EMAIL PROTECTED] wrote on 12/20/2004 04:03:28 PM: On 18 Dec 2004, at 20:52, Curt Arnold wrote: On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote: snip That a single log request can be rendered for more than one locale would either require having a localizable object passing through the logging dispatch system, being able to translate the log request at the appender or some other approach internal to the logging system. Constructing a message using resource bundles and passing a rendered message on to log4j logging would not accomplish that goal. We do not desire to pass on the rendered message, unless the underlying logger offers us no alternative. We desire to pass the messageID and parameters directly to the Logger, to be handled as it would. Again, I'm not sure what changes/problems you are arguing for? That is effectively issuing an architectural ultimatum to the logging implementations: be able to pass resource bundles and parameters through your processing pipeline or appear to be a second class implementation of Jakarta Commons Logging. (ceki - can't you keep your troops in line! ;) LOL! how the story has been rewritten in the last two years... we here in the commons are humble implementors of a simple (but yet too complex) thin (but too fat) bridging API. we are second class (we don't really provide any logging worth a damn): the logging system architects are the first class citizens. FWIW i have an idea that logging systems capable of supporting native thin wrapper implementations will actually be mostly used through the Log compatibility layer. If this is making architectural demands, it would be right to have the implementors feedback. though we are hoping not to make architectural demands, i think everyone here is glad to have your feedback. Absolutely. your points about the distinction between administrative and diagnostic logging interest me. it seems to me that diagnostic logging is less about the language that the log is written in and more about being able to correlate the message with the code that created the message. this suggests that knowledge of the key is much more critical than the message itself for diagnostic output. given a good key creation convention (org.apache.commons.bizarro[100], say). it might therefore be useful to be able to be able to render the key as part of the message (or even as the message). Can EASILY be managed by making the key part of your message text, in your resource. Documented as a best practice.. and yes, I can see all sorts of holes in this. TWO thoughts: 1. Configuration. We are NOT a logger, we don't want to be a logger, minimize configuration, etc. 2. Again, you are PRESUMING pre-translation of text before we hand off to the logger. 3. How the message is rended MUST be managed by the underlying logger implementation. 4. I'm coming around to the idea that for loggers that do NOT support translation, we could allow one to be plugged in. The scope must be across ALL components. The components must not presume, or be written to presume, any function/feature of these pluggable translators. Therefore I would maintain that the we should still focus on a resource bundle approach [properties file or class], so that we maintain portability across loggers/translators. A simple translator would be provided, but just as we do NOT want to get into the logging game, I maintain that we don't want to become the defacto clearing house for translation mechanisms. Those belong somewhere else. *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
news [EMAIL PROTECTED] wrote on 12/21/2004 08:04:09 AM: robert burrell donkin wrote: On 18 Dec 2004, at 23:07, Scott Deboy wrote: Enter and exit should not be defined as severities. This is useful information, but orthogonal to a logging event's severity attribute. Good point. I think this would be an excellent distinction for a logging implementation (e.g. Log4J to make). Until such a distinction is already implemented in an existing logging framework, I don't think JCL has any business doing work (i.e. - implementations! bad!) in this area. This distinction IS made in some frameworks. It's made in the JSR-47 f/w implicitly by it's description of the finer level. There are others I'm familiar with that support these types of methods explicitly, though in different forms that what the proposal contains. One way to provide entry/exit information is to overload the logger methods to take a map, and require the user to adhere to use-case specific conventions for keys and values. For example, to track entry and exit as we cross component boundaries, these entries might be sufficient to identify an event: Key Name Value - boundary.type component boundary.stateentry Similarly, to track entry and exit as we cross class boundaries: Key Name Value - boundary.type class boundary.stateexit This provides a general mechanism for extending what information an event provides - without codifying use-case specific attributes as methods in commons-logging. Again, the user would be responsible for conforming to naming conventions for the map entries (possibly with the aid of helper methods to build the map) in order to discover these use-case specific events. Again, something a logging implementation may decide is appropriate, but something I don't think sould be in JCL. Absolutely agree. It is interesting, but WAY to fat. interesting :) this is a classic component design dilemma: more specific, strongly contracted methods or fewer, more generic ones. i'm not really convinced either way as yet. JCL has benefitted from a compact, strongly contracted API and it would be good to keep it that way. IIRC ceki (in the past) convinced me (and probably a lot of others too) that there really isn't very much use in a plethura of logging levels. applications shouldn't really need anything much lower than debug. even for components, trace is more than a little debatable (though we went for it). a load of severities may look good in a policy document but are much less useful in practice and their usage patterns do not really generalize well. so, i don't really see the need for any more severities in JCL. +1, I agree with you and Ceki. TRACE is debatable (I personally like it), more than TRACE is silly. Well... call them what you will, I want em'!! lol And yes, I'm leaning towards EXPLICITLY naming methods to encourage best practices. To use the distinction made by Curt, I'm pushing the trace level methods towards diagnostic logger function, and stepping away from other uses entirely. I'm going to refrain from doing a full brain dump on all the fun thoughts now running through my head... [separating trace level methods and messaging/admin level methods into seperate interfaces.. ok I lied]. 3 levels stand out clearly to me: component level tracing [flow] - particularly useful in a larger system class level tracing [flow] additional detail richard's proposal to add symantic methods (rather than severities) is therefore interesting. exit and entry tracing is common. at the moment, this works rather poorly when JCP is used with log4j: most people log these at trace which is mapped to debug by the bridge. unfortunately, this has the effect of making debug level almost unusable. separate, symantically meaningful methods would have the advantage that the bridge will know enough to make better choices. -0. This is moving JCL out of the realm of bridging logging APIs and into the realm of providing logging implementations. For Log4J, enter/exit methods will end up being mapped to Log4J's DEBUG level. This means that JCL will have to provide the implementation that converts the enter/exit calls into DEBUG calls with a specific format. This is what the thin wrapper DOES. Not sure I understand your issue. What format should be used? Are we going to force one on users of Log4J We should adopt a helper method to do such formatting, and use it [common] across all components to standardize this as much as possible. Where logger impls support such, we pass as much as makes sense straight through. Let's not get hung up on formatting issues, the POINT is to capture information, enable the developers, etc. or make it configurable? And if it's configurable,
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Regarding coding, I do have someone here who is champing at the bit to start submitting code to me, for checkin. Not to say others cannot, just that before you put any of your own time into this, know that there are other resources being made available. I do think we can start teasing some elements of this apart, and dropping prototype code in the near future. If nothing else, it would be good to have something to poke at. When we do get to that point, would suggest a seperate directory in the CVS repository. Finally, regarding version numbers. I'm willing to not make that call yet, see where we end up, and call it what it is in the end. ras *** Richard A. Sitze IBM WebSphere WebServices Development robert burrell donkin [EMAIL PROTECTED] wrote on 12/20/2004 04:13:56 PM: On 18 Dec 2004, at 20:52, Curt Arnold wrote: On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote: snip We ARE assuming that maintaining SOME SIGNIFICANT compatibility with the existing JCL is of paramount importance. We are NOT trying to standardize on some other API within the industry, but rather to evolve an existing standard with new function. The API's are based *functionally* on JSR-47 and other logging implementations. It's fair to say that there is more than a little experience being brought to bear on this effort within the Jakarta community. Again, I'm coming into this late. Is there a requirements doc of some sort other than what was in this thread, have there been any votes, anything in CVS, any timeline? there was a vote but i think it was a little premature. certainly, there's been no pressure to conclude it and it seems to me that the present consensus is that more talk and thought is needed. commons appears to be in the process of migrating to subversion. i feel an urge to code but it'd be better to take a branch or three to further the discussion in code. so for the moment, i don't think we'll see any commits for a while yet. certainly, i wouldn't feel comfortable with any as yet. personally speaking, i think that refactoring the discovery process is a pre-requisite to firming up the design. i have seen too much discussion on that yet so maybe we're still a little way off... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 21 Dec 2004, at 15:05, Ceki Gülcü wrote: At 10:31 PM 12/20/2004, robert burrell donkin wrote: IIRC we're never really gone for official consultations here at apache (or at least the bits i've been involved with): too much committee, too little community. i alerted ceki (who i've know and respected for too many years even though we don't always agree) soon after i discovered this thread and hoped that other interested folks from the logging project. jakarta commons has a slightly different focus and expertise. we're more interested in bricks (small, compact reusable components with minimal dependencies) than logging systems. the extensions proposed by richard would allow components with enhanced logging requirements (such as i18nable messages) to be added to the commons. so, in many ways it doesn't matter whether existing logging systems offer these capabilities or not: what matters is whether there is a need for this kind of enhanced logging for the kind of bricks built by the jakarta commons. it's good people that logging experts have shown up to the party but (so long as a need for this exists), the party would have happened anyway. Official consultations at Apache might be a drag, but the last time I checked, Jakarta Commons was part of the Apache Software Foundation. It might not be a concern to this group, but keep in mind that the ASF frowns upon mission-creep. now it's getting political :( in many ways, i'd prefer to take your original advice and keep things technical: scope can be considered later. not a single line of code has been committed and no binding decisions have been taken. i agree with noel that we should address the technical issues first. (i'm now probably going to start preaching to the gallery since you're probably already well aware of my views. those who are uninterested in politics should stop reading now.) i'm very aware (maybe more than most) that the ASF has been frowning very strongly at jakarta (in general) and commons (in particular) for several years. we are very vunerable (both jakarta and commons) because we have (proportionally) very few members and so very few advocates at the ASF level but this awareness has also produced some strengths: we are very aware of issues of scope and aware that we are under scrutiny from the board and members. we have no voice and so the only way we can demonstrate that the commons is worthwhile is by our actions. we take scope seriously (many would argue: too seriously). we take our legal duties very seriously. so far, we've managed this whilst retaining a sense of community. i feel this is an achievement. though at some times it feels like we committers are becoming second class citizens in the ASF community, the board (whatever some people say) has proved time and again that it still believes in communities and committers. here in the commons, we have a healthy community and that matters. so, all things being equal, having the disapproval of the logging project really isn't something that worries me at all providing that the decisions taken are right ones for the community. community is the primary measure against which scope should be judged. JCL deals with the particular logging needs of bricks. it is therefore in scope for both the jakarta commons (which deals with bricks) and the logging project (which deals with logging). the community is here which is why JCL elected to stay. IIRC there were no questions raise by members or the board about the decision of the community on this matter. No doubt that your party would have happened without the participation of LS. Unfortunately, LS often gets stuck cleaning up after your party ends. matters of scope are less important than matters of community. if strong community backing emerges then the scope issues can easily be solved. if no community emerges then matters of scope will become irrelevant. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] roadmap? [WAS Re: [logging] Enterprise Common Logging... dare we say 2.0?]
(shifting towards a more appropriate subject) On 21 Dec 2004, at 14:19, Henning P. Schmiedehausen wrote: robert burrell donkin [EMAIL PROTECTED] writes: On 21 Dec 2004, at 08:07, Henning P. Schmiedehausen wrote: robert burrell donkin [EMAIL PROTECTED] writes: the question i pose is: are we trying for a JCL 2.0 which in my mind would be a compatible evolution of JCL 1.0 aiming to solve all the major JCL 1.0 itches or are we aiming for a JCL 1.1 (better discover and factoring) plus additional pluggable modules...? Personally, I'd like to aim for 1.1. These goals are already a good step on the way to 2.0 and also address most of the PITAs (PsITA?) that we currently have. IMHO addressing all of richard's goals properly at once on a single track would mean aiming for a 2.0 release. i wouldn't be happy shipping a 1.1 based on the 1.0 code with the extras tacked on since many of the existing issues will simply be magnified. JCL has numerous users and critics so it's important that what we release is right. by aiming for a 1.1 release i mean evolution and modularity as opposed to a big bang. as soon as the repository has been converted, we would start a release process for 1.0.5 (the work done to plug memory leaks with Brian Stansberry is important) and then implement the discovery revisions. JCL 1.1 should feature just the improved, modular discovery and it should be possible quickly to start a release process for that release. we may wish to consider adopting a release process more similar to struts and tomcat. more modular discovery would allow the various parts of the proposal to be progressed either separately or as a unit (as appears best) without effecting the core. i suspect that the method tracing is more controversial in design terms but easy to implement whereas there are a lot of details about the i18n support which may need some work and thought. opinions? Sounds good, I like it. Especially with a brick like JCL, which is used under the hood in many places, it is important that we get this right. i can pull some stuff together on the wiki if people are in agreement with this general approach. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 21 Dec 2004, at 14:04, Matt Sgarlata wrote: robert burrell donkin wrote: snip richard's proposal to add symantic methods (rather than severities) is therefore interesting. exit and entry tracing is common. at the moment, this works rather poorly when JCP is used with log4j: most people log these at trace which is mapped to debug by the bridge. unfortunately, this has the effect of making debug level almost unusable. separate, symantically meaningful methods would have the advantage that the bridge will know enough to make better choices. -0. This is moving JCL out of the realm of bridging logging APIs and into the realm of providing logging implementations. For Log4J, enter/exit methods will end up being mapped to Log4J's DEBUG level. This means that JCL will have to provide the implementation that converts the enter/exit calls into DEBUG calls with a specific format. What format should be used? Are we going to force one on users of Log4J or make it configurable? And if it's configurable, that stinks of JCL becoming a logging *implementation* rather than *bridge*. Yuck! If I was a committer (you're probably glad I'm not!) I would probably -1 the enter/exit methods. this one is an interesting dilemma. it's pretty obvious to me that some standard implementations beyond a simple bridge are going to be required for the proposal. for the moment, i'm more interested in the technical issues rather than the issue of scope. many (most?) of the extensions to commons logging under consideration extend the scope of JCL. where this (hypothetical) code ends up packaged is another matter: if JCL becomes a compact API plus extensions (some optional, some standard; some libraries, some byte-code manipulators) then that's the stage when the commons (probably collectively) will need to think about organization and scope. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Comments below... robert burrell donkin wrote: On 21 Dec 2004, at 14:04, Matt Sgarlata wrote: robert burrell donkin wrote: snip richard's proposal to add symantic methods (rather than severities) is therefore interesting. exit and entry tracing is common. at the moment, this works rather poorly when JCP is used with log4j: most people log these at trace which is mapped to debug by the bridge. unfortunately, this has the effect of making debug level almost unusable. separate, symantically meaningful methods would have the advantage that the bridge will know enough to make better choices. -0. This is moving JCL out of the realm of bridging logging APIs and into the realm of providing logging implementations. For Log4J, enter/exit methods will end up being mapped to Log4J's DEBUG level. This means that JCL will have to provide the implementation that converts the enter/exit calls into DEBUG calls with a specific format. What format should be used? Are we going to force one on users of Log4J or make it configurable? And if it's configurable, that stinks of JCL becoming a logging *implementation* rather than *bridge*. Yuck! If I was a committer (you're probably glad I'm not!) I would probably -1 the enter/exit methods. this one is an interesting dilemma. it's pretty obvious to me that some standard implementations beyond a simple bridge are going to be required for the proposal. It's not obvious to me though... what implementations would JCL need to provide? Even if we introduce our own MessageSource interface similar to Spring's (which I've seen some other people in recent posts seem to be in favor of), that is only defining an interface, not an implementation. If we choose to fall back to java.util.ResourceBundle functionality when there is no MessageSource implementation to be found, we are once again simply bridging functionality that is already written. That is, the default MessageSource is implemented by java.util.ResourceBundle and we've kept JCL free of implementations. If you're talking about the discovery stuff, well, that's over my head. But assuming for a moment that this did require JCL to do some implementation-type things for discovery, that doesn't mean that JCL should be given a free ticket to move away from being a bridge for all of the JCL, including functionality like enter/exit methods that are completely orthogonal to the discovery process! for the moment, i'm more interested in the technical issues rather than the issue of scope. many (most?) of the extensions to commons logging under consideration extend the scope of JCL. where this (hypothetical) code ends up packaged is another matter: if JCL becomes a compact API plus extensions (some optional, some standard; some libraries, some byte-code manipulators) then that's the stage when the commons (probably collectively) will need to think about organization and scope. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Richard Sitze wrote: news [EMAIL PROTECTED] wrote on 12/21/2004 08:04:09 AM: +1, I agree with you and Ceki. TRACE is debatable (I personally like it), more than TRACE is silly. Well... call them what you will, I want em'!! lol Does this mean you want all 42 logging levels I described in my previous post, including the TINY, SUPERTINY, VERYTINY, EXTREMLYTINY, TINIEST, and SPLITTINGHAIRS logging levels I mentioned in a previous post? Just kidding! That was a joke, please don't flame me because of it :) And yes, I'm leaning towards EXPLICITLY naming methods to encourage best practices. To use the distinction made by Curt, I'm pushing the trace level methods towards diagnostic logger function, and stepping away from other uses entirely. I'm going to refrain from doing a full brain dump on all the fun thoughts now running through my head... [separating trace level methods and messaging/admin level methods into seperate interfaces.. ok I lied]. OK, I'm being serious again. I think there are two problems with best practices: (1) they change and (2) they are in the eye of the beholder. Nothing can be deemed best without making a value judgement, which means that reasonable people can disagreee as to what is the best practice. Bringing this back to the situation at hand, you think enter/exit are best practices, I think they're as useful as the SUPERTINY log level. But let's not take my word for it. Consider that Log4J doesn't include enter/exit and it is the pioneer logging framework that's still going strong despite an attempt to hijack its charter by including logging in the Java language itself. This leads me to believe your argument that enter/exit is a best practice is debatable at best :) 3 levels stand out clearly to me: component level tracing [flow] - particularly useful in a larger system class level tracing [flow] additional detail I still don't understand this distinction, but I am comfortable taking your word for it that this is very important. It would probably be a great feature for Log4J instead of JCL :) richard's proposal to add symantic methods (rather than severities) is therefore interesting. exit and entry tracing is common. at the moment, this works rather poorly when JCP is used with log4j: most people log these at trace which is mapped to debug by the bridge. unfortunately, this has the effect of making debug level almost unusable. separate, symantically meaningful methods would have the advantage that the bridge will know enough to make better choices. -0. This is moving JCL out of the realm of bridging logging APIs and into the realm of providing logging implementations. For Log4J, enter/exit methods will end up being mapped to Log4J's DEBUG level. This means that JCL will have to provide the implementation that converts the enter/exit calls into DEBUG calls with a specific format. This is what the thin wrapper DOES. Not sure I understand your issue. What format should be used? Are we going to force one on users of Log4J We should adopt a helper method to do such formatting, and use it [common] across all components to standardize this as much as possible. Where logger impls support such, we pass as much as makes sense straight through. Let's not get hung up on formatting issues, the POINT is to capture information, enable the developers, etc. or make it configurable? And if it's configurable, that stinks of JCL becoming a logging *implementation* rather than *bridge*. Yuck! If I was a committer (you're probably glad I'm not!) I would probably -1 the enter/exit methods. No problem, I'd just keep beating at your arguments until my last dying breath. ;-) Hehe that worked on me last time :) I think it won't this time though! (so, i'm a little unsure about this issue at the moment.) - robert Matt *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
At 07:51 PM 12/21/2004, robert burrell donkin wrote: now it's getting political :( Your comments about the optionality of consultations elicited my political response. Many ASF members were involved with Apache at one point or another. Moreover, Jakarta has quite a few influential, I dare say, very influential, members. Thus, it is not easy to emphasize with the sense of victimization shared by some Jakarta committers. If proportionally too few Jakarta committers are ASF members, which I honestly doubt to be the case, what is keeping existing Jakarta members from increasing their own representation? matters of scope are less important than matters of community. if strong community backing emerges then the scope issues can easily be solved. if no community emerges then matters of scope will become irrelevant. It all depends on how you define community. By community do you mean Jakarta Commons, Jakarta or the rest of the ASF? - robert -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
news [EMAIL PROTECTED] wrote on 12/21/2004 02:01:07 PM: snip/ And yes, I'm leaning towards EXPLICITLY naming methods to encourage best practices. To use the distinction made by Curt, I'm pushing the trace level methods towards diagnostic logger function, and stepping away from other uses entirely. I'm going to refrain from doing a full brain dump on all the fun thoughts now running through my head... [separating trace level methods and messaging/admin level methods into seperate interfaces.. ok I lied]. OK, I'm being serious again. I think there are two problems with best practices: (1) they change and (2) they are in the eye of the beholder. Nothing can be deemed best without making a value judgement, which means that reasonable people can disagreee as to what is the best practice. Agreed. Looking for balance, there are some things that are more clear than others. Bringing this back to the situation at hand, you think enter/exit are best practices, I think they're as useful as the SUPERTINY log level. But let's not take my word for it. Consider that Log4J doesn't include enter/exit and it is the pioneer logging framework that's still going strong despite an attempt to hijack its charter by including logging in the Java language itself. This leads me to believe your argument that enter/exit is a best practice is debatable at best :) 3 levels stand out clearly to me: component level tracing [flow] - particularly useful in a larger system I want to turn on logging that tracks component boundries. When I enter my component [or robert's brick], and when I leave it. Perhaps log data exchanged across the boundry. class level tracing [flow] Ok, now that I'm IN my component, I want to track the flow between objects / methods. Again, data exchanged on method invocation / return. This corresponds to the proposed enter/exit. I'm agreeing with comments by others, in that [generally] I don't want to log just any old thing here, but I for loggers that do support multiple log levels, would be useful to have this without the next level down.. additional detail Capture details on internal data, track low level flow if desired... everything else. I still don't understand this distinction, but I am comfortable taking your word for it that this is very important. It would probably be a great feature for Log4J instead of JCL :) richard's proposal to add symantic methods (rather than severities) is therefore interesting. exit and entry tracing is common. at the moment, this works rather poorly when JCP is used with log4j: most people log these at trace which is mapped to debug by the bridge. unfortunately, this has the effect of making debug level almost unusable. separate, symantically meaningful methods would have the advantage that the bridge will know enough to make better choices. -0. This is moving JCL out of the realm of bridging logging APIs and into the realm of providing logging implementations. For Log4J, enter/exit methods will end up being mapped to Log4J's DEBUG level. This means that JCL will have to provide the implementation that converts the enter/exit calls into DEBUG calls with a specific format. This is what the thin wrapper DOES. Not sure I understand your issue. What format should be used? Are we going to force one on users of Log4J We should adopt a helper method to do such formatting, and use it [common] across all components to standardize this as much as possible. Where logger impls support such, we pass as much as makes sense straight through. Let's not get hung up on formatting issues, the POINT is to capture information, enable the developers, etc. or make it configurable? And if it's configurable, that stinks of JCL becoming a logging *implementation* rather than *bridge*. Yuck! If I was a committer (you're probably glad I'm not!) I would probably -1 the enter/exit methods. No problem, I'd just keep beating at your arguments until my last dying breath. ;-) Hehe that worked on me last time :) I think it won't this time though! I'm not done yet :) *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT][logging] politics [WAS Re: [logging] Enterprise Common Logging... dare we say 2.0?]
On 21 Dec 2004, at 20:24, Ceki Gülcü wrote: At 07:51 PM 12/21/2004, robert burrell donkin wrote: now it's getting political :( Your comments about the optionality of consultations elicited my political response. i've given up politics. (feel free to reply to my missive but please spend some time creating some worthwhile since i have no intention of posting any more replies to this thread. the only reason i've created a reply is that i suspect there may have been some misunderstanding of the points i wished to make early.) Many ASF members were involved with Apache at one point or another. Moreover, Jakarta has quite a few influential, I dare say, very influential, members. Thus, it is not easy to emphasize with the sense of victimization shared by some Jakarta committers. i wasn't trying to suggest that jakarta committers are victims, just that it's another symptom of the problems which the ASF has with jakarta. FWIW AFAIK the committers who feel victimized are outside jakarta. IMHO committers who are vocally critical of the ASF (as an organization) are something about which the membership should be concerned. some of them simply have an obvious axe to grind but for others, a few humble and kind words were all would have been required. certainly, threats by members to communities (especially without adequate ASF representation) at a time such as this seems to play a little too much into their hands. i hope and trust that this wasn't the intent of your previous post. (conversely, if you do think that JCL is out of scope for the commons or is at danger of becoming so - and that it's a big enough issue to consider things such as appealing to the members, then please tell me and i'd be glad to nominate you - and any other logging services pmc members who are interested - as committers for the commons and give you a free hand to sort out the problem as you best see fit. at least that way, myself and the rest of the JCL community will have a voice and some sort of vote. that would seem to me to be much more in the old apache spirit, at least as far as i can remember it...) If proportionally too few Jakarta committers are ASF members, which I honestly doubt to be the case, this one came up a while ago (IIRC greg stein raised the demography problem as one of the issues with jakarta). proportionally, there are/were too many committers, not enough pmc members and too few members. jakarta is addressing the first (sub-projects moving to TLP status) and the second. the third can be addressed by the members only. i can appreciate why the membership has grown in the way though i had hoped for a little more understanding that this situation is of the member's own making. what is keeping existing Jakarta members from increasing their own representation? we both know that the majority of jakarta members (yourself, for example) are actually now primarily involved with top level projects outside jakarta. even our chair isn't a member. the membership grows organically. FWIW i'm actually happy that there isn't a jakarta faction amongst the membership pushing jakarta committers forward: it's healthy. it's good that the membership cares more for the ASF than any particular project. what isn't so good is that they've done a bad job over the last few months in appearing to care about the committers and communities which create the code. i am quite sure that this isn't true but i do think there's a danger that this perceived gap may become a destructive gulf in the future. so please let's not start that particular war here... matters of scope are less important than matters of community. if strong community backing emerges then the scope issues can easily be solved. if no community emerges then matters of scope will become irrelevant. It all depends on how you define community. By community do you mean Jakarta Commons, Jakarta or the rest of the ASF? community in the usual apache sense of the word. (or possibly: in the old apache sense of the word). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 18 Dec 2004, at 18:24, Richard Sitze wrote: Curt Arnold [EMAIL PROTECTED] wrote on 12/16/2004 11:13:25 PM: On Dec 16, 2004, at 7:56 PM, Richard Sitze wrote: snip Some of advantages of this approach: no API change is necessary, diagnostic messages are still trivial to add and fast to process, each appender may have a different locale, localization has no cost for discarded messages, generic language (typically english) messages are available for messages that have not been translated (and likely most diagnostic messages would not be), does not require customized readers. It is reasonable to attempt to standardize a general enablement for I18N on the API level. Sure, you can roll your own. Sure, each component could roll it's own... Sure, we can duplicate this endlessly. Let's standardize this now. As long as this effort is only trying to define an abstraction layer to unify existing practice and implementations, I'm okay with it. If it is trying to standardize an API before implementations are available and without consultation with major implementations like the Logging Services Project, then I would be concerned. IIRC we're never really gone for official consultations here at apache (or at least the bits i've been involved with): too much committee, too little community. i alerted ceki (who i've know and respected for too many years even though we don't always agree) soon after i discovered this thread and hoped that other interested folks from the logging project. jakarta commons has a slightly different focus and expertise. we're more interested in bricks (small, compact reusable components with minimal dependencies) than logging systems. the extensions proposed by richard would allow components with enhanced logging requirements (such as i18nable messages) to be added to the commons. so, in many ways it doesn't matter whether existing logging systems offer these capabilities or not: what matters is whether there is a need for this kind of enhanced logging for the kind of bricks built by the jakarta commons. it's good people that logging experts have shown up to the party but (so long as a need for this exists), the party would have happened anyway. From reading the thread, I'm not sure what the effort is trying to do. We ARE assuming that maintaining SOME SIGNIFICANT compatibility with the existing JCL is of paramount importance. We are NOT trying to standardize on some other API within the industry, but rather to evolve an existing standard with new function. The API's are based *functionally* on JSR-47 and other logging implementations. It's fair to say that there is more than a little experience being brought to bear on this effort within the Jakarta community. i think that this is one of the crucial matters which hasn't really been totally bottomed out. IMHO enterprise commons logging it is technically feasible to added as a compatible extension to JCL. however, the proposal breaks down a little into a number of independent requests: i18nable logs; improved support for JSR-47; better discover and so on. in addition, there are a few other issues which are related which have been itches for quite a period (including improved support for frameworks, support for more varied environments and better packaging for distributables). the question i pose is: are we trying for a JCL 2.0 which in my mind would be a compatible evolution of JCL 1.0 aiming to solve all the major JCL 1.0 itches or are we aiming for a JCL 1.1 (better discover and factoring) plus additional pluggable modules...? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 18 Dec 2004, at 20:52, Curt Arnold wrote: On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote: snip That a single log request can be rendered for more than one locale would either require having a localizable object passing through the logging dispatch system, being able to translate the log request at the appender or some other approach internal to the logging system. Constructing a message using resource bundles and passing a rendered message on to log4j logging would not accomplish that goal. We do not desire to pass on the rendered message, unless the underlying logger offers us no alternative. We desire to pass the messageID and parameters directly to the Logger, to be handled as it would. Again, I'm not sure what changes/problems you are arguing for? That is effectively issuing an architectural ultimatum to the logging implementations: be able to pass resource bundles and parameters through your processing pipeline or appear to be a second class implementation of Jakarta Commons Logging. (ceki - can't you keep your troops in line! ;) LOL! how the story has been rewritten in the last two years... we here in the commons are humble implementors of a simple (but yet too complex) thin (but too fat) bridging API. we are second class (we don't really provide any logging worth a damn): the logging system architects are the first class citizens. FWIW i have an idea that logging systems capable of supporting native thin wrapper implementations will actually be mostly used through the Log compatibility layer. If this is making architectural demands, it would be right to have the implementors feedback. though we are hoping not to make architectural demands, i think everyone here is glad to have your feedback. your points about the distinction between administrative and diagnostic logging interest me. it seems to me that diagnostic logging is less about the language that the log is written in and more about being able to correlate the message with the code that created the message. this suggests that knowledge of the key is much more critical than the message itself for diagnostic output. given a good key creation convention (org.apache.commons.bizarro[100], say). it might therefore be useful to be able to be able to render the key as part of the message (or even as the message). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 18 Dec 2004, at 20:52, Curt Arnold wrote: On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote: snip We ARE assuming that maintaining SOME SIGNIFICANT compatibility with the existing JCL is of paramount importance. We are NOT trying to standardize on some other API within the industry, but rather to evolve an existing standard with new function. The API's are based *functionally* on JSR-47 and other logging implementations. It's fair to say that there is more than a little experience being brought to bear on this effort within the Jakarta community. Again, I'm coming into this late. Is there a requirements doc of some sort other than what was in this thread, have there been any votes, anything in CVS, any timeline? there was a vote but i think it was a little premature. certainly, there's been no pressure to conclude it and it seems to me that the present consensus is that more talk and thought is needed. commons appears to be in the process of migrating to subversion. i feel an urge to code but it'd be better to take a branch or three to further the discussion in code. so for the moment, i don't think we'll see any commits for a while yet. certainly, i wouldn't feel comfortable with any as yet. personally speaking, i think that refactoring the discovery process is a pre-requisite to firming up the design. i have seen too much discussion on that yet so maybe we're still a little way off... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
At 11:03 PM 12/20/2004, robert burrell donkin wrote: (ceki - can't you keep your troops in line! ;) I really don't have any troops marching at my orders. Those who are affiliated with Logging Services do not necessarily listen to me anyhow, let alone take any orders. They are all independently minded people who express their minds freely. We are extremely lucky to have them. (It doesn't always work out so well in other projects.) LOL! how the story has been rewritten in the last two years... What I find fascinating is the extent to which political considerations seem to outweigh technical considerations. - robert -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 20 Dec 2004, at 22:21, Ceki Gülcü wrote: At 11:03 PM 12/20/2004, robert burrell donkin wrote: (ceki - can't you keep your troops in line! ;) I really don't have any troops marching at my orders. Those who are affiliated with Logging Services do not necessarily listen to me anyhow, let alone take any orders. They are all independently minded people who express their minds freely. We are extremely lucky to have them. (It doesn't always work out so well in other projects.) exactly (and that was the intended joke) LOL! how the story has been rewritten in the last two years... What I find fascinating is the extent to which political considerations seem to outweigh technical considerations. ISTM it hasn't really started out so political this time (or did i miss it...) we certainly have a different agenda here in the commons but IMO that has more to do with technical matters such as how to make bricks that can fit... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Enterprise Common Logging... dare we say 2.0?
Robert, we've got some issues to work through and infrastructure wants to wait until at least next week. Don't delay anything on account of the svn migration. From what I see, the transition should be seemless - just a few hours downtime. So, commit away. Tim From: robert burrell donkin commons appears to be in the process of migrating to subversion. i feel an urge to code but it'd be better to take a branch or three to further the discussion in code. so for the moment, i don't think we'll see any commits for a while yet. certainly, i wouldn't feel comfortable with any as yet.
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Curt Arnold [EMAIL PROTECTED] wrote on 12/18/2004 02:52:02 PM: On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote: As you pointed out earlier, much of this depends on how the logger is used. Class category names for code logging, other application category logger names for the other would be a reasonable approach. However, for our stated *GOAL*, JCL's primary purpose is for instrumenting components that are expected to plug into larger applications/frameworks. It's not clear to me what it means to start instrumenting such components for administrative or application level logging events. Not to say it couldn't be done. This is a best-practice issue for the most part... something for the users guide. If there are specific issues to be addressed by the API's, please raise them? Examples? It's not clear to me what course of action you advocate. I was trying to give examples that the localized messages are not needed because the system is enterprise level or because the message is significant, but due to the audience and nature of the message. Agreed Enterprise level systems may have more messages that need to be localized, but that doesn't mean that non-enterprise level systems would not benefit. Agreed log4j and JSR-47 was designed and optimized for diagnostic logging, however they can be applied effectively for administrative logging. However when they do, there are some aspects (like localization) that may be lacking. However if I was designed a system that needed configurable routing of administrative messages, then I could do worse than using log4j or JSR-47 and working within their constraints or evolving them. Fair enough, but always remember to keep our primary goals in mind. There are a couple of issues with the resource bundle proposals that I have seen previously. I haven't had time to review those presented here so they may or may not apply. Resource bundle approaches are sufficiently demanding of developers that they will likely substantially reduce the density of diagnostic messages if only a resource bundle approach is available. What are our (simple) options. Again remember that we expect to be a thin-wrapper over existing log implementations. Depends on the requirements. All I have to go on is what was in the thread and there didn't seem to be a huge amount of elaboration. The requirements are all on the thread [archive], original post. There is probably a lot of historical discussion that establishes context, in the JCL community. Elaboration is coming through discussion, thank you for your comments. If the requirement is to support localization of logging messages, then there are multiple ways of attacking that problem. If the requirement is to provide a facade to mimic JSR-47's resource bundle approach, then that is very achievable, however I think it is likely to not be a deeply satisfactory solution to localizing logging messages without some accomodation in the implementations. The requirement is to enable localization of logging messages via a facade that maps to JSR-47 or other loggers that support localization underneath. Ideally to pass the localization info straight through to underlying implementations that support. You seem to be arguing against [pervious statements in your original post], and against [your new statements. What is your point? I am trying to say that the severity of the message is independent of the intended audience of the message and the need for localization. You can have an ERROR message targeted to a diagnostician that should be locale-neutral and a DEBUG message targeted to an administrator that needs to be localized. Ok, I can understand this... but would counter that a) you design to what the API's support. b) remember the target use: components. The primary purpose of trace level info is going to be diagnostic, and the intended audience would be the developer(s). Balance is key, there is no one right answer. If I was using a logging system to report, say employee status to a store manager, an employee arriving or leaving might be assigned an INFO status, i. e. lowest severity that is typically reported. If I was trying to diagnose a drop in productivity, I might want to be able to configure that I should get DEBUG severity events, like door swipes or cash register logins and I would still want these in my preferred language. Then the designer must be aware of the distinction between trace level logging, as intended for application debugging, and for message level logging. Everything you describe is message level logging. I think I'm starting to see where you are going with this... and would start by arguing that independent pluggable components are not necessarily the right place to start making assumptions of this sort, or even the right
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Curt Arnold [EMAIL PROTECTED] wrote on 12/18/2004 03:19:41 PM: On Dec 18, 2004, at 2:18 PM, Richard Sitze wrote: +1. Just because the JDK 1.4 log does this, doesn't mean that we have to enforce this behavior on all logging implementations. Why not just leave it generic? If someone wants enter/exit methods, they can define their own: public static void enter(Log log, Class clazz, String method); public static void exit(Log log, Class clazz, String method); The proposal is for more than a the simple helper methods, it is for the [potential] underlying implementation below. Where possible, these SHOULD be mapped to a finer level than 'debug', but not as fine as 'trace'. By naming them 'enter/exit' instead of 'finer', we encourage their use in a particular fashion... if you feel that such strong best-practice enforcement is inappropriate, then let's not throw the dog [and I know it's a dog ;)] out with the bath water. We'd like at least one more trace level, see below. Maybe the tension is a manifestation of the problem of trying to assign one common severity to entering and exiting messages. Some entries have to be more significant than others, the only mechanism to distinguish them in the JSR-47 is to not instrument the less significant entry points. Maybe adding a entering(Level level, String...) The JSR-47 adapter could map this the JSR's entering if level was the equivalent of FINER or lower and fabricate a similar message if the level were higher than finer. Interesting point. We're trying to NOT expose parameterized levels in JCL. Not to say that we can't, just that I expect heated discussion within the community ;) ras *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Hi Chris,
On Sat, 2004-12-18 at 11:32, Chris Lambrou wrote:
Someone suggested that for Log, it would be appropriate to make it an
abstract class rather than an interface, so we can make these kinds of
changes easier in the future.
That was me (inspired by Robert Donkin's enthusiasm for using abstract
classes rather than interfaces in digester).
I think the risks for this are low, and
probably better [less problems for the majority of users] than just adding
new methods to the existing interface. Other thoughts on this direction?
I think the risk of annoying quite a number of users by changing Log
from an interface to an abstract class is actually quite high. For sure,
one of the default logging implementations provided by JCL would
probably suffice for the majority. However, there are groups who will
have chosen, for whatever reason, to provide their own logging
implementations. I've certainly worked on a couple of projects where
this has been the case. One of them could probably cope with the change
relatively easiliy, but such a change could be a real pain for the
other. Whilst the proportion of JCL users in this situation is probably
quite small, in terms of actual numbers, such a change could cause quite
a lot of grief.
First, I was suggesting that instead of introducing a *new* *interface*
(Richard's proposal) to provide an extended API that a *new* *abstract
class* be introduced. Neither of us were proposing changing the existing
Log interface.
But if the Log interface were to be changed, then adding methods to it
would break binary compatibility. The most obvious way is that classes
that were previously valid implementations of the interface become
incomplete.
Suppose for a moment that we were to choose between adding methods to
the Log interface, and turning it into an abstract class with some
methods; I don't understand what real pain would be incurred by having
custom logging adapters be declared as:
public class FooLog extends Logger {...}
instead of the existing
public class FooLog implements Log {...}
Sure there would be some inconvenience, but wouldn't it be the same as
having to update the existing log implementation to add implementations
for the new methods added to a Log interface? Making this sort of change
would indeed annoy users as they couldn't used their existing
log-specific adapters with the new JCL release without modifying them.
But that would be the case even if the Log class remained an interface.
And once a move to using abstract classes has been made, we *can* extend
the API later without breaking binary compatibility as long as a
reasonable default implementation can be provided.
The only problem would be if someone had an adapter class that for some
reason needed to extend some other existing class. But I don't see why
that would happen for a logging adapter, and there are reasonable
workarounds for this anyway (eg using a trivial inner class).
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 17 Dec 2004, at 22:32, Chris Lambrou wrote: Someone suggested that for Log, it would be appropriate to make it an abstract class rather than an interface, so we can make these kinds of changes easier in the future. I think the risks for this are low, and probably better [less problems for the majority of users] than just adding new methods to the existing interface. Other thoughts on this direction? I think the risk of annoying quite a number of users by changing Log from an interface to an abstract class is actually quite high. For sure, one of the default logging implementations provided by JCL would probably suffice for the majority. However, there are groups who will have chosen, for whatever reason, to provide their own logging implementations. I've certainly worked on a couple of projects where this has been the case. One of them could probably cope with the change relatively easiliy, but such a change could be a real pain for the other. Whilst the proportion of JCL users in this situation is probably quite small, in terms of actual numbers, such a change could cause quite a lot of grief. i think that simon was suggesting the new logical interface proposed is implemented (in java) as an empty abstract class as opposed to a interface. this would allow new methods to be added without breaking compatibility but at the cost of preventing implementations belonging to another type hierarchy. does anyone think that there is any real need for implementations to belong to a second type hierarchy? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Simon Kitching wrote:
Suppose for a moment that we were to choose between adding methods to
the Log interface, and turning it into an abstract class with some
methods; I don't understand what real pain would be incurred by having
custom logging adapters be declared as:
The pain (as Robert pointed out) is that you preclude FooLog from
extending any other class. (More below)
public class FooLog extends Logger {...}
instead of the existing
public class FooLog implements Log {...}
Sure there would be some inconvenience, but wouldn't it be the same as
having to update the existing log implementation to add implementations
for the new methods added to a Log interface?
Ideally instead of changing the existing Log interface, any new methods
you want to add you introduce in a new interface (e.g. - EnterpriseLog).
If it's possible for EnterpriseLog to be implemented in terms of Log,
all the better: existing implementations can have an EnterpriseLog
exposed by using the Decorator pattern.
I really like this approach because it allows you to keep programming to
interfaces rather than classes. For example, let's say that I had my
own legacy CustomLogger that had some nice features I would like to keep
when I migrate to JCL. CustomLogger participates in its own type
hierarchy. All I have to do to integrate it with JCL is make it
implement the Log interface. If Log is an abstract class, I have to
take a sledgehammer to my CustomLogger to make it extend from Log and
delegate calls to a SledgeHammeredCustomLogger.
I took this approach in Morph and I think it works quite well. Users
only implement a simple Converter interface (similar to the one in
BeanUtils). I have a separate interface called DecoratedConverter that
exposes lots of extra methods that can all be implemented in terms of
the basic Converter interface. If someone wants to expose their
plain-old Converter as a DecoratedConverter, all they have to do is
DecoratedConverter decorated = new ConverterDecorator(converter). This
way, if I have an old Converter that participates in a type hierarchy
already (say one that I wrote for BeanUtils), I can easily plug it into
Morph by just implementing a new interface.
More below...
robert burrell donkin wrote:
does anyone think that there is any real need for implementations to
belong to a second type hierarchy?
I don't think it's a good idea to *preclude* logs from participating in
two different type hierarchies because it's hard to anticipate new use
cases.
But to answer your question, remember how Richard proposed that the
generation of exception messages be possible with Logs? Well I think
the community struck that idea down, but what if someone *did* decide
they wanted to combine that functionality with their logger. In that
case they would probably want to extend some type of message resolution
base class rather than being forced to extend a Log abstract class.
- robert
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Noel J. Bergman wrote: Simon Kitching wrote: I've been convinced by the arguments put forward in this thread that explicit enter/exit methods taking class+method strings should not be encouraged Actually, I agree. I'd prefer to see that semantic state encoded in the log message, which I feel is much cleaner. --- Noel +1. Just because the JDK 1.4 log does this, doesn't mean that we have to enforce this behavior on all logging implementations. Why not just leave it generic? If someone wants enter/exit methods, they can define their own: public static void enter(Log log, Class clazz, String method); public static void exit(Log log, Class clazz, String method); Personally, I am against introducing logging that is more specific than TRACE. In practice, I think it's hard to explain even the distinction between TRACE and DEBUG (i.e. - the projects I've seen tend to use one or the other almost exclusively if they're not using INFO or higher for the message). Again, just because JDK 1.4 offers FINEST, FINER doesn't mean JCL has to. What happens when the next implementation comes along that offers 42 different logging levels, including TINY, VERYTINY, EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels? Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
At 05:44 PM 12/18/2004, Matt Sgarlata wrote: Noel J. Bergman wrote: Actually, I agree. I'd prefer to see that semantic state encoded in the log message, which I feel is much cleaner. --- Noel +1. Just because the JDK 1.4 log does this, doesn't mean that we have to enforce this behavior on all logging implementations. Why not just leave it generic? If someone wants enter/exit methods, they can define their own: public static void enter(Log log, Class clazz, String method); public static void exit(Log log, Class clazz, String method); Personally, I am against introducing logging that is more specific than TRACE. In practice, I think it's hard to explain even the distinction between TRACE and DEBUG (i.e. - the projects I've seen tend to use one or the other almost exclusively if they're not using INFO or higher for the message). Again, just because JDK 1.4 offers FINEST, FINER doesn't mean JCL has to. What happens when the next implementation comes along that offers 42 different logging levels, including TINY, VERYTINY, EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels? Log4j version 1.4 or 2.0 is likely to introduce the notion of multiple domains for categorizing logging statements. When that happens, the notion of logging levels will be looked at very differently. Commons-logging promises to abstract different logging APIs such as log4j, Avalon logkit and java.util.logging API. However, such a task is near impossible to fulfill, while Avalon Logkit is nowhere to be seen. In the history of software, no one has ever managed to abstract competing and divergent APIs without their active cooperation. Chances are it won't happen this time around either. User who currently use commons-logging are likely to go through a lengthy and painful conversion process when they realize that log4j offers must-have features. Matt -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Curt Arnold [EMAIL PROTECTED] wrote on 12/16/2004 11:13:25 PM: On Dec 16, 2004, at 7:56 PM, Richard Sitze wrote: Good comments, thanks. Curt Arnold [EMAIL PROTECTED] wrote on 12/16/2004 05:34:58 PM: Sorry to come in on this late. I just read the archives after Ceki posted a link on log4j-dev. First, I agree Enterprise is a poor name. I tend to think in terms of Back to the issue of names, assuming we don't play some of the other games mentioned above, other name suggestions are welcome. I wasn't terribly concerned about the eventual class names. More try to make the observation that the major tension is between the intended audience for the message not the scope of the system. A debug or trace level message in a handheld app has more in common with a trace level message in a enterprise system than either has with a out of stock warning in either system. diagnostic versus administrative logging. Diagnostic logging intended to diagnose an issue where log requests are generally discarded (unless actively researching a problem) and fluency with internal program structure and with the human language used in the implementation is assumed. Logger names based on class names would be appropriate here since the audience is likely familiar with the code base. Agreed. JCL [as well as Log4J and JSR-47 logging] supports trace level [JCL debug, trace] logging which I believe equates to what you term diagnostic logging. We do *not* propose to 'internationalize' these... I would resist such efforts. Administrative logging (in lack of a better term, but at least it is better than Enterprise) are messages intended for a difference audience where knowledge of internal program structure and the human language of the implementation is not given. These difference audiences have resulted in different API on some platforms, for example, Windows has OutputDebugString (for diagnostic messages) and the Event log methods for administrative messages. Logger names here would likely be business process related. Reasonable, not sure if your intention is to relate this type of logging to the message level logging of JCL [fatal, error, warn, info]. I don't think that was my intention. Platform provided diagnostic logging, like Win32 OutputDebugString, may be very simplistic and provide no support for prioritization, persistence, or internationalization. Platform provided administrative logging, like the NT event log, would likely support some of those. Both a diagnostic and a administrative system may have a concept of a WARN severity, however the business significance of a WARN severity may be orders of magnitude different depending on the context. I would not think it common that, for example, inventory messages would switch from using a diagnostic to an administrative type API based on message severity. As you pointed out earlier, much of this depends on how the logger is used. Class category names for code logging, other application category logger names for the other would be a reasonable approach. However, for our stated *GOAL*, JCL's primary purpose is for instrumenting components that are expected to plug into larger applications/frameworks. It's not clear to me what it means to start instrumenting such components for administrative or application level logging events. Not to say it couldn't be done. This is a best-practice issue for the most part... something for the users guide. If there are specific issues to be addressed by the API's, please raise them? Examples? It's not clear to me what course of action you advocate. There are a couple of issues with the resource bundle proposals that I have seen previously. I haven't had time to review those presented here so they may or may not apply. Resource bundle approaches are sufficiently demanding of developers that they will likely substantially reduce the density of diagnostic messages if only a resource bundle approach is available. What are our (simple) options. Again remember that we expect to be a thin-wrapper over existing log implementations. Using the locale settings of the user or system is likely inappropriate for diagnostic messages. A diagnostician reviewing log files or receiving networked log messages should not be forced to read log messages in the user's native language. A worse case scenario would be a internationalized web site log where the language in the log file was constantly changing. Agreed. Again, the current proposal does not provide I18N enabled logging for JCL debug or trace methods. If I was a diagnostician looking at a log, I would want all the diagnostic messages, whether they be ERROR or TRACE to be in my preferred language not that of a user or web site visitor. Turning on debug or trace messages would likely
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 18 Dec 2004, at 16:25, Matt Sgarlata wrote: snip robert burrell donkin wrote: does anyone think that there is any real need for implementations to belong to a second type hierarchy? I don't think it's a good idea to *preclude* logs from participating in two different type hierarchies because it's hard to anticipate new use cases. it's a tradeoff :) it's hard to anticipate new use cases. this means that it's hard to future-proof any interface. Log isn't too bad but (had it been an abstract class) i think that it would have had at least one more method added (to improve support for IoC frameworks). it's important to keep in mind that these interfaces are likely to have to maintain compatibility for several years. But to answer your question, remember how Richard proposed that the generation of exception messages be possible with Logs? Well I think the community struck that idea down, but what if someone *did* decide they wanted to combine that functionality with their logger. In that case they would probably want to extend some type of message resolution base class rather than being forced to extend a Log abstract class. (i wasn't the first to note this but) inheritance is often overused in java. an equally good design could use delegation (to the message resolution class) or a nested implementation. i don't mind forcing users to choose a particular design provided that this design is as good or better than the original. the only use case (where alternative, equitable designs do not exist) i can think of would be a Log proxy. i'm not sure how useful that would be. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 17 Dec 2004, at 01:56, Richard Sitze wrote: robert burrell donkin [EMAIL PROTECTED] wrote on 12/16/2004 04:38:34 PM: snip the solution i've been considering is to separate the base application-environmental configuration from the sophisticated discovery process required to ensure proper isolation in complex managed server environments. (i'm not going to describe this in detail right now: i should post a code example but i'm tired so that'll have to wait.) I will eagerly await, and will compare your thoughts to what is described in the original proposal. For reference, please note that the proposal can be found here: http://issues.apache.org/bugzilla/show_bug.cgi?id=32618 i've added some thoughts onto some new wiki pages linked from http://wiki.apache.org/jakarta-commons/Logging. where does byte-code engineering come in? well, there are certain things that users want that are just not going to be feasible no matter how sophisticated a discovery process is employed. too much complexity leads to fragility in the discovery code: providing rewiring at the byte-code level would allow users great control and relieve the commons-logging development team of the burden of creating every more complex discovery code. And other teams... this *must* be addressed independently from Logging. +1 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Excellent! Chris Lambrou [EMAIL PROTECTED] wrote on 12/17/2004 04:32:28 PM: Someone suggested that for Log, it would be appropriate to make it an abstract class rather than an interface, so we can make these kinds of changes easier in the future. I think the risks for this are low, and probably better [less problems for the majority of users] than just adding new methods to the existing interface. Other thoughts on this direction? I think the risk of annoying quite a number of users by changing Log from an interface to an abstract class is actually quite high. For sure, one of the default logging implementations provided by JCL would probably suffice for the majority. However, there are groups who will have chosen, for whatever reason, to provide their own logging implementations. I've certainly worked on a couple of projects where this has been the case. One of them could probably cope with the change relatively easiliy, but such a change could be a real pain for the other. Whilst the proportion of JCL users in this situation is probably quite small, in terms of actual numbers, such a change could cause quite a lot of grief. IF we went down this road [no such proposal has yet been made], you would be required to make SOME code change. a. Change the 'implements' to an 'extends', pick up default impls for the new methods. b. Supply new methods all your existing code that implements Log. You advocate that (a) is a bigger hit to you. I would have thought (b) would be more difficult, UNLESS your current Log implementations extend some other class. I would have thought Log classes extending other [non Log] classes would be very unlikely. *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
While acknowledging that while we all orbit the same sun, we also stand in different time zones and see it differently... :-) news [EMAIL PROTECTED] wrote on 12/18/2004 10:44:11 AM: Noel J. Bergman wrote: Simon Kitching wrote: I've been convinced by the arguments put forward in this thread that explicit enter/exit methods taking class+method strings should not be encouraged Actually, I agree. I'd prefer to see that semantic state encoded in the log message, which I feel is much cleaner. --- Noel +1. Just because the JDK 1.4 log does this, doesn't mean that we have to enforce this behavior on all logging implementations. Why not just leave it generic? If someone wants enter/exit methods, they can define their own: public static void enter(Log log, Class clazz, String method); public static void exit(Log log, Class clazz, String method); The proposal is for more than a the simple helper methods, it is for the [potential] underlying implementation below. Where possible, these SHOULD be mapped to a finer level than 'debug', but not as fine as 'trace'. By naming them 'enter/exit' instead of 'finer', we encourage their use in a particular fashion... if you feel that such strong best-practice enforcement is inappropriate, then let's not throw the dog [and I know it's a dog ;)] out with the bath water. We'd like at least one more trace level, see below. Personally, I am against introducing logging that is more specific than TRACE. In practice, I think it's hard to explain even the distinction between TRACE and DEBUG (i.e. - the projects I've seen tend to use one or the other almost exclusively if they're not using INFO or higher for the message). Again, just because JDK 1.4 offers FINEST, FINER doesn't mean JCL has to. What happens when the next implementation comes along that offers 42 different logging levels, including TINY, VERYTINY, EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels? There are many uses for different levels of trace logging [general term, not JCL trace]. One such for which I advocate better support is: 1. Tracing as we cross component boundries [currently this would be JCL debug on classes representing component API's]. I want to log information that helps me understand what's coming in, and what's going out, at a COMPONENT level [component TBD as you like]. 2. Tracing as we cross class/method boundries [currently we propose this with enter/exit]. 3. Tracing of additional low level information [currently this would be JCL trace]. Two trace levels is simply not enough. Granted we can play games with loggerNames, but feel this unnecessarily imposes multiple logger name schemes where the class name is more than sufficient for most uses. IN PARTICULAR, if we want to document this as a best-practice in the users guide, then we need also to ensure that there is a consistent logger name scheme being used across components, that there are no [or minimal] collisions... class name really simplifies this. *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote: As you pointed out earlier, much of this depends on how the logger is used. Class category names for code logging, other application category logger names for the other would be a reasonable approach. However, for our stated *GOAL*, JCL's primary purpose is for instrumenting components that are expected to plug into larger applications/frameworks. It's not clear to me what it means to start instrumenting such components for administrative or application level logging events. Not to say it couldn't be done. This is a best-practice issue for the most part... something for the users guide. If there are specific issues to be addressed by the API's, please raise them? Examples? It's not clear to me what course of action you advocate. I was trying to give examples that the localized messages are not needed because the system is enterprise level or because the message is significant, but due to the audience and nature of the message. Enterprise level systems may have more messages that need to be localized, but that doesn't mean that non-enterprise level systems would not benefit. log4j and JSR-47 was designed and optimized for diagnostic logging, however they can be applied effectively for administrative logging. However when they do, there are some aspects (like localization) that may be lacking. However if I was designed a system that needed configurable routing of administrative messages, then I could do worse than using log4j or JSR-47 and working within their constraints or evolving them. There are a couple of issues with the resource bundle proposals that I have seen previously. I haven't had time to review those presented here so they may or may not apply. Resource bundle approaches are sufficiently demanding of developers that they will likely substantially reduce the density of diagnostic messages if only a resource bundle approach is available. What are our (simple) options. Again remember that we expect to be a thin-wrapper over existing log implementations. Depends on the requirements. All I have to go on is what was in the thread and there didn't seem to be a huge amount of elaboration. If the requirement is to support localization of logging messages, then there are multiple ways of attacking that problem. If the requirement is to provide a facade to mimic JSR-47's resource bundle approach, then that is very achievable, however I think it is likely to not be a deeply satisfactory solution to localizing logging messages without some accomodation in the implementations. You seem to be arguing against [pervious statements in your original post], and against [your new statements. What is your point? I am trying to say that the severity of the message is independent of the intended audience of the message and the need for localization. You can have an ERROR message targeted to a diagnostician that should be locale-neutral and a DEBUG message targeted to an administrator that needs to be localized. If I was using a logging system to report, say employee status to a store manager, an employee arriving or leaving might be assigned an INFO status, i. e. lowest severity that is typically reported. If I was trying to diagnose a drop in productivity, I might want to be able to configure that I should get DEBUG severity events, like door swipes or cash register logins and I would still want these in my preferred language. Then the designer must be aware of the distinction between trace level logging, as intended for application debugging, and for message level logging. Everything you describe is message level logging. I think I'm starting to see where you are going with this... and would start by arguing that independent pluggable components are not necessarily the right place to start making assumptions of this sort, or even the right place to be logging this level of information. I was trying to provide reasonable use case sub-INFO severity message would need localization. The primary requirements that drove log4j were diagnostic logging requirements and localization was not a significant design concern. Developers have applied in many uses, like administrative logging, that weren't in the initial set of requirements. The questions is if these two types of logging are incompatible and need two distinct API's or if one API can acceptably handle both. If you are saying that log4j and JCL should ignore requirements from people who are using it for administrative logging, then were are the requirements for localization coming. That a single log request can be rendered for more than one locale would either require having a localizable object passing through the logging dispatch system, being able to translate the log request at the appender or some other approach internal to the logging system. Constructing a message using resource bundles and passing a rendered message on to log4j logging would
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On Dec 18, 2004, at 2:18 PM, Richard Sitze wrote: +1. Just because the JDK 1.4 log does this, doesn't mean that we have to enforce this behavior on all logging implementations. Why not just leave it generic? If someone wants enter/exit methods, they can define their own: public static void enter(Log log, Class clazz, String method); public static void exit(Log log, Class clazz, String method); The proposal is for more than a the simple helper methods, it is for the [potential] underlying implementation below. Where possible, these SHOULD be mapped to a finer level than 'debug', but not as fine as 'trace'. By naming them 'enter/exit' instead of 'finer', we encourage their use in a particular fashion... if you feel that such strong best-practice enforcement is inappropriate, then let's not throw the dog [and I know it's a dog ;)] out with the bath water. We'd like at least one more trace level, see below. Maybe the tension is a manifestation of the problem of trying to assign one common severity to entering and exiting messages. Some entries have to be more significant than others, the only mechanism to distinguish them in the JSR-47 is to not instrument the less significant entry points. Maybe adding a entering(Level level, String...) The JSR-47 adapter could map this the JSR's entering if level was the equivalent of FINER or lower and fabricate a similar message if the level were higher than finer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Developers of open source components that are expected to be plugged into different projects simply cannot and should not assume that Log4J, JSR-47, Avalon, or any other logger IS present. This may severely limit the logging capabilities that may be used by such components. This is the price we pay to be able to go into a customers shop, install an open source solution, and map the logger to their own internal infrastructure with minimal code overhead AND minimal impact on their deployment and administrative processes. It's good to know Log4J is growing so strongly, it is an excellent project. I've enjoyed using it myself a few times. Ceki Gülcü [EMAIL PROTECTED] wrote on 12/18/2004 11:34:14 AM: At 05:44 PM 12/18/2004, Matt Sgarlata wrote: Noel J. Bergman wrote: Actually, I agree. I'd prefer to see that semantic state encoded in the log message, which I feel is much cleaner. --- Noel +1. Just because the JDK 1.4 log does this, doesn't mean that we have to enforce this behavior on all logging implementations. Why not just leave it generic? If someone wants enter/exit methods, they can define their own: public static void enter(Log log, Class clazz, String method); public static void exit(Log log, Class clazz, String method); Personally, I am against introducing logging that is more specific than TRACE. In practice, I think it's hard to explain even the distinction between TRACE and DEBUG (i.e. - the projects I've seen tend to use one or the other almost exclusively if they're not using INFO or higher for the message). Again, just because JDK 1.4 offers FINEST, FINER doesn't mean JCL has to. What happens when the next implementation comes along that offers 42 different logging levels, including TINY, VERYTINY, EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels? Log4j version 1.4 or 2.0 is likely to introduce the notion of multiple domains for categorizing logging statements. When that happens, the notion of logging levels will be looked at very differently. Commons-logging promises to abstract different logging APIs such as log4j, Avalon logkit and java.util.logging API. However, such a task is near impossible to fulfill, while Avalon Logkit is nowhere to be seen. In the history of software, no one has ever managed to abstract competing and divergent APIs without their active cooperation. Chances are it won't happen this time around either. User who currently use commons-logging are likely to go through a lengthy and painful conversion process when they realize that log4j offers must-have features. Matt -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Enter and exit should not be defined as severities. This is useful information, but orthogonal to a logging event's severity attribute. One way to provide entry/exit information is to overload the logger methods to take a map, and require the user to adhere to use-case specific conventions for keys and values. For example, to track entry and exit as we cross component boundaries, these entries might be sufficient to identify an event: Key Name Value - boundary.type component boundary.stateentry Similarly, to track entry and exit as we cross class boundaries: Key Name Value - boundary.type class boundary.stateexit This provides a general mechanism for extending what information an event provides - without codifying use-case specific attributes as methods in commons-logging. Again, the user would be responsible for conforming to naming conventions for the map entries (possibly with the aid of helper methods to build the map) in order to discover these use-case specific events. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
I don't think this alternative has been proposed, the additional
features could also be provided by a decorator, something like :
ExtendedLog log = new ExtendedLog(LogFactory.getLog(Foo.class));
or
ExtendedLog log = LogFactory.getExtendedLog(Foo.class));
For localization, ExtendedLog would create a LogMessage and pass it to
the log implementation. It could also add a code guard to reduce object
creations:
public void debug(String key, Object[] params) {
if (log.isDebugEnabled()) {
log.debug(new LogMessage(key, params));
}
}
For log implementations supporting i18n, the key is extracted from the
LogMessage and searched in a resource bundle. For other implementations,
LogMessage.toString() returns the key and the parameters concatenated.
Just some thoughts :) For i18n I think I like Curt's solution of parsing
the message in the implementation.
Emmanuel Bourg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Someone suggested that for Log, it would be appropriate to make it an abstract class rather than an interface, so we can make these kinds of changes easier in the future. I think the risks for this are low, and probably better [less problems for the majority of users] than just adding new methods to the existing interface. Other thoughts on this direction? I think the risk of annoying quite a number of users by changing Log from an interface to an abstract class is actually quite high. For sure, one of the default logging implementations provided by JCL would probably suffice for the majority. However, there are groups who will have chosen, for whatever reason, to provide their own logging implementations. I've certainly worked on a couple of projects where this has been the case. One of them could probably cope with the change relatively easiliy, but such a change could be a real pain for the other. Whilst the proportion of JCL users in this situation is probably quite small, in terms of actual numbers, such a change could cause quite a lot of grief. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Enterprise Common Logging... dare we say 2.0?
Richard Sitze wrote:
As a real example, the axis community uses globalized messages.
A lot of products do, as I see on a regular basis, so I definitely support
your interest in this feature.
However, I view logging as separate from content generation. I'd like to
see the mechanism pluggable. That could be done by providing a message
factory to the logging layer, so that it does the lookup rather than your
example:
log.error(Message.getMessage(MSGID, new String { arg1, ..., argN }));
Doing so would still permit your facade:
log.error(this.getClass(), thisMethodName, MSGID, new String {...});
but the factory that the logger uses to construct the message would be
pluggable and distinct from the role of bridging to an underlying log
mechanism.
And I'd like to see a Java 5 versiion of this interface that takes advantage
of variable argument lists, rather than the String[].
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Enterprise Common Logging... dare we say 2.0?
Aspect oriented tools obsolete the need for this kind of logging method. We've been able to implement this sort of thing for years using OpenJava. You're all using the OpenJava pre-processor, right? ;-) Translation: I'll accept this reasoning when AOP tools are part of every JDK. Which should be 3-5 years after it is released by Sun. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Enterprise Common Logging... dare we say 2.0?
Simon Kitching wrote: Noel J. Bergman wrote: It disturbs me that what seems to me to be a reasonable and small set of requirements --- along with what appears to have been considerable forethought based upon real world issues, and experiences supporting many developers --- appears to be discounted a bit too out of hand. I hope my perception is wrong. The question is whether the implementation of those requirements is a good fit for commons-logging or not. Commons-logging is used in many environments that the Websphere team may *not* be interested in. Agreed. And I have absolutely no issue with any of the constructive debate that has occured. But I also saw some comments that came across to me as dismissive, and I don't want to discourage people from trying to innovate here. I will dispute localisation of log messages if this: My thought is to have this new layer use a factory pattern to manufacture the logging string from the parameters. That would introduce capability and flexibility without mandating any particular mechanism or overhead, and would remove the need to impose an i18n requirement on the underlying logging implementation. I've been convinced by the arguments put forward in this thread that explicit enter/exit methods taking class+method strings should not be encouraged Actually, I agree. I'd prefer to see that semantic state encoded in the log message, which I feel is much cleaner. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Enterprise Common Logging... dare we say 2.0?
Paulo Gaspar wrote: I don't think we are discounting the value of the original proposal but simply questioning if it should be implemented exactly as proposed - a process you should be familiar with since it is quite common about proposals presented at Apache projects. David Graham wrote: What you're seeing is the natural result of design conversations held outside of the mailing list. No one here had the benefit of participating in the localized logging design so naturally we're asking questions and making suggestions. robert burrell donkin wrote: i'd much rather that people speak up and voice their concerns now when we can actually acknowledge them and (at the very least) document reasons for rejecting. As I said to Simon, I have no issue with any of the constructive debate surrounding the proposal. I firmly believe that the best solutions come from constructive pushing within the solution space to satisfy competing interests, and are a synthesis derived from the creative input of multiple people. However, I also saw some comments that came across to me as unnecessarily negative, and I don't want to discourage people from trying to innovate here. Putting this another way: let's have the debates, but at the same time, make sure that we encourage participation in the process while we do so. Not everyone will have what appears to be Richard's excellent attitude. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Hello Henning, Robert Burrell Donkin kindly informed of the existence of your discussion. Henning, since you mentioned me by name in your last message, allow me to respond. If my memory serves me correctly, I have only once proposed Tomcat to bundle log4j. It was quite a few years ago. Since then, I have been careful to stay away from that topic. Being out of the limelight actually helped us to develop log4j without all the pressure associated with excessive public attention. So it would be nice to have Tomcat officially adopt log4j, but maybe not just yet. Best regards, On 2004-12-16 8:29:31, Henning P. Schmiedehausen wrote: Hm. This does not feel right to me. IMHO this will lead to the situation that some developers (most notably the log4j guys; Hi Ceki! [1]) condemn. Your web app container (let's say tomcat) ships with the missing config is ok jar version in its class path and your application is deployed with the missing config is bad version. Leading to all kinds of interesting classloader issues and general nightmarish behaviour. Regards Henning [1] If we went down the path that Ceki has for years lobbied for, today it would be tomcat ships with log4j 1.2.x and your app requires log4j 1.3.x,, leading to all kinds of interesting classloader issues and general nightmarish behaviour. today... :-) -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
All, Sorry for sidetracking, this is for Ceki Ceki, when do you plan to release 1.3.0? I've been following the development with some interest for a whiledo you have any idea when 1.3.0 will be ready for release? Jakarta Commons Developers List [EMAIL PROTECTED] wrote: Hello Henning, Robert Burrell Donkin kindly informed of the existence of your discussion. Henning, since you mentioned me by name in your last message, allow me to respond. If my memory serves me correctly, I have only once proposed Tomcat to bundle log4j. It was quite a few years ago. Since then, I have been careful to stay away from that topic. Being out of the limelight actually helped us to develop log4j without all the pressure associated with excessive public attention. So it would be nice to have Tomcat officially adopt log4j, but maybe not just yet. Best regards, On 2004-12-16 8:29:31, Henning P. Schmiedehausen wrote: Hm. This does not feel right to me. IMHO this will lead to the situation that some developers (most notably the log4j guys; Hi Ceki! [1]) condemn. Your web app container (let's say tomcat) ships with the missing config is ok jar version in its class path and your application is deployed with the missing config is bad version. Leading to all kinds of interesting classloader issues and general nightmarish behaviour. Regards Henning [1] If we went down the path that Ceki has for years lobbied for, today it would be tomcat ships with log4j 1.2.x and your app requires log4j 1.3.x,, leading to all kinds of interesting classloader issues and general nightmarish behaviour. today... :-) --=20 Ceki G=FClc=FC The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
*** Richard A. Sitze IBM WebSphere WebServices Development Simon Kitching [EMAIL PROTECTED] wrote on 12/15/2004 06:23:35 PM: On Thu, 2004-12-16 at 10:21, Richard Sitze wrote: Henning P. Schmiedehausen [EMAIL PROTECTED] wrote on 12/15/2004 ...byte-code engineering contradict each other. One of the really, really strong things of c-l is, that it needs no additional jars. Just drop commons-logging in, develop your app, deploy with the app, commons-logging and a logger implementation, off you go. This is a strong point from a lazy point of view [no offense, please]. But it's also one if it's greatest weaknesses. You have no way of knowing which logger impl. you are going to be using. Yes, you can configure. No, there is no assurance that what you configured will be used... you can check it once, but when you start deploying your applications in production, you have to re-check.. and re-check... and you never know when someone's going to change the classpath and change the behavior. It's a nightmare. I think this demonstrates a major issue. When using logging in an enterprise situation, the logging can be considered a critical part of the application. If you have heavy-duty monitoring systems watching for alerts from the software, and have sysadmins on call 24x7 to deal with issues, then for an application to fail to locate the correct logging libs or config files is a *failure* of the app. You don't want an app to start up, but then not be able to generate alerts if problems occur. But when using logging in other situations, logging is *not* a critical part, and should not cause an application to fail to start. The latter is the focus of commons-logging at the moment. And unfortunately as commons-logging has no *mandatory* configuration, it is not possible to add a fail-on-no-config option! I do not advocate a fail-on-no-config or fail-on-ambiguous-config. I advocate a *warn* or *error* on either, using the simple default logger. The warning will be visible on the console, which suffices for my immediate concerns. How that warning/error (in general) is managed is up to the application environment. So perhaps we could build two separate jars from mostly-common source code? Deploying the traditional commons-logging jar would do the be quiet on no config, while the enterprise commons-logging jar would do something like write message to STDERR then throw a runtime exception on no config? Yes, I want to maintain the easy route as much as possible, but it's time we adopt proven best practices from the industry and stop falling all over ourselves to keep a few programmers happy. It's easier to figure out what your problem is if you missed one of two required jar files, than it is to debug the current situation. Strategies have been discussed in more detail on other threads, so I'm not going to go in this any further here. I think this depends on what your application's goal is. You seem to be thinking *only* of commons-logging from a J2EE point of view. Writers of stand-alone apps often want exactly the behaviour that commons-logging currently gives, and would be very against commons-logging terminating apps unless config is found. The environments in question are not [necessarily] related to J2EE. The particular issues should be generalized to more complex classloader hierarchies... which is something JCL explicitly attempts to support. I hope that my suggestion above (two commons-logging variants built from a common source tree) provides a way to address both goals without having to create a separate fork for enterprise logging. I'd very much like to keep that, which means that any bytecode manipulation code should be part of the commons-logging jar. I'd like to avoid getting dependent on things like BCEL. I'm cool with any byte-code manip as an ant task, for those who want to pull those dependencies into their environment. But JCL should not start down this path [redundant with other projects, just like it's discovery is redundant with Jakarta Commons Discovery... admittedly JCL came first]. So I'll repeat an earlier request: anyone want to submit the correct AspectJ [and other's are of course welcome] declarations to perform this type of work? Even if it's a few lines in the User's Guide. I notice that just4log (just4log.sourceforge.net) supports automatically adding entry/exit logging at compile-time. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Just for the record, the primary issue is NOT inability to locate a logger. It's not finding the expected logger [from the developer/users perspective], and silently falling back to an alternate logger. *** Richard A. Sitze IBM WebSphere WebServices Development Simon Kitching [EMAIL PROTECTED] wrote on 12/15/2004 10:18:44 PM: On Thu, 2004-12-16 at 13:53, Matt Sgarlata wrote: Simon Kitching wrote: I think this demonstrates a major issue. When using logging in an enterprise situation, the logging can be considered a critical part of the application. If you have heavy-duty monitoring systems watching for alerts from the software, and have sysadmins on call 24x7 to deal with issues, then for an application to fail to locate the correct logging libs or config files is a *failure* of the app. You don't want an app to start up, but then not be able to generate alerts if problems occur. But when using logging in other situations, logging is *not* a critical part, and should not cause an application to fail to start. The latter is the focus of commons-logging at the moment. And unfortunately as commons-logging has no *mandatory* configuration, it is not possible to add a fail-on-no-config option! So perhaps we could build two separate jars from mostly-common source code? Deploying the traditional commons-logging jar would do the be quiet on no config, while the enterprise commons-logging jar would do something like write message to STDERR then throw a runtime exception on no config? Why not just introduce a boolean parameter that says whether or not an inability to log is a failure? e.g. Log log = LogFactory.getLog(MyClass.class, true); It's not inability to log as such. It's whether finding no specific config info or underlying log implementation and therefore falling back to using java.util.logging (java=1.4) or org.apache.commons.logging.SimpleLog (java1.4) is allowed or not. In many cases, what you *want* an app to do if it can't find any specific logging config is simply to output ERROR and FATAL messages to stderr. This is what commons-logging will currently do if its discovery process finds nothing. I guess commons-logging *could* use a parameter such as you suggest to indicate explicit configuration of logging is mandatory. This would presumably mean detecting whether commons-logging.properties or the corresponding system properties have defined an explicit log implementation and config file for that implementation. I'm not sure, however, if the decision on whether logging is mandatory or not should be a compile-time one. It seems to me to be more like something the application *deployer* should choose. That then leads us to a circular reference: how do we know whether configuration is mandatory or not, if we can't find any configuration? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
David Graham [EMAIL PROTECTED] wrote on 12/16/2004 11:47:46 AM: snip/ The current proposal is: - configuration is always manditory. Doesn't mandatory configuration relieve us from needing to split commons-logging.jar into several pieces? I like the fact that I don't have to manage multiple commons-logging jar files and will be rather dissapointed if that is required in the future. I wouldn't mind having a simple properties file or a system property like -Dorg.apache.commons.logging.impl=log4j that tells commons-logging to use log4j. ok, without going back to review exactly what I said in an earlier note, I had in mind something like: commons-logging-core.jar - core interface factory class, NO config commons-logging.jar- core + all helpers, NO config commons-logging-impl.jar - core + ONE helper, ONE config With this scheme, I believe we can scrub the code from LogFactory that looks for an attempts to load specific logger impls [Log4J, Avalon, ?], and instead depend entirely on the config. David - ambiguous [multiple] configurations located by a particular ClassLoader in the hierarchy requires an error to be logged [where is a reasonable question to ask]. How we determine which configs belong to which ClassLoaders is described in the original proposal. - in a core JCL jar, a configuration *must not* be packaged with JCL. - in a helper JCL jar, a configuration *must* be packaged, along with *one* JCL logger wrapper class. - multiple helper JCL jar files, one per logging impl wrapper we support. Pick the logger impl you want, grab the corresponding helper JCL jar file, and drop it into your application. snip/ *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Richard Sitze [EMAIL PROTECTED] writes: Just for the record, the primary issue is NOT inability to locate a logger. It's not finding the expected logger [from the developer/users perspective], and silently falling back to an alternate logger. Yep. I fully agree with you here. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 15 Dec 2004, at 20:10, Richard Sitze wrote: robert burrell donkin [EMAIL PROTECTED] wrote on 12/15/2004 01:39:57 PM: On 10 Dec 2004, at 01:42, Charles Daniels wrote: 8 8 Regardless of the performance, though, there is still the matter of exactly where the messagekey+params gets converted to a message string. Having a user-provided Message object do it delegates the responsibility of locating the i18n resource bundle to the logging app, which may or may not be appropriate. Having an underlying log adapter class do it (a kind of i18n decorator pattern?) raises the issue of how it would locate the bundle. Log adaptor classes don't currently deal with configuration in any way AFAIK; they just pass the message down. Yes, I agree, the trick then becomes locating the resource bundle. Perhaps one way to do this is to have the Message class locate it based upon a property in commons-logging.properties. The Message.toString method would then lookup the resource and construct the message. This way, neither the application nor the Log implementation would have to deal with it. i really think that this needs to be done through pluggable adapters (since there isn't going to be any one correct solution). in addition, i've come to the conclusion (after tussling with some thorny i18n and customization problems elsewhere) that the formatting conventionally available for parameterization rendering (stuff like MessageFormat) just isn't good enough and a proper bean query language is really needed. i've always wanted to mix resources and JEXL but (sighas usual/sigh) i haven't found the cycles... Ok.. this requires some thought here. All that sounds good, but is out of focus. 1. Remember that our goal is to pass resourceBundleName and keyID's straight through to underlying loggers that support I18N. For those that do NOT support, we want minimal help. providing underlying layers that could (if they wished) provide better support pretty much addresses my concern. 2. Recall that we are enabling LOGGING for COMPONENTS. This is substantially different, and can be [arguably should be] separated from any I18N for other output related to the component development [including GUI's, text output for console or printer user I/O]. 3. It is NOT our goal to develop a flexible, pluggable, etc. I18N framework for logging. 4. It is my hope and belief that we can fall back to a lowest common denominator that is sufficient for logging in *component* development. +1 those goals seem reasonable (and probably achievable). i'm not sure that lowest common denominator is the right description: a minimal sufficient implementation sounds better to me. in other words, rather than starting with what's provided in other frameworks, we start from nothing and add only what's necessary. once a sufficient implementation has been provided, development stops. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 15 Dec 2004, at 20:10, Richard Sitze wrote: Glad you made it Robert, was starting to feel that this was getting snubbed by the core logging advocates ;-)! good to hear from you again as well :) BTW i'm not sure i'd describe myself as an advocate: commons-logging usually seems more like trench warfare ;) (i don't seem to have been able to find too many cycles for apache recently - it's the traditional british Christmas: cold/flu, rushing around to see old friends and long, dark, wet and windy ale-filled nights - so you'll have to forgive me if i get a little behind this thread.) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 16 Dec 2004, at 00:23, Simon Kitching wrote: On Thu, 2004-12-16 at 10:21, Richard Sitze wrote: Henning P. Schmiedehausen [EMAIL PROTECTED] wrote on 12/15/2004 ...byte-code engineering contradict each other. One of the really, really strong things of c-l is, that it needs no additional jars. Just drop commons-logging in, develop your app, deploy with the app, commons-logging and a logger implementation, off you go. This is a strong point from a lazy point of view [no offense, please]. But it's also one if it's greatest weaknesses. You have no way of knowing which logger impl. you are going to be using. Yes, you can configure. No, there is no assurance that what you configured will be used... you can check it once, but when you start deploying your applications in production, you have to re-check.. and re-check... and you never know when someone's going to change the classpath and change the behavior. It's a nightmare. I think this demonstrates a major issue. When using logging in an enterprise situation, the logging can be considered a critical part of the application. If you have heavy-duty monitoring systems watching for alerts from the software, and have sysadmins on call 24x7 to deal with issues, then for an application to fail to locate the correct logging libs or config files is a *failure* of the app. You don't want an app to start up, but then not be able to generate alerts if problems occur. But when using logging in other situations, logging is *not* a critical part, and should not cause an application to fail to start. The latter is the focus of commons-logging at the moment. And unfortunately as commons-logging has no *mandatory* configuration, it is not possible to add a fail-on-no-config option! +1 it seems to me that there are actually two separate levels of configuration: one for the total application environment and one for components within that environment. after a long time trying to work out how to satisfy everyone, i now think that discovery processes can only work within a particular application domain. for example, the current discovery process works well on tomcat, less well on jboss, badly in applets and not at all for J2ME. i believe that it would be possible to create satisfactory discovery systems for limited domains but it would not be possible to use an uber-discovery process to guess the environment. the weakness in current design seems to be the bootstrap process. a discovery process most suitable for only one domain is part of the code that components compile against. the solution i've been considering is to separate the base application-environmental configuration from the sophisticated discovery process required to ensure proper isolation in complex managed server environments. (i'm not going to describe this in detail right now: i should post a code example but i'm tired so that'll have to wait.) where does byte-code engineering come in? well, there are certain things that users want that are just not going to be feasible no matter how sophisticated a discovery process is employed. too much complexity leads to fragility in the discovery code: providing rewiring at the byte-code level would allow users great control and relieve the commons-logging development team of the burden of creating every more complex discovery code. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Sorry to come in on this late. I just read the archives after Ceki posted a link on log4j-dev. First, I agree Enterprise is a poor name. I tend to think in terms of diagnostic versus administrative logging. Diagnostic logging intended to diagnose an issue where log requests are generally discarded (unless actively researching a problem) and fluency with internal program structure and with the human language used in the implementation is assumed. Logger names based on class names would be appropriate here since the audience is likely familiar with the code base. Administrative logging (in lack of a better term, but at least it is better than Enterprise) are messages intended for a difference audience where knowledge of internal program structure and the human language of the implementation is not given. These difference audiences have resulted in different API on some platforms, for example, Windows has OutputDebugString (for diagnostic messages) and the Event log methods for administrative messages. Logger names here would likely be business process related. There are a couple of issues with the resource bundle proposals that I have seen previously. I haven't had time to review those presented here so they may or may not apply. Resource bundle approaches are sufficiently demanding of developers that they will likely substantially reduce the density of diagnostic messages if only a resource bundle approach is available. Using the locale settings of the user or system is likely inappropriate for diagnostic messages. A diagnostician reviewing log files or receiving networked log messages should not be forced to read log messages in the user's native language. A worse case scenario would be a internationalized web site log where the language in the log file was constantly changing. A log request may need to be rendered for more than one locale. For example, a log request may result in email messages send to multiple recipients each in an appropriate language. A diagnostic log may be transmitted to a location where the resource bundles are not available. If it still is resource based at that point, you would require a specialized reader which would need to be kept in sync as new messages were added. Discarded diagnostic messages need to be very low cost. Administrative messages are vastly less frequent, are rarely discarded and can be fairly expensive. An approach that I've found to work fairly well without requiring API modifications is the use of a localizing layout. http://www.mail-archive.com/log4j-user@logging.apache.org/ msg00479.html) describe the use of such a layout in a project using log4net. If you were careful on how you constructed your messages (for example, start with fixed content instead of variable content, did not allow your conversions to be affected by the default locale), you could create a fairly efficient localization mechanism by having a layout that would match the generic message and transform it into an appropriate localized content based on an external document containing regex patterns and substitutions. Some of advantages of this approach: no API change is necessary, diagnostic messages are still trivial to add and fast to process, each appender may have a different locale, localization has no cost for discarded messages, generic language (typically english) messages are available for messages that have not been translated (and likely most diagnostic messages would not be), does not require customized readers. The primary disadvantage is that is it not straightforward to ensure that all the messages of concern have translations and that messages that are to be localized should be designed so that they are easily matched and parsed. FYI: log4cxx does have a resource bundle logging API, but I have no experience with it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
robert burrell donkin [EMAIL PROTECTED] wrote on 12/16/2004 04:38:34 PM: snip/ I think this demonstrates a major issue. When using logging in an enterprise situation, the logging can be considered a critical part of the application. If you have heavy-duty monitoring systems watching for alerts from the software, and have sysadmins on call 24x7 to deal with issues, then for an application to fail to locate the correct logging libs or config files is a *failure* of the app. You don't want an app to start up, but then not be able to generate alerts if problems occur. But when using logging in other situations, logging is *not* a critical part, and should not cause an application to fail to start. The latter is the focus of commons-logging at the moment. And unfortunately as commons-logging has no *mandatory* configuration, it is not possible to add a fail-on-no-config option! +1 it seems to me that there are actually two separate levels of configuration: one for the total application environment and one for components within that environment. I don't entirely disagree, but we have adamantly maintained that for JCL in particular, there IS no configuration of the underlying logger by JCL. That should be left to the logger implementation. So... what do you think the components should/could configure for logging? after a long time trying to work out how to satisfy everyone, i now think that discovery processes can only work within a particular application domain. for example, the current discovery process works well on tomcat, less well on jboss, badly in applets and not at all for J2ME. i believe that it would be possible to create satisfactory discovery systems for limited domains but it would not be possible to use an uber-discovery process to guess the environment. the weakness in current design seems to be the bootstrap process. a discovery process most suitable for only one domain is part of the code that components compile against. I've started to recognize this myself... a. This is an argument for commons-discovery.. to break the discovery process completely OUT of the components that need to be discovered [JCL is one such]. b. Have asked myself the horrible question of how discovery might discover itself. I get a headache quickly, and wish I drank. c. Realize that the simple answer is that discovery does NOT discover, it's hard coded for a particular environment. The [high level] API's are standardized, and a commons component [such as commons logging] MUST be able to assume that they are there. the solution i've been considering is to separate the base application-environmental configuration from the sophisticated discovery process required to ensure proper isolation in complex managed server environments. (i'm not going to describe this in detail right now: i should post a code example but i'm tired so that'll have to wait.) I will eagerly await, and will compare your thoughts to what is described in the original proposal. For reference, please note that the proposal can be found here: http://issues.apache.org/bugzilla/show_bug.cgi?id=32618 where does byte-code engineering come in? well, there are certain things that users want that are just not going to be feasible no matter how sophisticated a discovery process is employed. too much complexity leads to fragility in the discovery code: providing rewiring at the byte-code level would allow users great control and relieve the commons-logging development team of the burden of creating every more complex discovery code. And other teams... this *must* be addressed independently from Logging. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Richard A. Sitze IBM WebSphere WebServices Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Good comments, thanks. Curt Arnold [EMAIL PROTECTED] wrote on 12/16/2004 05:34:58 PM: Sorry to come in on this late. I just read the archives after Ceki posted a link on log4j-dev. First, I agree Enterprise is a poor name. I tend to think in terms of Ok.. let me make a few points: - LocalizedLog, GlobalizeLog, i18nLog, nlsLog, nlvLog, or any of 100 other variants along that theme are not strictly appropriate. I will resist these names. The addition APIs include more than [admittedly not a lot more] i18n support. enter/exit are new trace level [diagnostic level, as-per your terms] API's. - We could consider a staged approach: - MoreLog extends Log [name tbd]: for the enter/exit methods - nlsLog extends MoreLog: for i18n API's Not sure I like the implications of this, but am still reluctant to add new methods to Log itself. Someone suggested that for Log, it would be appropriate to make it an abstract class rather than an interface, so we can make these kinds of changes easier in the future. I think the risks for this are low, and probably better [less problems for the majority of users] than just adding new methods to the existing interface. Other thoughts on this direction? Back to the issue of names, assuming we don't play some of the other games mentioned above, other name suggestions are welcome. diagnostic versus administrative logging. Diagnostic logging intended to diagnose an issue where log requests are generally discarded (unless actively researching a problem) and fluency with internal program structure and with the human language used in the implementation is assumed. Logger names based on class names would be appropriate here since the audience is likely familiar with the code base. Agreed. JCL [as well as Log4J and JSR-47 logging] supports trace level [JCL debug, trace] logging which I believe equates to what you term diagnostic logging. We do *not* propose to 'internationalize' these... I would resist such efforts. Administrative logging (in lack of a better term, but at least it is better than Enterprise) are messages intended for a difference audience where knowledge of internal program structure and the human language of the implementation is not given. These difference audiences have resulted in different API on some platforms, for example, Windows has OutputDebugString (for diagnostic messages) and the Event log methods for administrative messages. Logger names here would likely be business process related. Reasonable, not sure if your intention is to relate this type of logging to the message level logging of JCL [fatal, error, warn, info]. There are a couple of issues with the resource bundle proposals that I have seen previously. I haven't had time to review those presented here so they may or may not apply. Resource bundle approaches are sufficiently demanding of developers that they will likely substantially reduce the density of diagnostic messages if only a resource bundle approach is available. Using the locale settings of the user or system is likely inappropriate for diagnostic messages. A diagnostician reviewing log files or receiving networked log messages should not be forced to read log messages in the user's native language. A worse case scenario would be a internationalized web site log where the language in the log file was constantly changing. Agreed. Again, the current proposal does not provide I18N enabled logging for JCL debug or trace methods. A log request may need to be rendered for more than one locale. For example, a log request may result in email messages send to multiple recipients each in an appropriate language. A diagnostic log may be transmitted to a location where the resource bundles are not available. If it still is resource based at that point, you would require a specialized reader which would need to be kept in sync as new messages were added. Discarded diagnostic messages need to be very low cost. Administrative messages are vastly less frequent, are rarely discarded and can be fairly expensive. Agreed. An approach that I've found to work fairly well without requiring API modifications is the use of a localizing layout. http://www.mail-archive.com/log4j-user@logging.apache.org/ msg00479.html) describe the use of such a layout in a project using log4net. If you were careful on how you constructed your messages (for example, start with fixed content instead of variable content, did not allow your conversions to be affected by the default locale), you could create a fairly efficient localization mechanism by having a layout that would match the generic message and transform it into an appropriate localized content based on an external document containing regex patterns and substitutions. This is much to complex for the casual user. To repeat earlier comment, it is *critical* to put JCL
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On Dec 16, 2004, at 7:56 PM, Richard Sitze wrote: Good comments, thanks. Curt Arnold [EMAIL PROTECTED] wrote on 12/16/2004 05:34:58 PM: Sorry to come in on this late. I just read the archives after Ceki posted a link on log4j-dev. First, I agree Enterprise is a poor name. I tend to think in terms of Back to the issue of names, assuming we don't play some of the other games mentioned above, other name suggestions are welcome. I wasn't terribly concerned about the eventual class names. More try to make the observation that the major tension is between the intended audience for the message not the scope of the system. A debug or trace level message in a handheld app has more in common with a trace level message in a enterprise system than either has with a out of stock warning in either system. diagnostic versus administrative logging. Diagnostic logging intended to diagnose an issue where log requests are generally discarded (unless actively researching a problem) and fluency with internal program structure and with the human language used in the implementation is assumed. Logger names based on class names would be appropriate here since the audience is likely familiar with the code base. Agreed. JCL [as well as Log4J and JSR-47 logging] supports trace level [JCL debug, trace] logging which I believe equates to what you term diagnostic logging. We do *not* propose to 'internationalize' these... I would resist such efforts. Administrative logging (in lack of a better term, but at least it is better than Enterprise) are messages intended for a difference audience where knowledge of internal program structure and the human language of the implementation is not given. These difference audiences have resulted in different API on some platforms, for example, Windows has OutputDebugString (for diagnostic messages) and the Event log methods for administrative messages. Logger names here would likely be business process related. Reasonable, not sure if your intention is to relate this type of logging to the message level logging of JCL [fatal, error, warn, info]. I don't think that was my intention. Platform provided diagnostic logging, like Win32 OutputDebugString, may be very simplistic and provide no support for prioritization, persistence, or internationalization. Platform provided administrative logging, like the NT event log, would likely support some of those. Both a diagnostic and a administrative system may have a concept of a WARN severity, however the business significance of a WARN severity may be orders of magnitude different depending on the context. I would not think it common that, for example, inventory messages would switch from using a diagnostic to an administrative type API based on message severity. There are a couple of issues with the resource bundle proposals that I have seen previously. I haven't had time to review those presented here so they may or may not apply. Resource bundle approaches are sufficiently demanding of developers that they will likely substantially reduce the density of diagnostic messages if only a resource bundle approach is available. Using the locale settings of the user or system is likely inappropriate for diagnostic messages. A diagnostician reviewing log files or receiving networked log messages should not be forced to read log messages in the user's native language. A worse case scenario would be a internationalized web site log where the language in the log file was constantly changing. Agreed. Again, the current proposal does not provide I18N enabled logging for JCL debug or trace methods. If I was a diagnostician looking at a log, I would want all the diagnostic messages, whether they be ERROR or TRACE to be in my preferred language not that of a user or web site visitor. Turning on debug or trace messages would likely only occur after I narrow the problem down by looking at higher level. By not having I18N debug or trace messages, you are basically saying that those levels don't exist for messages that need to be internationalized. If I was using a logging system to report, say employee status to a store manager, an employee arriving or leaving might be assigned an INFO status, i. e. lowest severity that is typically reported. If I was trying to diagnose a drop in productivity, I might want to be able to configure that I should get DEBUG severity events, like door swipes or cash register logins and I would still want these in my preferred language. A log request may need to be rendered for more than one locale. For example, a log request may result in email messages send to multiple recipients each in an appropriate language. A diagnostic log may be transmitted to a location where the resource bundles are not available. If it still is resource based at that point, you would require a specialized reader which would need to be kept in sync as new messages were added. Discarded diagnostic
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Simon Kitching [EMAIL PROTECTED] writes: So perhaps we could build two separate jars from mostly-common source code? Deploying the traditional commons-logging jar would do the be quiet on no config, while the enterprise commons-logging jar would do something like write message to STDERR then throw a runtime exception on no config? Hm. This does not feel right to me. IMHO this will lead to the situation that some developers (most notably the log4j guys; Hi Ceki! [1]) condemn. Your web app container (let's say tomcat) ships with the missing config is ok jar version in its class path and your application is deployed with the missing config is bad version. Leading to all kinds of interesting classloader issues and general nightmarish behaviour. Regards Henning [1] If we went down the path that Ceki has for years lobbied for, today it would be tomcat ships with log4j 1.2.x and your app requires log4j 1.3.x,, leading to all kinds of interesting classloader issues and general nightmarish behaviour. today... :-) -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Richard Sitze [EMAIL PROTECTED] writes: This is a strong point from a lazy point of view [no offense, please]. But it's also one if it's greatest weaknesses. You have no way of knowing which logger impl. you are going to be using. Yes, you can configure. No, there is no assurance that what you configured will be used... you can check it once, but when you start deploying your applications in production, you have to re-check.. and re-check... and you never know when someone's going to change the classpath and change the behavior. It's a nightmare. Making sure that you always hand out the right logging implementatin is the job of your application / your container. It should use e.g. log4j as its enterprise logger and allow components, that are 3rd party or independently written from your application and want to use JCL to use these and wire their logging output into your enterprise logging. An example here. Turbine optionally configures log4j and offers it to its components and applications as its enterprise logger. It also uses a commons-logging.properties file (which is part of the META environment and distributed with every turbine application unless the developer changes it explicitly), to wire JCL onto log4j. The Turbine core itself uses _only_ JCL and we do encourage our users whenever they write a new service or component to do the same. So you can plug a Turbine application into your enterprise container and simply rewire all of its logging using commons-logging.properties (which then should point at your enterprise logging facility). Your app would be responsible to offer the JCL implementation (which boils down to what? One class (factory) and one Log interface implementation) to its components. When they ask for Log log = LogFactory.getLog(mumble), the app is ultimately responsible that they get a logger which is then integrated with your enterprise logging. If this fails, this IMHO is an application failure, not a JCL failure. The enterprise logging scope (I will keep the L10N and I18N issues out here) for JCL is IMHO the same scope as for the regular component. If you run a smallish program (or build a component), an unconfigured JCL will output to stderr. Which works well. If you run in an enterprise environment, you must make sure, that this enterprise environment returns the right configuration to the LogFactory so that it returns your implementation. The current lookup process is IMHO too fragile because it depends on jars in the classpath. Using bytecode engineering has its merits (because it would allow your enterprise application to simply rewire the Factory implementation lookup process to return your enterprise logger). Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
On 2004-12-16 8:29:31, Henning P. Schmiedehausen wrote: [1] If we went down the path that Ceki has for years lobbied for, today it would be tomcat ships with log4j 1.2.x and your app requires log4j 1.3.x,, leading to all kinds of interesting classloader issues and general nightmarish behaviour. today... :-) For logging within an app server like Tomcat, the log4j team recommends the installation of a single copy of log4j.jar in TOMCAT_HOME/common/lib/. This log4j.jar file will be loaded only once in memory, shared by the application server *and* all applications desiring to use log4j for their logging, with the separation of logging contexts ensured by a repository selector [1, 2, 3] based on JNDI. Applications desiring to use a different logging API remain unaffected. Given that log4j versions change quite slowly with almost few rare backward compatibility problems, one could imagine that an application server, say WildCat, could easily move to the latest official version of log4j without significant trouble. Now, in the possible but relatively infrequent event where the customer's application using log4j version 'k' is deployed on an older version of WildCat dependent on log4j version k, with k n, the customer has several options. First, it should be possible to just drop and replace log4j version n with version k at the level of WILDCAT_HOME/common/lib. If that is not possible, then the customer can bundle log4j version n within the application's war file. Note that the latter solution is more or less where we stand today. I guess that's enough talk about log4j on this forum. [1] http://wiki.custine.com/display/ENV/Log4j+1.3+and+Tomcat5 [2] http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/tiny-webapp/ [3] http://www.qos.ch/logging/sc.jsp -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
--- Richard Sitze [EMAIL PROTECTED] wrote: Simon Kitching [EMAIL PROTECTED] wrote on 12/15/2004 10:18:44 PM: On Thu, 2004-12-16 at 13:53, Matt Sgarlata wrote: Simon Kitching wrote: I think this demonstrates a major issue. When using logging in an enterprise situation, the logging can be considered a critical part of the application. If you have heavy-duty monitoring systems watching for alerts from the software, and have sysadmins on call 24x7 to deal with issues, then for an application to fail to locate the correct logging libs or config files is a *failure* of the app. You don't want an app to start up, but then not be able to generate alerts if problems occur. But when using logging in other situations, logging is *not* a critical part, and should not cause an application to fail to start. The latter is the focus of commons-logging at the moment. And unfortunately as commons-logging has no *mandatory* configuration, it is not possible to add a fail-on-no-config option! So perhaps we could build two separate jars from mostly-common source code? Deploying the traditional commons-logging jar would do the be quiet on no config, while the enterprise commons-logging jar would do something like write message to STDERR then throw a runtime exception on no config? Why not just introduce a boolean parameter that says whether or not an inability to log is a failure? e.g. Log log = LogFactory.getLog(MyClass.class, true); It's not inability to log as such. It's whether finding no specific config info or underlying log implementation and therefore falling back to using java.util.logging (java=1.4) or org.apache.commons.logging.SimpleLog (java1.4) is allowed or not. In many cases, what you *want* an app to do if it can't find any specific logging config is simply to output ERROR and FATAL messages to stderr. This is what commons-logging will currently do if its discovery process finds nothing. I guess commons-logging *could* use a parameter such as you suggest to indicate explicit configuration of logging is mandatory. This would presumably mean detecting whether commons-logging.properties or the corresponding system properties have defined an explicit log implementation and config file for that implementation. I'm not sure, however, if the decision on whether logging is mandatory or not should be a compile-time one. It seems to me to be more like something the application *deployer* should choose. That then leads us to a circular reference: how do we know whether configuration is mandatory or not, if we can't find any configuration? The current proposal is: - configuration is always manditory. Doesn't mandatory configuration relieve us from needing to split commons-logging.jar into several pieces? I like the fact that I don't have to manage multiple commons-logging jar files and will be rather dissapointed if that is required in the future. I wouldn't mind having a simple properties file or a system property like -Dorg.apache.commons.logging.impl=log4j that tells commons-logging to use log4j. David - ambiguous [multiple] configurations located by a particular ClassLoader in the hierarchy requires an error to be logged [where is a reasonable question to ask]. How we determine which configs belong to which ClassLoaders is described in the original proposal. - in a core JCL jar, a configuration *must not* be packaged with JCL. - in a helper JCL jar, a configuration *must* be packaged, along with *one* JCL logger wrapper class. - multiple helper JCL jar files, one per logging impl wrapper we support. Pick the logger impl you want, grab the corresponding helper JCL jar file, and drop it into your application. Regards, Simon __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
--- Richard Sitze [EMAIL PROTECTED] wrote: David Graham [EMAIL PROTECTED] wrote on 12/16/2004 11:47:46 AM: snip/ The current proposal is: - configuration is always manditory. Doesn't mandatory configuration relieve us from needing to split commons-logging.jar into several pieces? I like the fact that I don't have to manage multiple commons-logging jar files and will be rather dissapointed if that is required in the future. I wouldn't mind having a simple properties file or a system property like -Dorg.apache.commons.logging.impl=log4j that tells commons-logging to use log4j. ok, without going back to review exactly what I said in an earlier note, I had in mind something like: commons-logging-core.jar - core interface factory class, NO config commons-logging.jar- core + all helpers, NO config commons-logging-impl.jar - core + ONE helper, ONE config With this scheme, I believe we can scrub the code from LogFactory that looks for an attempts to load specific logger impls [Log4J, Avalon, ?], and instead depend entirely on the config. So the configuration file is inside each impl. jar? What are you picturing the configuration will look like? I figured it would just be a simple declaration that you're using Log4J, java.util.logging, etc. If it is indeed that simple then I don't understand why we would need separate jars. We could keep the single commons-logging.jar but just use the application supplied configuration instead of relying on the LogFactory lookup code. David __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
