avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: LogKitManagement
Date Tue, 21 Aug 2001 16:50:25 GMT
Giacomo Pati wrote:
> Dear all
> I've almost finished the LogKitManagement and I'd like to express the
> abstractions I've choosen. I'll commit the sources into the scratchpad sometimes
> this evening (Europe) when I can tested then a bit more extensively.

So far, it looks good.

> First the configuration syntax:
> <logkit>
>   <!-- The definitions of the LogTargetFactories
>        This could well be put into an own configuration file somewhere
>        into the source tree and be loaded as a resource via classloader
>        but I've choosen to have it here for now.
>        The type attribute denotes the name of the elements in the
>        targets section
>   -->
>   <factories>
>     <factory type="file"
>       class="org.apache.avalon.excalibur.logger.factory.FileTargetFactory"/>
>     <factory type="property-filter"
>       class="org.apache.avalon.excalibur.logger.factory.FilterTargetFactory"/>
>     <factory type="servlet"
>       class="org.apache.avalon.excalibur.logger.factory.ServletTargetFactory"/>
>   </factories>

There are a couple of ways we can approach this.  This is good to start with,
and I agree, the LogTargetFactories can be specified as a classloader resource.
It is good to have the markup available here as well so that users can extend
the factories with their own.  I would have a Hierarchical factory definition
like the RoleManager in Excalibur.component.  That way, we can specify the
base definitions via classloader, and then we can suppliment or override the
factories with other ones:

<factories href="logfactories.factory"/>

or even:

<factories href="logfactories.factory">
  <factory type="bar"

The order of precedence would be:

1) <factory/> elements
2) <factories href="location.factories"/>
3) classloader

If each one of those resources contained the "foo" factory, the one in the
logkit file wins.

>   <targets>
>     <file id="root">
>       <filename>logs/main.log</filename>
>     </file>
>     <file id="classloader">
>       <filename>logs/classloader.log</filename>
>     </file>
>     <file id="foo">
>       <filename>logs/foo.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>
>     <category name="foo" log-level="INFO">
>       <log-target id-ref="foo"/>
>     </category>
>   </categories>
> </logkit>

This all looks good.

<skip excellent overview that should be made into an xdoc>

> One last step that is to be made is enable the LogKitManagement into the
> ExcaliburComponentManager by use of "magic attributes" like logger="category" on
> the component definition syntax. Would you encourage me to put the classes
> modified for it into the scratchpad area as well?
> Thought and comments appreciated.

This so far is exellent.  If you already have made changes to the ExcaliburComponentManager
et. al. to allow for the LogKitManager, then I say continue the changes there.  If
you have created a new ComponentManager that extends ExcaliburComponentManager then
I would have those changes remain in the new ComponentManager.

Once we agree that the overall LogKitManager approach (wich I like) is the way
to go, I would like the ComponentManagers merged.

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

View raw message