You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2001/09/24 16:42:03 UTC
[LogKit] public Hierarchy.getRootLogger()
Hi all,
Would it be possible to make Hierarchy.getRootLogger() public ?
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).
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 ?
Thanks.
--
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
Re: [LogKit] public Hierarchy.getRootLogger()
Posted by Peter Donald <do...@apache.org>.
On Thu, 27 Sep 2001 19:14, Sylvain Wallez wrote:
> > Sounds kool ;) Just FYI the way I originally wanted to do it was
> > something like
> >
> > Hierargy.getManager()
> >
> > class LogManager
> > {
> > setLogTargets( String name, LogTarget[] targets );
> > LogTarget[] getLogTargets( String name );
> >
> > setPriority( String name, Priority );
> > Priority getPriority( String name );
> >
> > ...insert other mutators/accessors here ...
> > }
> >
> > I am not sure how valid that is now or even if it is still a good idea ;)
>
> I'm not sure wether the first parameter should be a String or a Logger
> (which of course must belong to the managed hierarchy). In other words,
> should the manager act on loggers/categories that already exist, or
> should it create them on the fly when requested ?
I would say create them on the fly. (fits in with how it behaves now).
> And also, couldn't Hierarchy and HierarchyManager be merged ? If there's
> no restriction for getting a manager once we know the hierarchy, it
> would be better IMO to let the Hierarchy manage itself its category
> tree, or we will end up with Hierarchy having only getLoggerFor() and
> all other methods moved to HierarchyManager.
>
> Thoughts ?
works for me - Hierarchy used to be called LogManager in LogKit's alpha stage
;) It was changed to Hierarchy because a few people requested the name change
(because thats the same terminology Log4J uses).
> And also, please find attached a StreamTargetFactory which allows to
> configure StreamTargets with LogKitManager using OutputStreams stored in
> the context (System.out/System.err are predefined entries).
will add it in a bit.
--
Cheers,
Pete
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [LogKit] public Hierarchy.getRootLogger()
Posted by Peter Donald <do...@apache.org>.
On Wed, 26 Sep 2001 03:44, Peter Donald wrote:
> > > > - 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 );
> >
> > Won't be enough :
> > - LogKitManager can create its own Hierarchy
> > - I'd like to access the Hierarchy from a LogKitManageable (more
> > precisely a Cocoon component).
>
> Convinced me. Anyone else mind this ?
applied.
--
Cheers,
Pete
"The ability to quote is a serviceable substitute for wit." -- Maugham
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [LogKit] public Hierarchy.getRootLogger()
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Peter Donald a �crit :
>
> On Tue, 25 Sep 2001 19:26, Sylvain Wallez wrote:
> > > > > 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() ;)
> >
> > Doh ! I was focused on the missing "public getRootLogger" and forgot it
> > already existed protected. Sorry !
>
> ;)
>
> > > > > or maybe something else? Would any of them work?
> > > >
> > > > Hierarchy.setDefaultLogTargets(LogTarget[] targets) would solve this
> > > > particular problem.
> > >
> > > thats easily doable.
> >
> > Since I need this one now, patch attached for Hierarchy and
> > LogKitManager !
>
> applied.
Thanks.
> > I think a LogManager (or HierarchyManager ?) will be needed if we want
> > to build sophisticated log management apps, since such apps will need
> > detailed knowledge on Logger configurations which shouldn't be exposed
> > to normal client code (such as getLogTargets). I'll try to send a
> > proposal soon.
>
> Sounds kool ;) Just FYI the way I originally wanted to do it was something
> like
>
> Hierargy.getManager()
>
> class LogManager
> {
> setLogTargets( String name, LogTarget[] targets );
> LogTarget[] getLogTargets( String name );
>
> setPriority( String name, Priority );
> Priority getPriority( String name );
>
> ...insert other mutators/accessors here ...
> }
>
> I am not sure how valid that is now or even if it is still a good idea ;)
I'm not sure wether the first parameter should be a String or a Logger
(which of course must belong to the managed hierarchy). In other words,
should the manager act on loggers/categories that already exist, or
should it create them on the fly when requested ?
And also, couldn't Hierarchy and HierarchyManager be merged ? If there's
no restriction for getting a manager once we know the hierarchy, it
would be better IMO to let the Hierarchy manage itself its category
tree, or we will end up with Hierarchy having only getLoggerFor() and
all other methods moved to HierarchyManager.
Thoughts ?
> > > > - 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 );
> >
> > Won't be enough :
> > - LogKitManager can create its own Hierarchy
> > - I'd like to access the Hierarchy from a LogKitManageable (more
> > precisely a Cocoon component).
>
> Convinced me. Anyone else mind this ?
>
> > > > - Logger.isPriorityInherited()
> > >
> > > works for me.
> >
> > Cool, but we won't need it if we have a HierarchyManager...
>
> ok - wont add it just yet then ;)
>
> >
> > > > 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.
> >
> > I discovered today they've been acquired by another company. And since
> > LogFactor5 isn't their main product, I don't know if they will continue
> > supporting it. So maybe it's better to wait for now and see what will
> > happen.
>
> okays.
Oh, forgot to say : if can be useful to anyone, I can post it.
And also, please find attached a StreamTargetFactory which allows to
configure StreamTargets with LogKitManager using OutputStreams stored in
the context (System.out/System.err are predefined entries).
> --
> Cheers,
>
> Pete
>
> ---------------------------------------------------------------
> The difference between genius, and stupidity? Genius has limits
> ---------------------------------------------------------------
>
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
Re: [LogKit] public Hierarchy.getRootLogger()
Posted by Peter Donald <do...@apache.org>.
On Tue, 25 Sep 2001 19:26, Sylvain Wallez wrote:
> > > > 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() ;)
>
> Doh ! I was focused on the missing "public getRootLogger" and forgot it
> already existed protected. Sorry !
;)
> > > > or maybe something else? Would any of them work?
> > >
> > > Hierarchy.setDefaultLogTargets(LogTarget[] targets) would solve this
> > > particular problem.
> >
> > thats easily doable.
>
> Since I need this one now, patch attached for Hierarchy and
> LogKitManager !
applied.
> I think a LogManager (or HierarchyManager ?) will be needed if we want
> to build sophisticated log management apps, since such apps will need
> detailed knowledge on Logger configurations which shouldn't be exposed
> to normal client code (such as getLogTargets). I'll try to send a
> proposal soon.
Sounds kool ;) Just FYI the way I originally wanted to do it was something
like
Hierargy.getManager()
class LogManager
{
setLogTargets( String name, LogTarget[] targets );
LogTarget[] getLogTargets( String name );
setPriority( String name, Priority );
Priority getPriority( String name );
...insert other mutators/accessors here ...
}
I am not sure how valid that is now or even if it is still a good idea ;)
> > > - 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 );
>
> Won't be enough :
> - LogKitManager can create its own Hierarchy
> - I'd like to access the Hierarchy from a LogKitManageable (more
> precisely a Cocoon component).
Convinced me. Anyone else mind this ?
> > > - Logger.isPriorityInherited()
> >
> > works for me.
>
> Cool, but we won't need it if we have a HierarchyManager...
ok - wont add it just yet then ;)
>
> > > 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.
>
> I discovered today they've been acquired by another company. And since
> LogFactor5 isn't their main product, I don't know if they will continue
> supporting it. So maybe it's better to wait for now and see what will
> happen.
okays.
--
Cheers,
Pete
---------------------------------------------------------------
The difference between genius, and stupidity? Genius has limits
---------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [LogKit] public Hierarchy.getRootLogger()
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Peter Donald a �crit :
>
> 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() ;)
Doh ! I was focused on the missing "public getRootLogger" and forgot it
already existed protected. Sorry !
> > > or maybe something else? Would any of them work?
> >
> > Hierarchy.setDefaultLogTargets(LogTarget[] targets) would solve this
> > particular problem.
>
> thats easily doable.
Since I need this one now, patch attached for Hierarchy and
LogKitManager !
> > 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 ;)
I think a LogManager (or HierarchyManager ?) will be needed if we want
to build sophisticated log management apps, since such apps will need
detailed knowledge on Logger configurations which shouldn't be exposed
to normal client code (such as getLogTargets). I'll try to send a
proposal soon.
> > 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 );
Won't be enough :
- LogKitManager can create its own Hierarchy
- I'd like to access the Hierarchy from a LogKitManageable (more
precisely a Cocoon component).
> > - Logger.isPriorityInherited()
>
> works for me.
Cool, but we won't need it if we have a HierarchyManager...
> > 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.
I discovered today they've been acquired by another company. And since
LogFactor5 isn't their main product, I don't know if they will continue
supporting it. So maybe it's better to wait for now and see what will
happen.
> --
> Cheers,
>
> Pete
>
> -------------------------------------------------
> We should take care not to make the intellect our
> god; it has, of course, powerful muscles, but no
> personality.
> -------------------------------------------------
>
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
Re: [LogKit] public Hierarchy.getRootLogger()
Posted by Peter Donald <do...@apache.org>.
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.
--
Cheers,
Pete
-------------------------------------------------
We should take care not to make the intellect our
god; it has, of course, powerful muscles, but no
personality.
-------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [LogKit] public Hierarchy.getRootLogger()
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
inheritance).
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
Re: [LogKit] public Hierarchy.getRootLogger()
Posted by Peter Donald <do...@apache.org>.
On Tue, 25 Sep 2001 00:42, Sylvain Wallez wrote:
> Hi all,
>
> Would it be possible to make Hierarchy.getRootLogger() public ?
probably ;)
> 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.
> 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.
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...
}
or maybe something else? Would any of them work?
--
Cheers,
Pete
----------------------------------
"Don't play dumb with me.
I happen to be an expert at that"
- Maxwell Smart
----------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org