On Fri, 17 Aug 2001 10:44, [EMAIL PROTECTED] wrote:
> As in many other cases, doing something from scratch doesn't prevent you
> from repeating the same mistakes :-).
;)
> 1. (major)As far as I can see, Logging has exactly the same security
> problems as log4j ( in logging.LogSource class ). Even worse, at least by
> using log4j ( as Ceki mentioned ) you can get secure logging by using
> separate hierarchies, while the proposing logging is just hopeless.
I am not sure about "secure". It is less insecure but any object that can get
a reference to a Category can still do anything to system, so ...
> 3. (major)Obviously, performance. I believe recycling is essential for
> scalability and performance. LogEvent can be used for that ( with some
> enhancements ), the current Logging is again hopeless.
Just a note about this. I used to pool LogEvents inside LogKit. LogEvents are
small short-lived objects -> ie the perfect use case for generation GC which
is in 1.3 and 1.4. Thus in 1.3/1.4 pooling will actually decrease
performance. In 1.1 it will increase performance (object creation is
expensive in those JVMs). I am not sure about 1.2 - never really used it in
production environment but it would be a close call which is more expensive;
synchronization and pooling overhead vs gc.
Either way this API doesn't actually specify any LogEVents as such or am I
missing something?
> This is going to be used by (probably) many commons and outside packages,
> and ( as mentioned many times) it will be _required_.
--
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 *
*-----------------------------------------------------*
