commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Sat, 18 Dec 2004 20:52:02 GMT

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


Mime
View raw message