commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From simon <s_kitch...@paradise.net.nz>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Fri, 10 Dec 2004 00:29:12 GMT
On Fri, 2004-12-10 at 09:40, Matt Sgarlata wrote:
> Richard Sitze wrote:
> 
> >          - For message level logging, support globalized
> >            variants on the new EnterpriseLog interface:
> >
> >            info(Class callingClass,
> >                 String methodName,
> >                 String messageID);
> >
> >            info(Class callingClass,
> >                 String methodName,
> >                 String messageID,
> >                 Object messageParam);
> >
> >            info(Class callingClass,
> >                 String methodName,
> >                 String messageID,
> >                 Object[] messageParams);
> >
> >            same for warn, error, fatal.
> >  
> >
> I don't understand why the calling class and method name are included.  
> Can't this information simply be retrieved from the current stack trace 
> by the underlying logging implementation?  I would think a cleaner 
> approach would be one of the alternatives below (note we have to avoid 
> conflicting with the existing info, warn, error, etc. methods)
> 
> info(String defaultMessage, String messageKey);
> info(String defaultMessage, String messageKey, Object param);
> info(String defaultMessage, String messageKey, Object[] params);

Unfortunately, when optimisation has been applied to java code, class
and method information is not always available via stack traces. I
expect that if pre-compilation (eg gcj) has been applied then the
problem will be even worse. This is (presumably) why the JSR-47
java.util.logging API takes class/method parameters.

> Also, I don't want to type
> 
> private static final EnterpriseLog log = 
> EnterpriseLogFactory.getClass(MyVeryLongClassName.class);
> 
> I would think this new functionality could be added directly to the 
> existing Log and LogFactory classes.

Log is an interface. Because of this, it is not possible to add methods
to it without breaking binary compatibility. The proposed approach of
adding the EnterpriseLog interface (and associated factory) is an
attempt to "enhance" the existing log library rather than break
compatibility.

Regards,

Simon


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