On Fri, Mar 4, 2011 at 2:06 AM, Felix Meschberger <[email protected]>wrote:
> Hi, > > Am Donnerstag, den 03.03.2011, 17:07 +0000 schrieb Carl Hall: > > There seem to be 3 things to accomplish here: > > * Change logging order to have slf4j write into the LogService then have > a > > LogListener that will handle writing to logback, etc. > > I would not do that. Rather keep the structure as it is now. > > Maybe we can just provide a custom logback appender which emits the OSGi > events requested by Bertrand ? I think having all the log messages/events make their way to the LogListeners is important to have for slf4j as well as LogService log messages. The LogListeners are manually registered with the LogReaderService so I'm not quite sure how to get a handle to the LogListeners since they don't have to be exposed as OSGi services. Could you give me some more details of how an appender can get access to the LogListeners? I can see getting a reference to LogService and relogging the message to get it out to LogListeners but is it possible to not double log a message like that? I think if we change LogSupport.fireEvent(..) from logging to slf4j + queuing the log event to queuing the event + adding a LogListener to log the message to logback, the processing order is more consistent for all logging paths and easier to follow. This also makes adding/replacing the log system as trivial as adding a new LogListener. I haven't tried this in the code yet though so I could be talking crazy again. :)
