On Tue, 21 Aug 2001, Berin Loritsch wrote:
> 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.
Ok, would be easy to extend (as it is already realized in the
RoleManagement
>
> > <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>
Yes, I thought to write it down to have a start for later on :)
>
> > 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.
I haven't started so far but I tend to do it directly in the src/java
tree because it is not a complex thing to achieve.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
