avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: LogKit Configurator
Date Fri, 10 Aug 2001 19:21:29 GMT
On Fri, 10 Aug 2001, giacomo wrote:

Ok, lets summarize:

The goal:

	Enable configurability of the Logger a Component
	will receive by the ComponentMananger.

Proposed is a magic attribute logger (same approach take for the
pool-min, pool-max attributes to Poolable Components) that references
the logger to use:

   <component role="MyComp" class="..." logger="file"/>

A possible solution seems to be a similar approach take for the roles
definitions (RoleManager).

So the LogKit configuration file (see proposals below) will be fed into
a LogKitManager (Configurable). This LogKitManager creates the
Categories, LogTargets, and Filters. To enable the specified
LogTargetFactories to create LogTargets like ServletLogTarget a Context
object might be needed so the LogKitManager must and the
LogTargetFactories could be Contextualizable. All classes mentioned so
far will be Loggable to report failures during setup. The Logger will be
the one passed in by the client class as usual (probabbly the root
logger).

After initialisation of this LogKitManager it is passed to the
ExcaliburComponentManager (setLogKitManager). This is optional. The
ExcaliburCM must be extended to interpret the magic attributes mentioned
above in case a LogKitManager was set. The magic attribute denotes the
logger to used received from the LogKitManager and passed to the
Component in question.

Does this satisfy all your needs you have?

Giacomo


> On Fri, 10 Aug 2001, Peter Donald wrote:
>
> > On Fri, 10 Aug 2001 06:49, Berin Loritsch wrote:
> > > giacomo wrote:
> > > > On Thu, 2 Aug 2001, Berin Loritsch wrote:
> > > > > Projects like Cocoon need a way to easily configure
> > > > > the all the LogTargets and Categories that are associated
> > > > > with LogKit.  This will facilitate having the type of
> > > > > Log Messages you want where you want them.  It will also
> > > > > help limit the ammount log messages that are currently
> > > > > in cocoon.log.
> > > > >
> > > > > The LogKit Configurator would be a generic enough component
> > > > > to include in Avalon Excalibur--but the direct benefit would
> > > > > be for Cocoon and other private projects.  It is something
> > > > > I have been wanting for a while--but have not had the time
> > > > > to create.
> > > > >
> > > > > If anyone has the spare time to create this Component, please
> > > > > let me know.  I would like to see it sooner than later!
> > > >
> > > > It seems you have already made some thoughts about it. Can you explain
> > > > them here? As I'm writing the ExcaliburTestCase where you mentioned
> > > > exacly this I might have some time to acomplish this as well.
> > >
> > > My thoughts have been along the lines of a configuration format that
> > > separates the LogTargets from the Loggers categories:
> > >
> > > <logkit>
> > >   <targets>
> > >     <file id="root">
> > >       <filename>dev/logs/main.log</filename>
> > >     </file>
> > >     <file id="classloader">
> > >       <filename>dev/logs/classloader.log</filename>
> > >     </file>
> > >     <priority-filter id="servlet" log-level="ERROR">
> > >       <servlet/>
> > >     </priority-filter>
> > >   </targets>
> > >
> > >   <categories>
> > >     <category name="cocoon" log-level="INFO">
> > >       <log-target id-ref="root"/>
> > >       <log-target id-ref="servlet"/>
> > >
> > >       <category name="classloader" log-level="DEBUG">
> > >         <log-target id-ref="classloader"/>
> > >       </category>
> > >     </category>
> > >   </categories>
> > > </logkit>
> > >
> > > I am not really set on anything though.
> >
> > Another way I have about doing it is something like
> >
> > <targets>
> >   <target name="file:dev/logs/classloader.log"/>
> >
> >   <target name="console:stderr"/>
> >
> >   <target name="db:my-table">
> >     <parameter name="username" value="dbsa"/>
> >     <parameter name="password" value="secret"/>
> >   </target>
> >
> > </targets>
>
> And the next step would be:
>
> <targets>
>   <target name="file" class="logtarget.FileFactory">
>     <parameter name="filename" value="dev/logs/classloader.log/>
>   </target>
>
>   <target name="console" class="logtarget.FileFactory">
>     <parameter name="device" value="stderr"/>
>   </target>
>
>   <target name="db" class="logtarget.DBFactory">
>     <parameter name="table" valuer="my-table"/>
>     <parameter name="username" value="dbsa"/>
>     <parameter name="password" value="secret"/>
>   </target>
>
> </targets>
>
> and thus we have a full Selector/Component specification. So the
> TargetFactory interface can be reduced to
>
> interface TargetFactory
> {
>   LogTarget createTarget( String name,
>                           Parameter parameters );
> }
>
> Giacomo
>
> >
> > Then have a place where factorys could be registered. Factorys would look like
> >
> > interface TargetFactory
> > {
> >   LogTarget createTarget( String protocol,
> >                           String target,
> >                           Parameter parameters );
> > }
> >
> > final LogTarget target =
> >     factory.createTarget( "file", "/var/log/mylog.log", null );
> >
> >
> > Cheers,
> >
> > Pete
> >
> > *-----------------------------------------------------*
> > | "Faced with the choice between changing one's mind, |
> > | and proving that there is no need to do so - almost |
> > | everyone gets busy on the proof."                   |
> > |              - John Kenneth Galbraith               |
> > *-----------------------------------------------------*
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message