Peter Donald wrote:
>
> At 08:59 4/5/01 -0400, Berin Loritsch wrote:
> >> * Firstly: do we still need LogKit class. It was originally intended to be
> >> access point of all facilities but at the moment all it's methods delegate
> >> to other classes.
> >
> >If there is a better way to do things, then let us know. If it can really
> >be removed, then deprecate the class. The only piece I have used from LogKit
> >is the static LogKit.getLoggerFor("cocoon") class within static methods.
> >I wouldn't remove any classes until the next major release of LogKit.
>
> It's an ease of use thing - it could be removed quite easily. The thing is
> I am not sure if it is easier to directly use the methods or go via LogKit.
> ie
> Priority.getPriorityByName(...) vs LogKit.getPriorityByName(...)
> ContextStack.getCurrentContext() vs LogKit.getCurrentContext()
> ...
Well with the two examples, it logically makes sense to ask Priority to
getPriorityByName(). However, are we (idealogically speaking) getting
LogKit's CurrentContext, or ContextStack's?
Implementation wise, yes we are getting the ContextStack's current context,
but I logically, isn't it really LogKit's current context?
Here is where I don't have enough of a grasp of how LogKit is architected.
> the problem is then that configuring the loggers becomes order dependent.
> ie if you have categories "a.b.c.d" and "a.b" and configure "a.b" to DEBUG
> first then "a.b.c.d" to ERROR you will get different behaviour than if you
> do the reverse. The way it is set up now (and the way Log4j/Syslog and
> possibly the Logging JSR do it) is order independent. (ie "a.b" will be
> DEBUG, "a.b.c" will inherit DEBUG and "a.b.c.d" will be ERROR).
Well, that's why you built it the way you did!
> >> So if we can't find a valid use for it I would like to remove global
> >> priorities - anyone have a problem with that ?
> >
> >At this point, can we hold off for post release? It would be part of the
> >2.0 version plan. If we try to do too much restructuring, we will miss
> >our target date.
>
> I don't see there ever being any need for a 2.0 (or at least I hope that).
> I hope that the Logging JSR will solve our "enterprise level" needs and
> LogKit will only remain for performance orientated logging.
Sounds good to me.
> >As a general rule, I would like to see at least two point releases between
> >major releases. In fact, we could approach it like Cocoon 1 vs. Cocoon 2.
> >During Cocoon 2 initial development, Cocoon 1 was at version 1.7.x. Cocoon 1
> >continued development and support while Cocoon 2 was in development. I think
> >that for LogKit 2 that kind of approach will work. If you want, you could
> >even start with a clean slate (i.e. all deprecated methods removed).
> Logkit 2
> >would be able to continue active development even when LogKit 1 was under
> code
> >freeze.
>
> Right - I would agree if Logkit had ever formely been released to public.
> It has only ever been "released" to people I know. In all my code and their
> code that I am aware of global priorities have only ever been used in 4
> different areas (2 of which are in Avalon ;]). So it was never a used
> feature and considering that the recent addition to Logger features
> nullifies it's usefulness I would like to remove it now.
Ok. My concern was it being used in a widespread manner.
> If we decide not to remove it then I would like to see it stay in for good
> ;) It will not effect our release schedule (it is only requires a small
> patch that is extremely unlikely to cause "issues") but I just want to do
> it now or never ;) Considering I don't use it and can't think of a good
> reason to use it anymore ... ;)
> Cheers,
As long as we are talking about a small change.... <shudder/>
BTW, weren't you going to do package migration as well?
It's in the Now or Never category, but I am not adamant doing it. I just
want to know if that is the case or not.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
