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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
