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