commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Jack" <aj...@TrySybase.com>
Subject RE: [Logging] Facade
Date Tue, 03 Jun 2003 16:02:36 GMT
	The existing Log implementation classes in c-l are already facades, so
	they go to some effort to make available the name of the class that called
	them.  However, this support is hard coded -- for example, see the
	log(Level,String,Throwable) method in
	org.apache.comming.logging,impl.JDK14Logger.

Both log4j and JDK1.4 logging allow facades (in different ways). Could not
Commons Logging (c-l) allow this as a "works if the underlying
implementation supports it" feature?

	Throwing another facade around the c-l facade seems like an odd thing to
	do in the first place.  But if you really want to do so, I'd investigate
	modifying the actual Log implementation class for whichever logging
	implementation you're using underneath.

It seems wrong to ever try to get at what is beneath c-l, that is for c-l to
deal with. I want this feature for users, not for myself alone, so I think
it needs to be built into c-l.

The primary reason I have for wrappering is:

(1) I've been asked to have a property switch on/off this modules logging,
to save folks getting too deep into logging configuration, and to optimise
for the 99% of the time folks do not want logging. Note: This includes
info/warn/errors.
(2) I need to fail safe if logging is not in the environment (so can't put
those classes into my code).
(3) I want to be able to move to the next best logging XYZ that comes out,
or whatever survives from the log4j/jdk14/c-l tussle.

So, any chance of facade in c-l?

regards,

Adam


Mime
View raw message