At 22:04 25.05.2001 +0200, you wrote:
>I had JProbe Coverage investigate a run of the
>org.apache.log4j.StressCategory with 5 arguments.
>
>Calls -> howmany times this method was called during the run.
>Methods Missed -> howmany methods in that class / package that were not
>called (and some methods were called).
>
>This report shows which methods are important when stessing the Category
>class (and thus the entire log4j framework).
>This information can be used to optimize performance (some more...).
>
>Some things I have in mind for log4j 1.2 (just IDEA's, so comments please):
>- configuration of log4j via JMX
I am expecting to see commercial log4j extensions to implement management related
functionality as this is quite a big piece.
I suggest that we concentrate our efforts on core log4j API. For instance, LV2 is
quite interesting to look at. See
http://www.swzoo.org/log2/documents/ and
http://www.swzoo.org/documents/miscellaneous/jsr047/
-log4j configuration via a servlet (runtime)
Isn't this is a subset of the first item? See also Volker Mentzner's contribution.
>- "The principal security requirement is that untrusted code should not be
>able to change the logging configuration. Specifically, if the logging
>configuration has been set up to log a particular category of information to
>a particular Handler, then untrusted code should not be able to prevent or
>disrupt that logging. "
>--> from the JDK 1.4 logging section. we should have this too not?
I think Ron Rivest once said that security was fractal. This is an addition that needs
to be taken quite seriously. It also requires JDK 1.2 which I am not keen to adopt
just yet.
>- integration of the jakarta log taglib in the dist
>(http://jakarta.apache.org/taglibs/doc/log-doc/intro.html)
Cool. I did not know about this one.
Regards, Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
