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.
IThere are a couple of issues with the resource bundle proposals thathave 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 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. If this is making architectural demands, it would be right to have the implementors feedback.
Log4J is not the only logger out there. There are multitudes of loggers
that we would prefer to hand the messageID and parameters to. This allows
the messages to be distributed to the different handlers, as I think you
suggest earlier, and translated to a multitude of different locales if
necessary.
No, but it is a significant one and is also under the ASF. It would be a undesirable if Jakarta Common Logging makes architectural demands that log4j can't accept, especially if a reasonable compromise could be achieved.
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?
Internationalization has been a sporadic topic of discussion in the log4j and derivatives' mailing lists, but doesn't appear to be a major concern in our user base. I think a localizing layout would be a nice
It's a concern to SOME user bases, and we have requirements. We believe
that there is benefit for manifesting them in the open source community.
When Log4J supports localized messages, with I'm sure all sorts of
interesting features under the covers, components written to JCL will be
ready to migrate to that.
I wasn't discounting the validity of the concern and it has been an interest of mine. I was stating that log4j is immature in this area since it hasn't been a major concern of our user community.
Meanwhile, the loggers that already support it, in varying degrees, will
be better supported by JCL.
Any list of reference implementations?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
