You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/05/04 11:34:55 UTC
[Logkit] Update ahoy
Hi,
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 !).
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.
A few newish ideas popped into my mind when looking at the code.
* 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.
* 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
boolean recurse = true;
logger.unsetPriority( recurse );
which recursively unsets the priority of logger and all sub-loggers. This
means that all these loggers will get the same priority as their parent. So
you can disable whole hierarchies via
boolean recurse = true;
logger.unsetPriority( recurse );
logger.setPriority( Priority.ERROR );
Which first unsets all sub-loggers and makes sure their parent (ie the
current logger) has error priority. Thus they all inherit this error
priority.
So in a way we no longer need global priorities - unless we want to be able
to shutdown logging, start it up again and still "remember" the original
priorities. We can either re-read log config file or keep global priority
if this is a possible use case. (I don't use it in any of my code - can
anyone see any use for it?).
So if we can't find a valid use for it I would like to remove global
priorities - anyone have a problem with that ?
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
Re: [Logkit] Update ahoy
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> Re: Global priorities
>
> I guess what I was trying to say (in a less than clear fashion) was that we
> can take them out now and add them back in post-release if we find out they
> are needed. But once we release logkit with them in it we can't really take
> them out.
+0.5
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Logkit] Update ahoy
Posted by Peter Donald <do...@apache.org>.
Re: Global priorities
I guess what I was trying to say (in a less than clear fashion) was that we
can take them out now and add them back in post-release if we find out they
are needed. But once we release logkit with them in it we can't really take
them out.
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
Re: [Logkit] Update ahoy
Posted by Berin Loritsch <bl...@apache.org>.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Logkit] Update ahoy
Posted by Peter Donald <do...@apache.org>.
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
Re: [Logkit] Update ahoy
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> Hi,
>
> 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).
> A few newish ideas popped into my mind when looking at the code.
You're scaring 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.
> * 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);
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?
> 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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org