commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Sun, 19 Dec 2004 23:34:06 GMT
Curt Arnold <carnold@apache.org> 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 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.

Remember our users: component developers.  Admin logging is 
application/framework... much higher level I would think.

> 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.

No demands are being issued.  I do see your point.  Implementors are free 
to jump in.


> > 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.

I'm listening.  I don't understand what you are proposing yet.  Examples?


> > 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?

No.  Just the first note on the thread.  No votes, we are opening 
discussion.  Folks, we have to start somewhere... and this is it.

> >> 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?

JSR-47 is the first to come to mind. 

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development


---------------------------------------------------------------------
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