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] Update ahoy
Date Fri, 04 May 2001 13:48:37 GMT
At 08:59  4/5/01 -0400, Berin Loritsch wrote:
>> When hacking at the code I decided that I may aswell go through my whole
>> list of things to do for logkit. The list of changes is in
>> src/xdocs/ChangeLog.txt. It is essentially a fair bit faster again but it
>> also uses more memory to cache information. (And it passes all
>> recomendations for JLS - yea !).
>
>You've been busy :)

;)

>> It is also a lot cleaner semantically and should be easier to use (less
>> unused abstractions). I have left the ContextStack in even though it is in
>> hindsight a bad idea mainly because I feel uncomfortable removing
>> functionality that is likely to used by logging clients.
>
>At this point it is a good move.  You should probably deprecate the offending
>methods and classes to discourage their use.  We should keep the deprecated
>methods until we do a Major release update (i.e. 1.0 to 2.0).

seems like a good idea to me.

>> * 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()
...

>> * Secondly: do we need global hierarchies? It was originally implemented so
>> you could easily disable the whole logging process to a certain level.
>> Prioritys are checked against minimum of global + category priority. I just
>> implemented
>
>I would leave the concept as the default.  I like the ability to do somthing
>like this:
>
>mylogger.setPriority("INFO");
>
>And any sub-categories are set to "INFO" as well.  If we didn't want that
>to happen, then we would resort to:
>
>mylogger.setPriority("INFO", false);

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

>This approach is kind of like the way StringTokenizer has its constructors,
>and allows you to choose to receive the delimiting Tokens as well as the
>regular Tokens.
>
>I think there is room for both methods in the class.
>
>Let's try not to sneak too much into this release.  Can we keep it as an
>issue for post release?

I think we should keep both methods full stop ;)

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

>As I mentioned above, at this point, don't remove--deprecate.  Deprecation
>is a tool that points developers into the proper path.
>
>We can vote on wether to remove deprecated methods at every Major release
>(i.e. 1.x to 2.0).  The reason being is that Major releases are not required
>to be backward compatible, but Minor and Micro releases are.  LogKit while
>we will likely release with version 1.0 should be considered a point release
>(one step above 0.9).
>
>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.

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,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


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


Mime
View raw message