avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [LogKit] public Hierarchy.getRootLogger()
Date Mon, 24 Sep 2001 16:36:40 GMT

Peter Donald a écrit :
> On Tue, 25 Sep 2001 00:42, Sylvain Wallez wrote:
> > Hi all,
> >
> > Would it be possible to make Hierarchy.getRootLogger() public ?
> probably ;)

Great ;))

> > Having it protected implies some limitations on LogKit usage. The one I
> > came across today is that it's not possible to set several log targets
> > on an entire hierarchy (Hierarchy.setDefaultLogTarget accepts only one
> > LogTarget).
> yep. I have come up against this and ended up adding a MulticastTarget that
> just propogates to multiple targets.

Isn't it a complicated solution to a simple problem ?

> > The only issue I see is that it exposes the logger hierarchy. But is it
> > really an issue, since you can get any Logger (apart root) from the
> > Hierarchy itself ?
> 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.

> 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 ;)

> or maybe something else? Would any of them work?

Hierarchy.setDefaultLogTargets(LogTarget[] targets) would solve this
particular problem.

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. 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

So what do you think about adding the following :
- Hierarchy.getRootLogger() (with additionnal checks in Logger if
m_parent is null)
- LogKitManager.getHierarchy()
- Logger.isPriorityInherited()

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 ?

> --
> Cheers,
> Pete
> ----------------------------------
>    "Don't play dumb with me.
> I happen to be an expert at that"
>            - Maxwell Smart
> ----------------------------------

Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

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

View raw message