commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: [logging] ECL: Log interface vs. abstract class
Date Sun, 26 Dec 2004 23:15:10 GMT
Simon Kitching <> wrote on 12/25/2004 06:25:51 

> On Mon, 2004-12-20 at 18:28 +0100, Ceki Gülcü wrote:
> > In  my last  message, I  failed to  emphasize the  brittleness  of the
> > "break  into  interfaces" hypothesis.   Even  if  at  a high-level  of
> > abstraction two  APIs perform the same  task, this does  not mean that
> > they can be abstracted away by a thin facade (or bridge). For example,
> > all the attempts  made at bridging X.25 and  TCP/IP, both well defined
> > and  stable protocols,  have  failed miserably,  even  if both  stacks
> > supposedly fit into layers 1-4 of the 7 layer OSI network model.
> I quite agree with this. 
> And I don't think the approach of providing multiple optional interfaces
> in commons-logging to support "advanced" features that various logging
> libraries implement is useful either. As I've written in previous
> emails, I do *not* like the idea of an application failing to start
> because an appropriate logging implementation is not present.
> I think commons-logging should be a *simple* API that abstracts only the
> *basic* functionality of logging. The current API is fine; log strings
> at various priority levels to a single named category. Any reasonable
> log implementation will be able to provide a sane mapping for these
> concepts.
> But I don't think it is worth trying to extend JCL much beyond this. As
> Ceki says, logging libraries can provide widely varying features and it
> is not productive to try to map these to portable APIs.

Agreed in general, but there are some directions that are reasonable to 
follow.  i18n is one.

> JCL does a very useful job for jakarta-commons libraries: provide a
> means for the commons libraries to implement logging without enforcing a
> logging implementation on the larger app which uses the library. Note
> that the kind of log messages generated by commons components are of
> course implementation-related and are therefore aimed at the *developer*
> not the user. For this reason, i18n support is not terribly useful for
> commons component logging.

Not true.  In particular, the Message level API's [fatal, error, warn, 
info] may be targeted towards either end users, or [international] 
developers using the component.  In either case, i18n is useful.

For example, HTTPSender reflects an edge component to which customers are 
directly exposed.  Failure to open ports, dropped socket connections... 
any socket, TCP/IP, or HTTP error is of interest to the end user, not just 
the developer using HTTPSender.  Clearly, the developer would very much 
prefer that the users *resolve* these problems [in their native languages] 
rather than have the user contact the developer.  And the component 
developer would prefer that the app developer understand how/if the API's 
are being misused, again in their natural language if possible.

There is a need for i18n logging, and IBM's recognition of this need is 
much broader than *my* immediately daily chores.  I'm just a spokeman here 
folks: the proposal is submitted on behalf of IBM, not IBM WebSphere 
[J2EE].  IBM and many other global companies are involved with a number of 
open source projects.  Internationalization IS becoming more and more 
important for our customers.  And our customers using open source are your 

The IBM community also feels *strongly* that we must NOT fragment the 
logging community any further than it already is, strong alignment with 
JCL is necessary.

> However I'm not convinced that for *applications* (rather than
> libraries) it is sensible to use JCL at all; why not just pick a
> concrete logging implementation and use that? You get all the necessary
> features, and apps can deploy whatever logging implementation they want.

Agree 100%.  NO question.  This is fundamental to JCL's goals.

> The only awkward situation is container frameworks like J2EE. In this
> case, you may want logging to be redirected to the container's logging
> implementation so that logging from all apps within the framework is
> treated consistently. I can see some kind of common API cabable of
> generating i18n messages being useful here. 
> After all the discussion on logging recently, I'm coming to the
> conclusion that Richard's original proposed features (i18n, discovery
> changes) should *not* be included in JCL. None of these features help
> commons components with their logging requirements, and these features

Disagree strongly.  And I believe there are others would also disagree.

> *are* going to make JCL significantly more complex and controversial. It
> would be better to start a separate project. If this project can
> successfully resolve the issues then maybe it could be merged back in to
> JCL.
> To summarize, my (non-binding) votes are:
>   -1 to adding extra *optional* features to JCL that fail if the
>     "discovered" logging implementation doesn't suport them. This
>     includes Richard's EnterpriseLog class, and Matt Scarlata's
>     proposals too.
>   -1 to *mandatory* configuration for JCL
>   +1 to keeping JCL as a least-common-denominator logging API that
>     can be used for commons components.
> Regards,
> Simon
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Richard A. Sitze
IBM WebSphere WebServices Development

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message