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 ? Regards Felix
