You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/08/02 19:00:54 UTC
LogKit Configurator
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!
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: LogKit Configurator
Posted by Peter Donald <do...@apache.org>.
On second thoughts how abaout something like
<targets>
<target name="file:dev/logs/classloader.log"/>
<target name="console:stderr"/>
<target name="db:my-table">
<username>dbsa</username>
<password>secret</password>
</target>
</targets>
On Fri, 10 Aug 2001 13:17, Peter Donald wrote:
> 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>
>
> 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
Re: LogKit Configurator
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Peter Donald <do...@apache.org>:
> On Mon, 13 Aug 2001 16:24, Giacomo Pati wrote:
> > Quoting Peter Donald <do...@apache.org>:
> > > On Mon, 13 Aug 2001 07:15, giacomo wrote:
> > > > Another think I need to know:
> > > >
> > > > A Logger is defined by its Category, Targets and Priority.
> > >
> > > I would say that a Logger is define by it's Hierarchy and it's
> category,
> > > much
> > > like a Class object is defined by it's ClassLoader and name.
> >
> > Ok, I know you can have separate logging hierarchies which all starts
> with
> > a Category of "" (rootLogger) but how does this relate to the LogKit
> > Configurator. I think we haven't specified having different
> hierarchies,
> > only categories, right?
>
> yup. I think that each Configurator should only configure one Hierarchy.
>
> Maybe we could provide the Hierarchy to the Configurator via a
> setHierarchy()
> method or something.
>
> > Do we have the need configuring different Hierarchies like
> >
> > <hierarchies>
> > <hierarchy name="foo"/>
> > <hierarchy name="bar"/>
> > </hierarchies>
> > <targets>
> > <target .../>
> > </targets>
> > <categories>
> > <category name="..." ... hierarchy="foo"/>
> > </categories>
>
> We could do that but I can not see any tangible benefit at this stage
> for
> doing something like that. Not sure really. Can you think of a reason
> why we
> would want configure multiple hierarchies from one configuration file?
No, I haven't had the need for different Hierarchies in a app yet. Did any
of you?
Giacomo
>
> >
> > Giacomo
> >
> > > > These three
> > > > things cannot be changed for a given Logger, right? Well, I know
> that
> > > > there are methods to change the Targets as well as the Priority
> for a
> > >
> > > given
> > >
> > > > Category but it makes no sense IIRC to have two Components which
> will
> > >
> > > have
> > >
> > > > the same Logger which differ in one of the aspects mentioned above
> > > > (Category, Target, Priority).
> > >
> > > yep. As soon as you change target or priority it changes
> target/priority
> > > for
> > > all components using that logger.
> > >
> > > > BTW: After browsing through the code for several month now (mainly
> > > > logkit and framework/excalibur) I have the feeling that specifying
> > > > everything possible as final (classes, member variables, method
> > > > arguments, local variables, and even catched exceptions) is good
> > > > programming practice, is it?
> > >
> > > Not sure - I have never seen any research on it. It is great when
> > > teaching
> > > students at introductory level because it encourages understanding.
> It
> > > can
> > > also be useful for some compilers/JITs as instead of recycling
> variables
> > > you
> > > create new variables (and make them final) which is easier for
> compilers
> > > to
> > > optimize. The other advantage is that it is *sometimes* easier to
> read
> > > as you
> > > don't have to search through code to verify that value hasn't
> changed.
> > >
> > > So I guess I think it is better but I don't know of any real proof
> ;)
> > >
> > > 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
>
> --
> 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
Re: LogKit Configurator
Posted by Peter Donald <do...@apache.org>.
On Mon, 13 Aug 2001 16:24, Giacomo Pati wrote:
> Quoting Peter Donald <do...@apache.org>:
> > On Mon, 13 Aug 2001 07:15, giacomo wrote:
> > > Another think I need to know:
> > >
> > > A Logger is defined by its Category, Targets and Priority.
> >
> > I would say that a Logger is define by it's Hierarchy and it's category,
> > much
> > like a Class object is defined by it's ClassLoader and name.
>
> Ok, I know you can have separate logging hierarchies which all starts with
> a Category of "" (rootLogger) but how does this relate to the LogKit
> Configurator. I think we haven't specified having different hierarchies,
> only categories, right?
yup. I think that each Configurator should only configure one Hierarchy.
Maybe we could provide the Hierarchy to the Configurator via a setHierarchy()
method or something.
> Do we have the need configuring different Hierarchies like
>
> <hierarchies>
> <hierarchy name="foo"/>
> <hierarchy name="bar"/>
> </hierarchies>
> <targets>
> <target .../>
> </targets>
> <categories>
> <category name="..." ... hierarchy="foo"/>
> </categories>
We could do that but I can not see any tangible benefit at this stage for
doing something like that. Not sure really. Can you think of a reason why we
would want configure multiple hierarchies from one configuration file?
>
> Giacomo
>
> > > These three
> > > things cannot be changed for a given Logger, right? Well, I know that
> > > there are methods to change the Targets as well as the Priority for a
> >
> > given
> >
> > > Category but it makes no sense IIRC to have two Components which will
> >
> > have
> >
> > > the same Logger which differ in one of the aspects mentioned above
> > > (Category, Target, Priority).
> >
> > yep. As soon as you change target or priority it changes target/priority
> > for
> > all components using that logger.
> >
> > > BTW: After browsing through the code for several month now (mainly
> > > logkit and framework/excalibur) I have the feeling that specifying
> > > everything possible as final (classes, member variables, method
> > > arguments, local variables, and even catched exceptions) is good
> > > programming practice, is it?
> >
> > Not sure - I have never seen any research on it. It is great when
> > teaching
> > students at introductory level because it encourages understanding. It
> > can
> > also be useful for some compilers/JITs as instead of recycling variables
> > you
> > create new variables (and make them final) which is easier for compilers
> > to
> > optimize. The other advantage is that it is *sometimes* easier to read
> > as you
> > don't have to search through code to verify that value hasn't changed.
> >
> > So I guess I think it is better but I don't know of any real proof ;)
> >
> > 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
--
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
Re: LogKit Configurator
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Peter Donald <do...@apache.org>:
> On Mon, 13 Aug 2001 07:15, giacomo wrote:
> > Another think I need to know:
> >
> > A Logger is defined by its Category, Targets and Priority.
>
> I would say that a Logger is define by it's Hierarchy and it's category,
> much
> like a Class object is defined by it's ClassLoader and name.
Ok, I know you can have separate logging hierarchies which all starts with a
Category of "" (rootLogger) but how does this relate to the LogKit Configurator.
I think we haven't specified having different hierarchies, only categories,
right?
Do we have the need configuring different Hierarchies like
<hierarchies>
<hierarchy name="foo"/>
<hierarchy name="bar"/>
</hierarchies>
<targets>
<target .../>
</targets>
<categories>
<category name="..." ... hierarchy="foo"/>
</categories>
Giacomo
>
> > These three
> > things cannot be changed for a given Logger, right? Well, I know that
> > there are methods to change the Targets as well as the Priority for a
> given
> > Category but it makes no sense IIRC to have two Components which will
> have
> > the same Logger which differ in one of the aspects mentioned above
> > (Category, Target, Priority).
>
> yep. As soon as you change target or priority it changes target/priority
> for
> all components using that logger.
>
> > BTW: After browsing through the code for several month now (mainly
> > logkit and framework/excalibur) I have the feeling that specifying
> > everything possible as final (classes, member variables, method
> > arguments, local variables, and even catched exceptions) is good
> > programming practice, is it?
>
> Not sure - I have never seen any research on it. It is great when
> teaching
> students at introductory level because it encourages understanding. It
> can
> also be useful for some compilers/JITs as instead of recycling variables
> you
> create new variables (and make them final) which is easier for compilers
> to
> optimize. The other advantage is that it is *sometimes* easier to read
> as you
> don't have to search through code to verify that value hasn't changed.
>
> So I guess I think it is better but I don't know of any real proof ;)
>
> 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
Re: LogKit Configurator
Posted by Peter Donald <do...@apache.org>.
On Mon, 13 Aug 2001 07:15, giacomo wrote:
> Another think I need to know:
>
> A Logger is defined by its Category, Targets and Priority.
I would say that a Logger is define by it's Hierarchy and it's category, much
like a Class object is defined by it's ClassLoader and name.
> These three
> things cannot be changed for a given Logger, right? Well, I know that
> there are methods to change the Targets as well as the Priority for a given
> Category but it makes no sense IIRC to have two Components which will have
> the same Logger which differ in one of the aspects mentioned above
> (Category, Target, Priority).
yep. As soon as you change target or priority it changes target/priority for
all components using that logger.
> BTW: After browsing through the code for several month now (mainly
> logkit and framework/excalibur) I have the feeling that specifying
> everything possible as final (classes, member variables, method
> arguments, local variables, and even catched exceptions) is good
> programming practice, is it?
Not sure - I have never seen any research on it. It is great when teaching
students at introductory level because it encourages understanding. It can
also be useful for some compilers/JITs as instead of recycling variables you
create new variables (and make them final) which is easier for compilers to
optimize. The other advantage is that it is *sometimes* easier to read as you
don't have to search through code to verify that value hasn't changed.
So I guess I think it is better but I don't know of any real proof ;)
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
Re: LogKit Configurator
Posted by giacomo <gi...@apache.org>.
On Sat, 11 Aug 2001, Peter Donald wrote:
> On Sat, 11 Aug 2001 20:16, giacomo wrote:
> > > interface TargetFactory
> > > {
> > > LogTarget createTarget( Configuration configuration );
> > > }
> >
> > You're right. As I've mentioned above with "full Selector/Component
> > specification" it clearly should be:
> >
> > interface TargetFactory /* extends Configurable */
> > {
> > LogTarget createTarget();
> > }
> >
> > Concrete Factories will implement Configurable like normal Components
> > will do.
>
> I think I would prefer the Configuration to be passed in. That way each
> factory could be a fly-weight - ie only one instance ever created. That way
> even if we have 20 different file log targets we will still only have one
> FileTargetFactory etc. Thoughts?
Ok.
Another think I need to know:
A Logger is defined by its Category, Targets and Priority. These three
things cannot be changed for a given Logger, right? Well, I know that
there are methods to change the Targets as well as the Priority for a given Category
but it makes no sense IIRC to have two Components which will have the
same Logger which differ in one of the aspects mentioned above
(Category, Target, Priority).
Please confirm.
Giacomo
BTW: After browsing through the code for several month now (mainly
logkit and framework/excalibur) I have the feeling that specifying
everything possible as final (classes, member variables, method
arguments, local variables, and even catched exceptions) is good
programming practice, is it?
>
> 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
Re: LogKit Configurator
Posted by Peter Donald <do...@apache.org>.
On Sat, 11 Aug 2001 20:16, giacomo wrote:
> > interface TargetFactory
> > {
> > LogTarget createTarget( Configuration configuration );
> > }
>
> You're right. As I've mentioned above with "full Selector/Component
> specification" it clearly should be:
>
> interface TargetFactory /* extends Configurable */
> {
> LogTarget createTarget();
> }
>
> Concrete Factories will implement Configurable like normal Components
> will do.
I think I would prefer the Configuration to be passed in. That way each
factory could be a fly-weight - ie only one instance ever created. That way
even if we have 20 different file log targets we will still only have one
FileTargetFactory etc. Thoughts?
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
Re: LogKit Configurator
Posted by giacomo <gi...@apache.org>.
On Sat, 11 Aug 2001, Peter Donald wrote:
> On Sat, 11 Aug 2001 01:05, giacomo wrote:
> > > 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 );
> > }
>
> I would prefer a full Configuration object be passed because some log targets
> will potentially have non-flat configuration (db target, jms target etc).
> Other than that I like. However I am not sure I know why you need to provide
> name to target if you specify factory class. Couldn't something simpler such
> as the following work? Or do you see targets as potentially creating multiple
> different types or something?
>
> interface TargetFactory
> {
> LogTarget createTarget( Configuration configuration );
> }
You're right. As I've mentioned above with "full Selector/Component
specification" it clearly should be:
interface TargetFactory /* extends Configurable */
{
LogTarget createTarget();
}
Concrete Factories will implement Configurable like normal Components
will do.
Giacomo
>
> 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
Re: LogKit Configurator
Posted by giacomo <gi...@apache.org>.
On Sat, 11 Aug 2001, Peter Donald wrote:
> On Sat, 11 Aug 2001 01:05, giacomo wrote:
> > > 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 );
> > }
>
> I would prefer a full Configuration object be passed because some log targets
> will potentially have non-flat configuration (db target, jms target etc).
> Other than that I like. However I am not sure I know why you need to provide
> name to target if you specify factory class.
To have a way the category section can refer to targets (name="file"
and ref="file" or as Berin proposed with id="..." and id-ref="...").
> Couldn't something simpler such
> as the following work? Or do you see targets as potentially creating multiple
> different types or something?
Not sure. Since the last changes to the logkit we have quite a lot of
different targets (recently all those Rotating targets based on the
files)
Giacomo
>
> interface TargetFactory
> {
> LogTarget createTarget( Configuration configuration );
> }
>
> 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
Re: LogKit Configurator
Posted by Peter Donald <do...@apache.org>.
On Sat, 11 Aug 2001 01:05, giacomo wrote:
> > 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 );
> }
I would prefer a full Configuration object be passed because some log targets
will potentially have non-flat configuration (db target, jms target etc).
Other than that I like. However I am not sure I know why you need to provide
name to target if you specify factory class. Couldn't something simpler such
as the following work? Or do you see targets as potentially creating multiple
different types or something?
interface TargetFactory
{
LogTarget createTarget( Configuration configuration );
}
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
Re: LogKit Configurator
Posted by Peter Donald <do...@apache.org>.
On Sat, 11 Aug 2001 05:21, giacomo wrote:
> 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).
sounds good.
> 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).
Personally I would separate it into two classes, a LogManager and a
LogConfigurator. The LogManager will contain mapping of name to specific log
components (ie a map between name and logTarget, another map between name and
formatter). It would also contain reference to hierarchy.
The LogConfigurator will read a config source and manage the factorys. It
will inject all the log components created into manager. It would also
perform mapping between Loggers and priority/logtargets as necessary.
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
Re: LogKit Configurator
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
>
> 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?
It satisfies mine, and I believe it satisfies Cocoon's needs as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKit Configurator
Posted by giacomo <gi...@apache.org>.
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
Re: LogKit Configurator
Posted by giacomo <gi...@apache.org>.
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
Re: LogKit Configurator
Posted by Peter Donald <do...@apache.org>.
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>
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
Re: LogKit Configurator
Posted by Berin Loritsch <bl...@apache.org>.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKit Configurator
Posted by giacomo <gi...@apache.org>.
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.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKit Configurator
Posted by giacomo <gi...@apache.org>.
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.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org