Hi, I thought that the purpose of LogKitManagement was to avoid the circular depedencies Avalon<->LogKit. If you still use Configurable, Loggable..... why not use a ComponentManager/Selector to do the same job?
Mircea ----- Original Message ----- From: "Giacomo Pati" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, August 21, 2001 9:20 AM Subject: LogKitManagement > 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. > > 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> > > <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> > > The first abstraction is the LogKitManager: > > public interface LogKitManager > Logger getLogger( String categoryName ); > > There is a implementation named DefaultLogKitManager which is the only class > exposed to clients. As a convenient a additional interface is introduced for the > ComponentManager (stolen from the role management system) which states that a > class is willing to get a LogKitManager: > > public interface LogKitManageable > void setLogKitManager( LogKitManager logmanager ); > > This method has to be called before the configure method but after the > contextualize method. > > The DefaultLogKitManager is Configurable (as well as Loggable [the > initial default logger] and Contextualizable [to pass along for ie. > ServletLogTarget]) and gets a Configuration object as expressed in the logkit > xml syntax above. This DefaultLogKitManager then uses a object of type > > public interface LogTargetFactoryManager > LogTargetFactory getLogTargetFactory( String factoryName ); > > The DefaultLogTargetFactoryManager is Configurable (as well as Loggable and > Contextualizable) and gets the Configuration object located at the <factories> > element. It will instanciate the concrete factories into a map keyed by the type > attribute. So we are at the LogTargetFactory abstraction which is: > > public interface LogTargetFactory > LogTarget createTarget( Configuration configuration ) > throws ConfigurationException; > > I've initially written a FileTargetFactory (given the fact that this is the one > most in flux these days it is absolutely minimum). I've found that the following > interface is also needed: > > public interface LogTargetFactoryManageable > void LogTargetFactoryManager( > LogTargetFactoryManager logTargetFactoryManager ); > > This eases writing factories which acts like decorators (AsyncLogTarget, > PriorityFilter) and thus need a LogTargetFactoryManager to create the > decorated > LogTargets which are embeded in the configuration of them (see > <priority-filter> > above). > > After initializing the LogTargetFactoryManager a LogTargetManager > > public interface LogTargetManager > LogTarget getLogTarget( String targetId ); > > is created. The implementation DefaultLogTargetManager is, you guess it, > Configurable (as well as Loggable and Contextualizable). The Configuration > object is the <targets> element in the xml syntax and is put into a map keyed > by > the id attribute of the target element. It is also LogTargetFactoryManageable > to > be able to create the LogTargets. > > The last step of the DefaultLogKitManagers configure method is to create the > actual categories based on the categories elements content. It does it as the > syntax will show in a recursive way populating the Loggers retrieved by > Hierarchy.getDefaultHierarchy().getLoggerFor( full_category ) with the > denoted > LogTargets from the LogTargetManager and keeps the created loggers in > a map keyed by category. > > After that the LogKitManager is ready to be asked for Loggers. For now if it > cannot find the requested logger for a category the default logger is > returned > (the one passed in via Loggable). > > 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. > > Giacomo > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] karta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
