avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: [LogKit] public Hierarchy.getRootLogger()
Date Tue, 25 Sep 2001 03:42:32 GMT
On Tue, 25 Sep 2001 02:36, Sylvain Wallez wrote:
> > The original issues were that the whole system relies on the fact that
> > the root Logger has non-null LogTargets and that certain methods are not
> > called on root Logger. Getting around these limitations would be tricky
> > if anyone had access to that logger. I haven't looked at code recently
> > but I think that these conditions still hold. Generally I prefer the
> > safety of this encapsulation.
> I guess only set/resetLogTarget() are concerned. unsetPriority() already
> handles the special case where m_parent is null.

I am not sure .. haven't looked at it for a bit ;) The problem IIRC was not 
checking to see if parent was null but what to do when you inherit null 
LogTarget(s) from your parent. Hierarchy currently disallows this because it 
wraps setLogTargets and throws an exception if invalid (ie null) targets are 
set. I wouldn't like the idea of allowing the regular Logger object throw an 
exception because then it becomes difficult to program.

> > The question really becomes; Is there a better way to do what you want?
> > ie Would it be better to add extra methods to hierarchy that manipulated
> > root logger (in a safe way). Or perhaps I could commit my MulticastTarget
> > or maybe you could do something like
> >
> > class MyCustomHierarchy extends Hierarchy
> > {
> > ...do your tricky stuff here...
> > }
> Won't help a lot : "tricky stuff" cannot access m_rootLogger which is
> private ;)

thats why I made a protected accessor getRootLogger() ;)

> > or maybe something else? Would any of them work?
> Hierarchy.setDefaultLogTargets(LogTarget[] targets) would solve this
> particular problem.

thats easily doable.

> But here's another one : I started to build a log monitoring webapp
> using Cocoon. The purpose is to list all categories and allow the user
> to interactively set the priority of each one (next step is a
> CocoonLogTarget that displays the logs in a browser). Here, I also faced
> the lack of getter methods to access the needed information. 

partially thats a design choice ;) The getter methods are only really needed 
by logger "management" code and not by "client" code. If I was free to break 
compatability then I would actually remove almost all the getter methods ;) 
All the management functions would then go via another class (say LogManager 
or something that accessed package methods to do its work). However as that 
is not viable at this stage we may aswell add other required getters ;)

> In order to
> prototype my ideas, I used ugly-hacky introspection to get private
> fields of DefaultLogKitManager (m_hierarchy), Hierarchy (m_rootLogger to
> get all loggers) and Logger (m_priorityForceSet for priority
> inheritance).
> So what do you think about adding the following :
> - Hierarchy.getRootLogger() (with additionnal checks in Logger if
> m_parent is null)

I am still not sure I like this completely.

> - LogKitManager.getHierarchy()

You could just cache this before it gets passed to Hierarchy object. Or not? 
ie I would go

Hierarchy h = new Hierarchy();
LogKitManager lkm = new DefaultLogKitManager( h );

//Manage h here
manage( h );

> - Logger.isPriorityInherited()

works for me.

> BTW, I wrote a LogTarget for Servidium's LogFactor5 (www.servidium.com)
> which is a payware swing-based log monitoring GUI. They claim to be
> logging toolkit independent (which they are), but only provide Log4J
> integration. Do you think this could go into Avalon CVS ?

This can go in fine I think. The problem will be getting it compiled for a 
release. If LogFactor5 has a demo version we can use that, otherwise we will 
have to write stubs or get you to submit the .class files prior to a release.



We should take care not to make the intellect our 
god; it has, of course, powerful muscles, but no 

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

View raw message