Hi,
I think we should forget about the OSGi LogListener in this context.
A simple thing would be to use A simplified version of the logback
Appender interface something like (better names highly welcome):
MessageListener {
void message(ILoggingEvent event);
}
The service registration properties may then set the categories to which
this listener applies or what levels to filter and the name of the
listener. Such a MessageListener would then be wrapped inside an Proxy
implementing the Appender interface and being dynamically put into
logback as if we would configure a FileAppender or so...
Regards
Felix
Am Dienstag, den 08.03.2011, 06:04 +0000 schrieb Carl Hall:
> 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. :)
