commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@optonline.net>
Subject Re: [logging] Need interface...
Date Wed, 03 Apr 2002 17:17:20 GMT
On 4/3/02 11:59 AM, "Craig R. McClanahan" <craigmcc@apache.org> wrote:

> 
> 
> On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
> 
>> Date: Wed, 03 Apr 2002 08:46:07 -0500
>> From: Geir Magnusson Jr. <geirm@optonline.net>
>> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
>> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
>> Subject: [logging]  Need interface...
>> 
>> So what I propose is to add an interface 'LogUser' or something like it (we
>> can quibble about the name...)
>> 
>>  public interface LogUser
>>  {
>>     public void setCommonsLogger(Log log)
>>  }
>> 
> 
> I can see why some people might like to have a log setter method like this
> (rather than letting the log-using component define its own log name).
> What I don't see (yet?) is the value of having this interface defined in
> commons-logging itself.  Isn't the decision to need/use this made on a
> component by component basis anyway?  Don't the cooperating components
> have to know about it in order to call this method, whether its an
> o.a.c.l.LogUser interface or just a public property setter?

I know I am explaining this badly... Let me take another wack.

The idea is that in some kind of app/framework/servlet (from now on :=
'app'), the app might setup aggregated logging for all of the components to
use, and it would be nice if there was a standard indicator for
components/tools to use to indicate compatibility.

As components are added dynamically, the app sees if they implement the
*standard* interface o.a.c.l.LogUser, which flags to the app that the
component can log to a o.a.c.l.Log interface.  The app then invokes the
setCommonsLogger() method on the component with a Log-implementing object,
and then the component can log happily ever after.

If that doesn't make it clear, let me illustrate with a  use case.

Imagine a system, like a webapp, where you can define a set of tools (java
class names) that the servlet will instantiate and make available to the
view layer to use when templating.  For each tool that it reads from the set
(say a config file with class names...), it can check to see if that class
implements the LogUser interface, indicating that it wants to and can log
using o.a.c.l.Log.  So the servlet then just passes in something shaped like
a Log.

Our hope, in our Velocity tools project,  is that we don't have to reinvent
the wheel - if we support o.a.c.l.Log as the interface to the tools that log
(wrapping around whatever - the servlet logger, the Velocity logger, it
doesn't matter) - and we invent and promote a standard way to indicate
desire and compatibility that comes from o.a.c.l we donĀ¹t have to invent a
new, Velocity-tool-specific way to indicate loggyness to the
servlet/toolmanager..

Clearer?

geir

-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting
"We will be judged not by the monuments we build, but by the monuments we
destroy" - Ada Louise Huxtable


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


Mime
View raw message