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]
