commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: [Logging] Facade
Date Tue, 03 Jun 2003 16:59:35 GMT


On Tue, 3 Jun 2003, Adam Jack wrote:

> Date: Tue, 3 Jun 2003 10:02:36 -0600
> From: Adam Jack <ajack@TrySybase.com>
> Reply-To: Jakarta Commons Users List <commons-user@jakarta.apache.org>,
>      ajack@TrySybase.com
> To: 'Craig R. McClanahan' <craigmcc@apache.org>,
>      'Jakarta Commons Users List' <commons-user@jakarta.apache.org>
> Subject: RE: [Logging] Facade
>
> 	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.

I don't see how wrapping the configuration of the underlying logging
implementation has anything to do with wrapping the log calls themselves,
but ok.

> (2) I need to fail safe if logging is not in the environment (so can't put
> those classes into my code).

You mean if the C-L classes are not in your code?  (C-L already defaults
to SimpleLog writing to System.out if neither JDK 1.4 or Log4J 1.2 can be
found.)  Sounds like you might want to think about turning your facade
into direct calls on the underlying logging system, instead of trying to
go through C-L as well.  C-L isn't really buying you anything.

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

You've got the source ... go ahead and propose a patch :-).

For my purposes, C-L is already a facade that already exposes the method
name of whoever called it.  Double facading (as you propose) is not
something that I'm going to spend any coding time on.

>
> regards,
>
> Adam

Craig


>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>

Mime
View raw message