avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mircea Toma" <mircea.t...@calgary.qcdata.com>
Subject Re: LogKitManagement
Date Tue, 21 Aug 2001 17:35:21 GMT

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?


----- Original Message -----
From: "Giacomo Pati" <giacomo@apache.org>
To: <avalon-dev@jakarta.apache.org>
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
> 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"
>     <factory type="property-filter"
>     <factory type="servlet"
>   </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
> 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
> 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
> Contextualizable) and gets the Configuration object located at the
> 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
> interface is also needed:
> public interface LogTargetFactoryManageable
>     void
>         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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@ja

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

View raw message