You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Giacomo Pati <gi...@apache.org> on 2001/08/21 17:20:25 UTC
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 setLogTargetFactoryManager(
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@jakarta.apache.org
Re: LogKitManagement
Posted by Peter Donald <do...@apache.org>.
On Wed, 22 Aug 2001 19:34, Giacomo Pati wrote:
> > > 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.
> >
> > I like (1) and (3) ;)
>
> This means you don't like to extend the system to have the ability to
> specify an additional config file that contains factory definitions? So
> this would mean that "take the one provided by the system (as classloader
> reasource) or write your own definition right here into the config file
> (and not in an additional separate file), right?
Well as I see it, you need to have factory classes in ClassPath for it to
work. In which case the ClassLoader is already loaded and should have all the
information in it.
> > How about any Jar that contains LogTarget Factories must create a file
> >
> > META-INF/services/org.apache.avalon.excalibur.logger.LogFactory.xml
>
> Hm.., I think I need to study all thos jar/META stuff 'caus I'm not
> familiar with thos features.
I think it is documented in jdk1.3 docs under manifests or something. Heres
some sample code
final ClassLoader classLoader = getClass().getClassLoader();
final Enumeration enum =
classLoader.getResources( Deployment.DESCRIPTOR_NAME );
while( enum.hasMoreElements() )
{
final URL url = (URL)enum.nextElement();
parser.parse( url.toString() );
getLogger().debug( "deploying " + url );
deployFromDescriptor( handler.getConfiguration(),
classLoader, url );
}
However instead of reploying from descriptor you would be registering
factorys from descriptor ;)
> > ...snip...
> >
> > > This all looks good.
> > >
> > > <skip excellent overview that should be made into an xdoc>
> >
> > +1000
>
> Thank you all :)
no ... thank u ;)
--
Cheers,
Pete
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Peter Donald <do...@apache.org>:
> On Wed, 22 Aug 2001 02:50, Berin Loritsch wrote:
> > 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.
>
> I like (1) and (3) ;)
This means you don't like to extend the system to have the ability to specify an
additional config file that contains factory definitions? So this would mean
that "take the one provided by the system (as classloader reasource) or write
your own definition right here into the config file (and not in an additional
separate file), right?
> How about any Jar that contains LogTarget Factories must create a file
>
> META-INF/services/org.apache.avalon.excalibur.logger.LogFactory.xml
Hm.., I think I need to study all thos jar/META stuff 'caus I'm not familiar
with thos features.
> that contains all references available. This would mean that we no
> longer
> need (1), (2) or (3) and it wouls still be very flexible (besides being
> standard with other toolkits). Thoughts?
As stated above, i cannot speak on this because of lack knowledge ATM.
> ...snip...
> > This all looks good.
> >
> > <skip excellent overview that should be made into an xdoc>
>
> +1000
Thank you all :)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by Peter Donald <do...@apache.org>.
On Wed, 22 Aug 2001 02:50, Berin Loritsch wrote:
> 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.
I like (1) and (3) ;)
How about any Jar that contains LogTarget Factories must create a file
META-INF/services/org.apache.avalon.excalibur.logger.LogFactory.xml
that contains all references available. This would mean that we no longer
need (1), (2) or (3) and it wouls still be very flexible (besides being
standard with other toolkits). Thoughts?
...snip...
> This all looks good.
>
> <skip excellent overview that should be made into an xdoc>
+1000
--
Cheers,
Pete
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
>
> On Tue, 21 Aug 2001, Berin Loritsch wrote:
>
> > 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.
I agree. It's a low risk addition.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by giacomo <gi...@apache.org>.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by Berin Loritsch <bl...@apache.org>.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by Peter Donald <do...@apache.org>.
On Wed, 22 Aug 2001 19:41, Giacomo Pati wrote:
> > I am not sure what you mean by this. The Hierarchy and Logger should
> > create
> > Loggers that don't exist but are asked for. Maybe I missed something in
> > explanation ???
>
> I wasn't sure how to handle the following issue. If a client specifies a
> logger (logger="foo.bar") in a component configuration file which doesn't
> exist the Hierarchy.getLoggerForName will return a valid Logger but IIRC
> that logger will not have any LogTargets set, right?
Sortof. It will have LogTargets but it will be those inherited from parent
logger ("foo"), If "foo" is not defined then it will inherit from root logger.
>Thus I've decided to
> return the default Logger passed in at creation time. The alternative would
> be to raise an Exception to signal "no Logger for that category
> configured".
I would prefer to just return "foo.bar".
--
Cheers,
Pete
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Peter Donald <do...@apache.org>:
> woooohoooooooo!
:)
>
> Sounds great. Also a lot of potential xml/javadocs in that description
> ;)
I've taken care to write more that only minimal javadocs. Sure, my explanatory
mail can be used to create a xdoc for the LogKitManagement.
>
> On Wed, 22 Aug 2001 01:20, Giacomo Pati wrote:
> > 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).
>
> I am not sure what you mean by this. The Hierarchy and Logger should
> create
> Loggers that don't exist but are asked for. Maybe I missed something in
> explanation ???
I wasn't sure how to handle the following issue. If a client specifies a logger
(logger="foo.bar") in a component configuration file which doesn't exist the
Hierarchy.getLoggerForName will return a valid Logger but IIRC that logger will
not have any LogTargets set, right? Thus I've decided to return the default
Logger passed in at creation time. The alternative would be to raise an
Exception to signal "no Logger for that category configured".
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by Peter Donald <do...@apache.org>.
woooohoooooooo!
Sounds great. Also a lot of potential xml/javadocs in that description ;)
On Wed, 22 Aug 2001 01:20, Giacomo Pati wrote:
> 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).
I am not sure what you mean by this. The Hierarchy and Logger should create
Loggers that don't exist but are asked for. Maybe I missed something in
explanation ???
--
Cheers,
Pete
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by giacomo <gi...@apache.org>.
On Tue, 21 Aug 2001, Berin Loritsch wrote:
> Mircea Toma wrote:
> >
> > ----- Original Message -----
> > From: "Berin Loritsch" <bl...@apache.org>
> > To: "Avalon Development" <av...@jakarta.apache.org>
> > Sent: Tuesday, August 21, 2001 11:50 AM
> > Subject: Re: LogKitManagement
> >
> > > Mircea Toma wrote:
> > > >
> > > > 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?
> > >
> > > Because it is the wrong pattern. We don't obtain loggers by
> > > selecting them (how would we know if we couldn't select the right
> > > one).
> > >
> >
> > Yes, but targets/categories can be selected isn't it (assuming there is only
> > one hierarchy)?
>
> It really doesn't matter. Logging is a system level function. It is
> too much of a core function to go through formal Components. The ComponentManager/Selector
> approach would require refactoring LogKit to use Avalon Framework hooks,
> creating a circular dependency. It is the wrong pattern. It's
> like using a neumatic hammer when all you need is a rubber mallet.
To be honest, we have a system that has logger and logtarget build up as
components. But they are used for alarming first level support on
business case issues not technical.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by Berin Loritsch <bl...@apache.org>.
Mircea Toma wrote:
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> To: "Avalon Development" <av...@jakarta.apache.org>
> Sent: Tuesday, August 21, 2001 11:50 AM
> Subject: Re: LogKitManagement
>
> > Mircea Toma wrote:
> > >
> > > 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?
> >
> > Because it is the wrong pattern. We don't obtain loggers by
> > selecting them (how would we know if we couldn't select the right
> > one).
> >
>
> Yes, but targets/categories can be selected isn't it (assuming there is only
> one hierarchy)?
It really doesn't matter. Logging is a system level function. It is
too much of a core function to go through formal Components. The ComponentManager/Selector
approach would require refactoring LogKit to use Avalon Framework hooks,
creating a circular dependency. It is the wrong pattern. It's
like using a neumatic hammer when all you need is a rubber mallet.
Beyond that, the Hierarchy is basically hidden from view with the
LogKitManager. It is unnecessary to use it at all.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by giacomo <gi...@apache.org>.
On Tue, 21 Aug 2001, Mircea Toma wrote:
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> To: "Avalon Development" <av...@jakarta.apache.org>
> Sent: Tuesday, August 21, 2001 11:50 AM
> Subject: Re: LogKitManagement
>
>
> > Mircea Toma wrote:
> > >
> > > 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?
> >
> > Because it is the wrong pattern. We don't obtain loggers by
> > selecting them (how would we know if we couldn't select the right
> > one).
> >
>
> Yes, but targets/categories can be selected isn't it (assuming there is only
> one hierarchy)?
>
> > Also, this is avoiding the dependency of LogKit requiring Excalibur.
> > If you have dependencies only going in one direction, then you can't
> > have circular dependancies.
> >
> > LogKitManagement will live in Excalibur, and use Excalibur tools
> > and Framework tools. LogKit is completely unaffected by the LogKit
> > Management framework. In fact, all the LogTargetFactories that are
> > Configurable live in Excalibur with the management framework.
>
> Ok, I thought it will be part of LogKit :)
No, definitely not. It's part of Excalibur.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by Mircea Toma <mi...@calgary.qcdata.com>.
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Tuesday, August 21, 2001 11:50 AM
Subject: Re: LogKitManagement
> Mircea Toma wrote:
> >
> > 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?
>
> Because it is the wrong pattern. We don't obtain loggers by
> selecting them (how would we know if we couldn't select the right
> one).
>
Yes, but targets/categories can be selected isn't it (assuming there is only
one hierarchy)?
> Also, this is avoiding the dependency of LogKit requiring Excalibur.
> If you have dependencies only going in one direction, then you can't
> have circular dependancies.
>
> LogKitManagement will live in Excalibur, and use Excalibur tools
> and Framework tools. LogKit is completely unaffected by the LogKit
> Management framework. In fact, all the LogTargetFactories that are
> Configurable live in Excalibur with the management framework.
Ok, I thought it will be part of LogKit :)
Mircea,
Cheers
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by Berin Loritsch <bl...@apache.org>.
Mircea Toma wrote:
>
> 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?
Because it is the wrong pattern. We don't obtain loggers by
selecting them (how would we know if we couldn't select the right
one).
Also, this is avoiding the dependency of LogKit requiring Excalibur.
If you have dependencies only going in one direction, then you can't
have circular dependancies.
LogKitManagement will live in Excalibur, and use Excalibur tools
and Framework tools. LogKit is completely unaffected by the LogKit
Management framework. In fact, all the LogTargetFactories that are
Configurable live in Excalibur with the management framework.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: LogKitManagement
Posted by Mircea Toma <mi...@calgary.qcdata.com>.
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" <gi...@apache.org>
To: <av...@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
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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@ja
karta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org