You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Ceki Gülcü <cg...@qos.ch> on 2001/06/13 01:37:38 UTC
JSR47 Critique
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
java-logging-input@eng.sun.com
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.
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: JSR47 Critique
Posted by Ceki Gülcü <cg...@qos.ch>.
Hi Pier,
JSR47 is still in the public-review stage. Doesn't that mean that officially alterations are still possible? Cheers, Ceki
At 00:43 13.06.2001 +0100, Pier P. Fumagalli wrote:
>Ceki Gülcü at cgu@qos.ch 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
>>
>> java-logging-input@eng.sun.com
>>
>> 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.
>
>No matter how many requests they get, it's too bad, but this is for sure not
>going to happen, as what's delivered in the platform strictly must adhere to
>what the JCP produces. Apache is a member of the JCP for the J2EE platform,
>but not for the J2SE, where JSR47 falls, that's why we weren't asked to
>vote.
>
>Anyway, knowing Graham (he's a very reasonable person), I bet that for the
>next revision of the API you will be asked to participate :) Not all hope is
>lost... :) :)
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: JSR47 Critique
Posted by Ceki Gülcü <cg...@qos.ch>.
Hi Pier,
JSR47 is still in the public-review stage. Doesn't that mean that officially alterations are still possible? Cheers, Ceki
At 00:43 13.06.2001 +0100, Pier P. Fumagalli wrote:
>Ceki Gülcü at cgu@qos.ch 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
>>
>> java-logging-input@eng.sun.com
>>
>> 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.
>
>No matter how many requests they get, it's too bad, but this is for sure not
>going to happen, as what's delivered in the platform strictly must adhere to
>what the JCP produces. Apache is a member of the JCP for the J2EE platform,
>but not for the J2SE, where JSR47 falls, that's why we weren't asked to
>vote.
>
>Anyway, knowing Graham (he's a very reasonable person), I bet that for the
>next revision of the API you will be asked to participate :) Not all hope is
>lost... :) :)
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: JSR47 Critique
Posted by Ceki Gülcü <cg...@qos.ch>.
At 19:45 20.06.2001 +1000, Peter Donald wrote:
>On Wed, 20 Jun 2001 19:11, Ceki Gülcü wrote:
>> But even if the servlets are in the same web-application but do not trust
>> each other, I still do not see the problem.
>>
>> In log4j, anyone can retrieve a category by name. You can simply write:
>>
>> Categoty log = Category.getInstance("some-other.servlet")
>
>I assumed that Log4j allowed separate Hierarchies. So you can create a new
>hierarchy and it would not be accessible via static methods?
No, new hierarchies are not accessible via static methods. They are accessible only to those who have a reference to the newly created hierarchy. Regards, Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JSR47 Critique
Posted by Peter Donald <do...@apache.org>.
On Wed, 20 Jun 2001 19:11, Ceki Gülcü wrote:
> But even if the servlets are in the same web-application but do not trust
> each other, I still do not see the problem.
>
> In log4j, anyone can retrieve a category by name. You can simply write:
>
> Categoty log = Category.getInstance("some-other.servlet")
I assumed that Log4j allowed separate Hierarchies. So you can create a new
hierarchy and it would not be accessible via static methods?
> this has nothing to do with the parent/child relationship. Am I missing
> something? Ceki
Well assuming that root Logger is not accessible, it is not possible to futz
with parents Loggers (ie do unsafe things) if you don't have getParent() as
there is no way to get a reference to any of those objects.
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: JSR47 Critique
Posted by Ceki Gülcü <cg...@qos.ch>.
Peter,
This was your earlier comment on children holding references to their parents:
> I guess what I am trying to say is things like getParent() are
> generally considered bad practice when trying to isolate
> resources/computations. When they are available they are admitted
> failings or protected by SecurityExceptions or similar.
>
>
> Consider if two completely separate servlets were in same servlet
> engine. One servlet gets passed a logger (via
> ServletContext/JNDI/other). Now if the loggers where in same hierarchy
> and getParent() was supported it could fake log messages from other
> servlet engine via something like
>
>
> newLogger =
> logger.getParent().getParent().get( "some-other.servlet" )
>
>
> newLogger.warn( "I am invading other servlets logs by doing this" );
Here is my response.
Two completely separate servlets in different web-applications will be loaded by different classloaders. They will be living in different universes. Your argument about children holding references to their parents is not applicable here.
If the servlets are in the same web-application then one can assume that they mutually trust each other.
But even if the servlets are in the same web-application but do not trust each other, I still do not see the problem.
In log4j, anyone can retrieve a category by name. You can simply write:
Categoty log = Category.getInstance("some-other.servlet")
this has nothing to do with the parent/child relationship. Am I missing something? Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JSR47 Critique
Posted by Peter Donald <do...@apache.org>.
At 11:49 AM 6/13/01 +0200, Ceki Gülcü wrote:
>>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.
I guess what I am trying to say is things like getParent() are generally
considered bad practice when trying to isolate resources/computations. When
they are available they are admitted failings or protected by
SecurityExceptions or similar.
Consider if two completely separate servlets were in same servlet engine.
One servlet gets passed a logger (via ServletContext/JNDI/other). Now if
the loggers where in same hierarchy and getParent() was supported it could
fake log messages from other servlet engine via something like
newLogger =
logger.getParent().getParent().get( "some-other.servlet" )
newLogger.warn( "I am invading other servlets logs by doing this" );
>>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?
Well that is implementation dependent. In LogKit I have a private array of
references. At no stage is it passed outside the Logger toolkit. When a new
LogTarget/Appender is added the array is not modified but a new array is
created to replace the old array. Given these circumstances the IBM JDK
will optimize this vastly (no synchronization needed, never gets out of
that scope etc) and can get away with almost no overhead (I guestimate 8-12
bytes for object array reference).
One of the members of the Sun Java performance team (a Jeff someone) also
indicated that memory consumption and optimization is next major
optimization feature to tackle for their team. SO hopefully the final
release of the Sun 1.4 JDK will have similar performance characteristerics.
Though I am not quite sure that they can do it.
All in all the cost of 24-36 bytes (on intel) in worst case doesn't seem
like a large penalty. And considering the increase in performance I think
it is well worth it. It still doesn't allow you to do cascading/additive
inheritance but I have only rarely needed this feature and it could be
simulated using non-additive system with smart configurer.
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: JSR47 Critique
Posted by Peter Donald <do...@apache.org>.
At 11:49 AM 6/13/01 +0200, Ceki Gülcü wrote:
>>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.
I guess what I am trying to say is things like getParent() are generally
considered bad practice when trying to isolate resources/computations. When
they are available they are admitted failings or protected by
SecurityExceptions or similar.
Consider if two completely separate servlets were in same servlet engine.
One servlet gets passed a logger (via ServletContext/JNDI/other). Now if
the loggers where in same hierarchy and getParent() was supported it could
fake log messages from other servlet engine via something like
newLogger =
logger.getParent().getParent().get( "some-other.servlet" )
newLogger.warn( "I am invading other servlets logs by doing this" );
>>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?
Well that is implementation dependent. In LogKit I have a private array of
references. At no stage is it passed outside the Logger toolkit. When a new
LogTarget/Appender is added the array is not modified but a new array is
created to replace the old array. Given these circumstances the IBM JDK
will optimize this vastly (no synchronization needed, never gets out of
that scope etc) and can get away with almost no overhead (I guestimate 8-12
bytes for object array reference).
One of the members of the Sun Java performance team (a Jeff someone) also
indicated that memory consumption and optimization is next major
optimization feature to tackle for their team. SO hopefully the final
release of the Sun 1.4 JDK will have similar performance characteristerics.
Though I am not quite sure that they can do it.
All in all the cost of 24-36 bytes (on intel) in worst case doesn't seem
like a large penalty. And considering the increase in performance I think
it is well worth it. It still doesn't allow you to do cascading/additive
inheritance but I have only rarely needed this feature and it could be
simulated using non-additive system with smart configurer.
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: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: JSR47 Critique
Posted by Ceki Gülcü <cg...@qos.ch>.
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
>>
>> java-logging-input@eng.sun.com
>>
>>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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: JSR47 Critique
Posted by Ceki Gülcü <cg...@qos.ch>.
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
>>
>> java-logging-input@eng.sun.com
>>
>>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: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: JSR47 Critique
Posted by Geoff Soutter <ge...@whitewolf.com.au>.
"Pier P. Fumagalli" <pi...@betaversion.org> wrote:
> No matter how many requests they get, it's too bad, but this is for sure
not
> going to happen, as what's delivered in the platform strictly must adhere
to
> what the JCP produces. Apache is a member of the JCP for the J2EE
platform,
> but not for the J2SE, where JSR47 falls, that's why we weren't asked to
> vote.
Speaking as a "expert" on this JSR, it's not _totally_ too late.
Yes, we are late in the process, but no, we are not yet at the "drop dead"
date.
So, we are still considering feedback (well, I am at least :-).
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: JSR47 Critique
Posted by Geoff Soutter <ge...@whitewolf.com.au>.
"Pier P. Fumagalli" <pi...@betaversion.org> wrote:
> No matter how many requests they get, it's too bad, but this is for sure
not
> going to happen, as what's delivered in the platform strictly must adhere
to
> what the JCP produces. Apache is a member of the JCP for the J2EE
platform,
> but not for the J2SE, where JSR47 falls, that's why we weren't asked to
> vote.
Speaking as a "expert" on this JSR, it's not _totally_ too late.
Yes, we are late in the process, but no, we are not yet at the "drop dead"
date.
So, we are still considering feedback (well, I am at least :-).
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: JSR47 Critique
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Ceki Gülcü at cgu@qos.ch 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
>
> java-logging-input@eng.sun.com
>
> 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.
No matter how many requests they get, it's too bad, but this is for sure not
going to happen, as what's delivered in the platform strictly must adhere to
what the JCP produces. Apache is a member of the JCP for the J2EE platform,
but not for the J2SE, where JSR47 falls, that's why we weren't asked to
vote.
Anyway, knowing Graham (he's a very reasonable person), I bet that for the
next revision of the API you will be asked to participate :) Not all hope is
lost... :) :)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: JSR47 Critique
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Ceki Gülcü at cgu@qos.ch 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
>
> java-logging-input@eng.sun.com
>
> 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.
No matter how many requests they get, it's too bad, but this is for sure not
going to happen, as what's delivered in the platform strictly must adhere to
what the JCP produces. Apache is a member of the JCP for the J2EE platform,
but not for the J2SE, where JSR47 falls, that's why we weren't asked to
vote.
Anyway, knowing Graham (he's a very reasonable person), I bet that for the
next revision of the API you will be asked to participate :) Not all hope is
lost... :) :)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: JSR47 Critique
Posted by Peter Donald <do...@apache.org>.
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
>
> java-logging-input@eng.sun.com
>
>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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org