At 10:58 13.06.2001 +1000, Peter Donald wrote:
>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.
Hello Peter,
>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).
Very interesting. I'll look at how you do it immediately.
>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*).
Does not compute.
>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).
Object references are cheap but new objects are not. You'd need a new Vector for each
logger in the tree. Right?
>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.
I think it's a question of will in this particular case.
>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).
Absolutely but it takes two to tango... Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
