That's it? That's way easier than rerouting things. :) I'll start working on the patch and keep the JIRA[1] updated.
I created a second JIRA[2] to track the conversation and let folks know that we know about this and it is not considered a bug. Should I assign [1] to myself? I don't seem to have permissions to do that. 1 https://issues.apache.org/jira/browse/SLING-2024 <https://issues.apache.org/jira/browse/SLING-2024>2 https://issues.apache.org/jira/browse/SLING-2025 On Tue, Mar 8, 2011 at 3:49 AM, Bertrand Delacretaz <[email protected]>wrote: > On Tue, Mar 8, 2011 at 9:31 AM, Felix Meschberger <[email protected]> > wrote: > > Am Dienstag, den 08.03.2011, 08:25 +0000 schrieb Bertrand Delacretaz: > >> ...What's useful IMO (if it doesn't make things too complicated) is to > >> have a single way of intercepting both sources of log messages, i.e. > >> OSGi LogService and slf4j logging. If there's an interceptor mechanism > >> for slf4j, it can probably just register as a LogListener to get both > >> sources. > > > > This is not needed because OSGi LogService messages are ultimately > > handled by the SLF4J implementation. > > > > So if we provide a mechanism hooking into the SLF4J implementation this > > will intercept all logging message no matter what API (OSGi LogService, > > SLF4J, Commons Logging, Log4J) was used to provide the message.... > > Ok, cool, didn't realize that - so yes, being able to intercept slf4j > messages with a dynamically registered OSGi service is probably all we > need. > > -Bertrand >
