avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: LogKitManagement
Date Wed, 22 Aug 2001 09:34:36 GMT
Quoting Peter Donald <donaldp@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


Mime
View raw message