On Feb 11, 2008 9:29 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi, > > Am Montag, den 11.02.2008, 09:17 +0100 schrieb Karl Pauls: > > > Later on, I think I'll change Pax Logging to move all incoming requests > > > (log > > > and config) to its own thread to prevent the whole issue all together. > > > > Good - so we don't have to hurry. However, do you (and others) think > > it is acceptable to deliver log events asynchronously or at least > > later then the actual point they occur? We have the eventdispatching > > thread around anyways and I think it should be doable to use it to > > deliver events. But I will only spend time looking into this if the > > general opinion is that it is worthwhile ... > > I am not sure, whether this would be a good solution, because you would > then have log messages from the application and log messages from the > framework being out of think with regard to actuall order of processing. > This could cause some headaches when trying to interpret the log files. > > In addition, I tend to think, that the way Log4J locks itself and by > loading classes inside that lock potentially the complete system is kind > of problematic. Not sure how NLog4J and Logback act in this respect. > > On the Felix side, we might come up with a solution where we may > actively delay logging when inside some synchronized/locked code. > Probably the only really problematic location for logging is inside the > ClassLoader support. Could we gather messages there to be logged after > releasing any locks ?
Sure, we could do that. Let's see whether there are other opinions else I'll give it a shot. regards, Karl > Regards > Felix > > -- Karl Pauls [EMAIL PROTECTED]
