commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject RE: [logging] Enterprise Common Logging... dare we say 2.0?
Date Sat, 11 Dec 2004 04:07:13 GMT
On Sat, 2004-12-11 at 15:24, Noel J. Bergman wrote:
> It disturbs me that what seems to me to be a reasonable and small set of
> requirements --- along with what appears to have been considerable
> forethought based upon real world issues, and experiences supporting many
> developers --- appears to be discounted a bit too out of hand.  I hope my
> perception is wrong.
> Does anyone really dispute the requirement to support localization for log
> messages or the additional JSR-mandated logging requirements?  If not, then
> let's work constructively towards satisfying the requirements.  And not by
> relying upon some IDE's tooling.

I am quite sure the IBM Websphere team have a good idea of what J2EE
environments need in terms of logging. And I believe their proposal
should be given serious consideration.

The question is whether the implementation of those requirements is a
good fit for commons-logging or not. Commons-logging is used in many
environments that the Websphere team may *not* be interested in.

I will dispute localisation of log messages if this:
(a) forces commons-logging to terminate support for underlying logging
implementations that don't provide this feature, or
(b) forces commons-logging to include a "configuration layer" that it
didn't previously need so that it can implement i18n within

In neither case would this mean the requirements are wrong; it just
means (IMHO) that the implementation shouldn't be in commons-logging.
(Note: it's not clear to me whether IBM's proposal has problems (a) or
(b) or not).

My initial thoughts were that i18n support was a good idea. But the more
I think about it, the more concerns I have about whether these can be
included in commons-logging without making it unfit for purposes it is
currently used for.

I also dispute adding APIs to commons-logging if they encourage poor
software design, just because JSR-47 has that API. I've been convinced
by the arguments put forward in this thread that explicit enter/exit
methods taking class+method strings should not be encouraged because of
that (in addition to the practical issue of what to do with logging
implementations that don't have methods taking class/method names).

I look forward to seeing further discussion on i18n support + logging
config, and would be very happy to see improvements made to JCL - as
long as they fit.



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

View raw message