At 01:37 AM 6/13/01 +0200, Ceki G�lc� wrote:
>
>Greetings,
>
>Here is a written critique of JSR47, the logging API shipped with
>JDK 1.4:
>
> http://jakarta.apache.org/log4j/docs/critique.html
>
>If you agree with its contents, then you are encouraged to send a
>personalized request to
I read the critique and while I agree with some of the points I am not sure
I agree with your reasoning. Specifically I don't think thing your analysis
of "Parents vs Children" is valid. I would actually say it is largely an
implementation detail ;)
"Configutation order matters" does suck tremendously but this is not due to
the JSR storage of children.
For instance you say "In log4j, changing the priority of a category
involves the change of a single field. Children categories dynamically
inherit the priority of their parent by traversing the hierarchy tree
upwards.". So in Log4j you climb *up* category tree every time log() is
called.
Compare this to LogKit which traverses *down* the tree when you set
priority/appenders. LogKit thus only accesses a logger local avariable
rather than traversing hierarchy tree each log request (thus is faster).
So "Parents vs Children" has nothing to do with "Configutation order
matters" feature. I suspect parent access was blocked as it is a security
risk and a violation of patterns used in existing server products (which do
not condone *breaking out of the shell*).
Also you state "Unfortunately, in the JSR47 API, handlers cannot be
inherited because it would be prohibitively expensive (and unmanageable) to
let each logger to contain a Vector of all inherited handlers, especially
in large trees." which my experience would disagree with.
Object references are relatively cheap (usually 4 or 6 bytes on intel
machines). It is rare that a logger has more than 4 appenders (only one
program I know of actually requires more than that). So in worst case you
end up with 16 (or 24) extra bytes per logger ... not a biggie - even in
embedded devices. (This is not dealing properly with additivity though
which would require extra storage).
The JSR does have a limited range of handlers and configuration methods
though.
>If you agree with its contents, then you are encouraged to send a
>personalized request to
>
> [EMAIL PROTECTED]
>
>asking them to adopt log4j as the logging API shipped with JDK
>1.4. Please cc: me if and when you choose do so. Thank you in advance.
>From recent discussions with a Spec Lead for a core language/library
change, I would be very skeptical that this can ever occur. When making
changes to core java, the Spec Leads have to sign some heavyweight
contracts from the PMO. I am not sure if the Logging JSR is different as it
started out as a std extention but I suspect not.
If you really want to improve the the logging JSR I would suggest you work
with them to point out changes to the spec that would be beneficial. You
may even be able to convert some of the log4j appenders to JSR47 handlers
and distribute as part of the JSR RI (though as it comes under the umbrella
JSR I am not su sure).
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
