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