commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: Enterprise Logging - API Proposal
Date Tue, 14 Dec 2004 16:45:31 GMT
Matt Sgarlata <> wrote on 12/13/2004 
07:05:31 PM:

> Ah-hah, I understand our main disconnect now: I'm thinking in terms of 
> configuring logging for an overall application and you're thinking in 
> terms of components.  So now at least I understand where you're coming 

A step forward... :-)

> from, but I think it's time for us to agree to disagree :)  I think 

Give me time ;-)  The proper role and position for commons-logging is up 
to the individual developer.  That said, within the commons-logging 
development community it is a fundamental premise that commons-logging's 
mere existence is justified ONLY as an enabler for logging in components 
that must be developed independently from a single application/framework.

> someone said earlier that perhaps part of your proposal would fit better 

> in Log4J or in some other logging component.  In any case, thanks for 
> spending so much time discussing your ideas with me.  More comments 

If you are developing applications or frameworks, and you want Log4J 
function, then go use Log4J.  End of story, commons-logging has little/no 
value to you.  If your application integrates components that use JCL 
[Jakarta Commons Logging], then bind JCL to Log4J in your hosting 
environment, and you are ready to move forward.

> Richard Sitze wrote:
> >Now, were does the *component* developer 'place' this content?  I claim 
> >need a standard approach for this, based on the 'resource bundle name' 
> >parameters we pass into the 
> >EnterpriseLogFactory.getEnterpriseLog(loggerName, resourceBundleName);
> >
> > 
> >
> I think instead of the resourceBundleName we could optionally pass in a 
> MessageSource implementation.  That way if internationalization for a 
> component was dependent on a particular implementation, it could be 
> passed in.  If no MessageSource was passed in, we could still try 
> java.util.ResourceBundle and the underlying logging implementation.  I'm 

> sure we disagree on this point, but I just wanted to through this idea 
> out there :)

Not a bad idea.  With every level of flexibility we gain more complex 
code.  I would resist this at this moment because it either  a) introduces 
a 3rd party dependency on MessageSource, b) introduces yet more code to 
develope for commons-logging (keep it simple).

In addition, it also requires the user to new up and manage the 
MessageSource, yet one more ticky-mark on the check-list of new work to 
do.  There is admittedly a balance between "programmer work" and 
"function".  Everyone is going to have their own opinions on where the 
right place is to strike this balance.

So far, there are proposals for new API's.. but we've tried to keep new 
Interfaces, and implementations behind them, to a bare minimum (ELog & 

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