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"
class="org.apache.avalon.excalibur.logger.factory.BarTargetFactory"/>
</factories>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
