You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Carl Hall <ca...@hallwaytech.com> on 2011/03/02 22:37:57 UTC
Re: Access Log as OSGi Events
Looks like I have bought some cycles to work on this. I am familiarizing
myself with the code now. I'll plan to first replace the homegrown impl with
logback. Any suggestions on direction or features are most welcomed.
On Fri, Feb 18, 2011 at 10:09 AM, Felix Meschberger <fm...@adobe.com>wrote:
> Hi,
>
> Am Donnerstag, den 17.02.2011, 08:58 +0000 schrieb Bertrand Delacretaz:
> > Hi,
> >
> > On Wed, Feb 16, 2011 at 10:49 PM, Carl Hall <ca...@hallwaytech.com>
> wrote:
> > > Is it possible to send the access log entries as OSGi events? I see the
> use
> > > of RequestLogger which doesn't have such capabilities. To send access
> log
> > > entries to as events, would a patch be required for SlingMainServlet et
> al?
> >
> > In theory the LogReaderService might help for that, but the way our
> > logging is implemented does not allow us to use it currently, see
> > http://markmail.org/message/dlx5yvbjr74d46mh
> >
> > I think improving this would be useful, if someone has the cycles...
>
> As I already mentioned in the reference mail thread, using LogReader
> does not work. I thought about reverting the LogService-SLF4J
> interconnection in that SLF4J would log to LogService. But this turns
> out to not be practical -- mostly because LogService does not allow the
> same level of flexibility regarding log categories ....
>
> I really think the correct solution going forward (and needing cycles
> here) would be to replace our home-grown SLF4J implementation with an
> existing implementation (logback comes to mind) which would allows us
> for better extensibility and reuse.
>
> Regards
> Felix
>
>
> >
> > -Bertrand
> >
> > [1]
> http://www.osgi.org/javadoc/r4v42/org/osgi/service/log/LogReaderService.html
>
>
>
Re: Access Log as OSGi Events
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
One last word ;-)
Lets move this discussion to dev@ ;-)
Regards
Felix
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.
> * Replace homegrown log mechanism with logback (or something comparable)
> * maintaining all current functionality.
>
> And while I'm buying cycles I might as well try to accomplish everything. :)
>
> I feel decently comfortable in the code as I spent last night getting a map
> of the terrain. I have started a local git branch for performing these
> changes. I'll file 2 JIRAs to cover this (change to logback, change
> processing order).
>
> Felix, is this [1] the whiteboard sanbox you speak of?
>
> Let me know if I sound crazy on any of this.
>
>
> 1 http://svn.apache.org/repos/asf/sling/whiteboard/
>
>
> On Thu, Mar 3, 2011 at 8:56 AM, Justin Edelson <ju...@justinedelson.com>wrote:
>
> > Go Carl!!!
> >
> > On Mar 3, 2011, at 2:58 AM, Felix Meschberger <fm...@adobe.com> wrote:
> >
> > > Hi Carl,
> > >
> > > Am Mittwoch, den 02.03.2011, 21:37 +0000 schrieb Carl Hall:
> > >> Looks like I have bought some cycles to work on this. I am familiarizing
> > >> myself with the code now. I'll plan to first replace the homegrown impl
> > with
> > >> logback. Any suggestions on direction or features are most welcomed.
> > >
> > > The most important point is, that existing configurations and
> > > configuration mechanisms (factory configurations for writers and
> > > loggers) must still be supported.
> > >
> > > Further points would then probably be extending the current
> > > configuration mechanisms to support more logback features:
> > >
> > > - different Appenders
> > > - Appender extension
> >
> > Definitely in favor of these two conceptually, but I would prefer we didn't
> > expose the implementation detail that we're using logback. Possible?
> >
> > > - add Sling to the list of open-source projects using it
> > > (see http://logback.qos.ch)
> > >
> > > I think this will be a major rework. How about starting this in a
> > > whiteboard sandbox ?
> > >
> > > Regards
> > > Felix
> > >
> > >>
> > >>
> > >> On Fri, Feb 18, 2011 at 10:09 AM, Felix Meschberger <fmeschbe@adobe.com
> > >wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> Am Donnerstag, den 17.02.2011, 08:58 +0000 schrieb Bertrand Delacretaz:
> > >>>> Hi,
> > >>>>
> > >>>> On Wed, Feb 16, 2011 at 10:49 PM, Carl Hall <ca...@hallwaytech.com>
> > >>> wrote:
> > >>>>> Is it possible to send the access log entries as OSGi events? I see
> > the
> > >>> use
> > >>>>> of RequestLogger which doesn't have such capabilities. To send access
> > >>> log
> > >>>>> entries to as events, would a patch be required for SlingMainServlet
> > et
> > >>> al?
> > >>>>
> > >>>> In theory the LogReaderService might help for that, but the way our
> > >>>> logging is implemented does not allow us to use it currently, see
> > >>>> http://markmail.org/message/dlx5yvbjr74d46mh
> > >>>>
> > >>>> I think improving this would be useful, if someone has the cycles...
> > >>>
> > >>> As I already mentioned in the reference mail thread, using LogReader
> > >>> does not work. I thought about reverting the LogService-SLF4J
> > >>> interconnection in that SLF4J would log to LogService. But this turns
> > >>> out to not be practical -- mostly because LogService does not allow the
> > >>> same level of flexibility regarding log categories ....
> > >>>
> > >>> I really think the correct solution going forward (and needing cycles
> > >>> here) would be to replace our home-grown SLF4J implementation with an
> > >>> existing implementation (logback comes to mind) which would allows us
> > >>> for better extensibility and reuse.
> > >>>
> > >>> Regards
> > >>> Felix
> > >>>
> > >>>
> > >>>>
> > >>>> -Bertrand
> > >>>>
> > >>>> [1]
> > >>>
> > http://www.osgi.org/javadoc/r4v42/org/osgi/service/log/LogReaderService.html
> > >>>
> > >>>
> > >>>
> > >
> > >
> >
Re: Access Log as OSGi Events
Posted by Carl Hall <ca...@hallwaytech.com>.
>From the looks of things, the least disruptive change would be to leave most
of the current logging code in place. Since SlingLogPanel needs to have
knowledge of what loggers are out there, I'm not sure that replacing the
Sling slf4j impl with logback is plausible. Instead I'm looking at using
logback at the point where the code gets down to finally writing something
to a file. Does this inline with the approach you were thinking of?
On Tue, Mar 8, 2011 at 3:31 AM, Felix Meschberger <fm...@adobe.com>wrote:
> Hi,
>
> Am Dienstag, den 08.03.2011, 08:25 +0000 schrieb Bertrand Delacretaz:
> > Hi,
> >
> > On Tue, Mar 8, 2011 at 8:51 AM, Felix Meschberger <fm...@adobe.com>
> wrote:
> > > ...I think we should forget about the OSGi LogListener in this
> context....
> >
> > I agree that if we have a better way to intercept logging messages, we
> > don't necessarily need to have the OSGi LogListener.
> >
> > 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.
>
> Regards
> Felix
>
>
>
Re: Access Log as OSGi Events
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Mar 8, 2011 at 3:23 PM, Carl Hall <ca...@hallwaytech.com> wrote:
> ...Should I assign [1] to
> myself? I don't seem to have permissions to do that....
Should be ok now, added you to the "committers" role in the Sling JIRA.
-Bertrand
Re: Access Log as OSGi Events
Posted by Carl Hall <ca...@hallwaytech.com>.
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
<bd...@apache.org>wrote:
> On Tue, Mar 8, 2011 at 9:31 AM, Felix Meschberger <fm...@adobe.com>
> 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
>
Re: Access Log as OSGi Events
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Mar 8, 2011 at 9:31 AM, Felix Meschberger <fm...@adobe.com> 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
Re: Access Log as OSGi Events
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am Dienstag, den 08.03.2011, 08:25 +0000 schrieb Bertrand Delacretaz:
> Hi,
>
> On Tue, Mar 8, 2011 at 8:51 AM, Felix Meschberger <fm...@adobe.com> wrote:
> > ...I think we should forget about the OSGi LogListener in this context....
>
> I agree that if we have a better way to intercept logging messages, we
> don't necessarily need to have the OSGi LogListener.
>
> 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.
Regards
Felix
Re: Access Log as OSGi Events
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Mar 8, 2011 at 8:51 AM, Felix Meschberger <fm...@adobe.com> wrote:
> ...I think we should forget about the OSGi LogListener in this context....
I agree that if we have a better way to intercept logging messages, we
don't necessarily need to have the OSGi LogListener.
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.
-Bertrand
Re: Access Log as OSGi Events
Posted by Felix Meschberger <fm...@adobe.com>.
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 <fm...@adobe.com>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. :)
Re: Access Log as OSGi Events
Posted by Carl Hall <ca...@hallwaytech.com>.
On Fri, Mar 4, 2011 at 2:06 AM, Felix Meschberger <fm...@adobe.com>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. :)
Re: Access Log as OSGi Events
Posted by Felix Meschberger <fm...@adobe.com>.
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 ?
> * Replace homegrown log mechanism with logback (or something comparable)
> * maintaining all current functionality.
+1 to both.
>
> And while I'm buying cycles I might as well try to accomplish everything. :)
>
> I feel decently comfortable in the code as I spent last night getting a map
> of the terrain. I have started a local git branch for performing these
> changes. I'll file 2 JIRAs to cover this (change to logback, change
> processing order).
>
> Felix, is this [1] the whiteboard sanbox you speak of?
Exactly. But you might also use the Apache Review Board, if you like.
>
> Let me know if I sound crazy on any of this.
All things said, except: Thanks a lot for taking this over !
Regards
Felix
>
>
> 1 http://svn.apache.org/repos/asf/sling/whiteboard/
>
>
> On Thu, Mar 3, 2011 at 8:56 AM, Justin Edelson <ju...@justinedelson.com>wrote:
>
> > Go Carl!!!
> >
> > On Mar 3, 2011, at 2:58 AM, Felix Meschberger <fm...@adobe.com> wrote:
> >
> > > Hi Carl,
> > >
> > > Am Mittwoch, den 02.03.2011, 21:37 +0000 schrieb Carl Hall:
> > >> Looks like I have bought some cycles to work on this. I am familiarizing
> > >> myself with the code now. I'll plan to first replace the homegrown impl
> > with
> > >> logback. Any suggestions on direction or features are most welcomed.
> > >
> > > The most important point is, that existing configurations and
> > > configuration mechanisms (factory configurations for writers and
> > > loggers) must still be supported.
> > >
> > > Further points would then probably be extending the current
> > > configuration mechanisms to support more logback features:
> > >
> > > - different Appenders
> > > - Appender extension
> >
> > Definitely in favor of these two conceptually, but I would prefer we didn't
> > expose the implementation detail that we're using logback. Possible?
> >
> > > - add Sling to the list of open-source projects using it
> > > (see http://logback.qos.ch)
> > >
> > > I think this will be a major rework. How about starting this in a
> > > whiteboard sandbox ?
> > >
> > > Regards
> > > Felix
> > >
> > >>
> > >>
> > >> On Fri, Feb 18, 2011 at 10:09 AM, Felix Meschberger <fmeschbe@adobe.com
> > >wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> Am Donnerstag, den 17.02.2011, 08:58 +0000 schrieb Bertrand Delacretaz:
> > >>>> Hi,
> > >>>>
> > >>>> On Wed, Feb 16, 2011 at 10:49 PM, Carl Hall <ca...@hallwaytech.com>
> > >>> wrote:
> > >>>>> Is it possible to send the access log entries as OSGi events? I see
> > the
> > >>> use
> > >>>>> of RequestLogger which doesn't have such capabilities. To send access
> > >>> log
> > >>>>> entries to as events, would a patch be required for SlingMainServlet
> > et
> > >>> al?
> > >>>>
> > >>>> In theory the LogReaderService might help for that, but the way our
> > >>>> logging is implemented does not allow us to use it currently, see
> > >>>> http://markmail.org/message/dlx5yvbjr74d46mh
> > >>>>
> > >>>> I think improving this would be useful, if someone has the cycles...
> > >>>
> > >>> As I already mentioned in the reference mail thread, using LogReader
> > >>> does not work. I thought about reverting the LogService-SLF4J
> > >>> interconnection in that SLF4J would log to LogService. But this turns
> > >>> out to not be practical -- mostly because LogService does not allow the
> > >>> same level of flexibility regarding log categories ....
> > >>>
> > >>> I really think the correct solution going forward (and needing cycles
> > >>> here) would be to replace our home-grown SLF4J implementation with an
> > >>> existing implementation (logback comes to mind) which would allows us
> > >>> for better extensibility and reuse.
> > >>>
> > >>> Regards
> > >>> Felix
> > >>>
> > >>>
> > >>>>
> > >>>> -Bertrand
> > >>>>
> > >>>> [1]
> > >>>
> > http://www.osgi.org/javadoc/r4v42/org/osgi/service/log/LogReaderService.html
> > >>>
> > >>>
> > >>>
> > >
> > >
> >
Re: Access Log as OSGi Events
Posted by Carl Hall <ca...@hallwaytech.com>.
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.
* Replace homegrown log mechanism with logback (or something comparable)
* maintaining all current functionality.
And while I'm buying cycles I might as well try to accomplish everything. :)
I feel decently comfortable in the code as I spent last night getting a map
of the terrain. I have started a local git branch for performing these
changes. I'll file 2 JIRAs to cover this (change to logback, change
processing order).
Felix, is this [1] the whiteboard sanbox you speak of?
Let me know if I sound crazy on any of this.
1 http://svn.apache.org/repos/asf/sling/whiteboard/
On Thu, Mar 3, 2011 at 8:56 AM, Justin Edelson <ju...@justinedelson.com>wrote:
> Go Carl!!!
>
> On Mar 3, 2011, at 2:58 AM, Felix Meschberger <fm...@adobe.com> wrote:
>
> > Hi Carl,
> >
> > Am Mittwoch, den 02.03.2011, 21:37 +0000 schrieb Carl Hall:
> >> Looks like I have bought some cycles to work on this. I am familiarizing
> >> myself with the code now. I'll plan to first replace the homegrown impl
> with
> >> logback. Any suggestions on direction or features are most welcomed.
> >
> > The most important point is, that existing configurations and
> > configuration mechanisms (factory configurations for writers and
> > loggers) must still be supported.
> >
> > Further points would then probably be extending the current
> > configuration mechanisms to support more logback features:
> >
> > - different Appenders
> > - Appender extension
>
> Definitely in favor of these two conceptually, but I would prefer we didn't
> expose the implementation detail that we're using logback. Possible?
>
> > - add Sling to the list of open-source projects using it
> > (see http://logback.qos.ch)
> >
> > I think this will be a major rework. How about starting this in a
> > whiteboard sandbox ?
> >
> > Regards
> > Felix
> >
> >>
> >>
> >> On Fri, Feb 18, 2011 at 10:09 AM, Felix Meschberger <fmeschbe@adobe.com
> >wrote:
> >>
> >>> Hi,
> >>>
> >>> Am Donnerstag, den 17.02.2011, 08:58 +0000 schrieb Bertrand Delacretaz:
> >>>> Hi,
> >>>>
> >>>> On Wed, Feb 16, 2011 at 10:49 PM, Carl Hall <ca...@hallwaytech.com>
> >>> wrote:
> >>>>> Is it possible to send the access log entries as OSGi events? I see
> the
> >>> use
> >>>>> of RequestLogger which doesn't have such capabilities. To send access
> >>> log
> >>>>> entries to as events, would a patch be required for SlingMainServlet
> et
> >>> al?
> >>>>
> >>>> In theory the LogReaderService might help for that, but the way our
> >>>> logging is implemented does not allow us to use it currently, see
> >>>> http://markmail.org/message/dlx5yvbjr74d46mh
> >>>>
> >>>> I think improving this would be useful, if someone has the cycles...
> >>>
> >>> As I already mentioned in the reference mail thread, using LogReader
> >>> does not work. I thought about reverting the LogService-SLF4J
> >>> interconnection in that SLF4J would log to LogService. But this turns
> >>> out to not be practical -- mostly because LogService does not allow the
> >>> same level of flexibility regarding log categories ....
> >>>
> >>> I really think the correct solution going forward (and needing cycles
> >>> here) would be to replace our home-grown SLF4J implementation with an
> >>> existing implementation (logback comes to mind) which would allows us
> >>> for better extensibility and reuse.
> >>>
> >>> Regards
> >>> Felix
> >>>
> >>>
> >>>>
> >>>> -Bertrand
> >>>>
> >>>> [1]
> >>>
> http://www.osgi.org/javadoc/r4v42/org/osgi/service/log/LogReaderService.html
> >>>
> >>>
> >>>
> >
> >
>
Re: Access Log as OSGi Events
Posted by Justin Edelson <ju...@justinedelson.com>.
Go Carl!!!
On Mar 3, 2011, at 2:58 AM, Felix Meschberger <fm...@adobe.com> wrote:
> Hi Carl,
>
> Am Mittwoch, den 02.03.2011, 21:37 +0000 schrieb Carl Hall:
>> Looks like I have bought some cycles to work on this. I am familiarizing
>> myself with the code now. I'll plan to first replace the homegrown impl with
>> logback. Any suggestions on direction or features are most welcomed.
>
> The most important point is, that existing configurations and
> configuration mechanisms (factory configurations for writers and
> loggers) must still be supported.
>
> Further points would then probably be extending the current
> configuration mechanisms to support more logback features:
>
> - different Appenders
> - Appender extension
Definitely in favor of these two conceptually, but I would prefer we didn't expose the implementation detail that we're using logback. Possible?
> - add Sling to the list of open-source projects using it
> (see http://logback.qos.ch)
>
> I think this will be a major rework. How about starting this in a
> whiteboard sandbox ?
>
> Regards
> Felix
>
>>
>>
>> On Fri, Feb 18, 2011 at 10:09 AM, Felix Meschberger <fm...@adobe.com>wrote:
>>
>>> Hi,
>>>
>>> Am Donnerstag, den 17.02.2011, 08:58 +0000 schrieb Bertrand Delacretaz:
>>>> Hi,
>>>>
>>>> On Wed, Feb 16, 2011 at 10:49 PM, Carl Hall <ca...@hallwaytech.com>
>>> wrote:
>>>>> Is it possible to send the access log entries as OSGi events? I see the
>>> use
>>>>> of RequestLogger which doesn't have such capabilities. To send access
>>> log
>>>>> entries to as events, would a patch be required for SlingMainServlet et
>>> al?
>>>>
>>>> In theory the LogReaderService might help for that, but the way our
>>>> logging is implemented does not allow us to use it currently, see
>>>> http://markmail.org/message/dlx5yvbjr74d46mh
>>>>
>>>> I think improving this would be useful, if someone has the cycles...
>>>
>>> As I already mentioned in the reference mail thread, using LogReader
>>> does not work. I thought about reverting the LogService-SLF4J
>>> interconnection in that SLF4J would log to LogService. But this turns
>>> out to not be practical -- mostly because LogService does not allow the
>>> same level of flexibility regarding log categories ....
>>>
>>> I really think the correct solution going forward (and needing cycles
>>> here) would be to replace our home-grown SLF4J implementation with an
>>> existing implementation (logback comes to mind) which would allows us
>>> for better extensibility and reuse.
>>>
>>> Regards
>>> Felix
>>>
>>>
>>>>
>>>> -Bertrand
>>>>
>>>> [1]
>>> http://www.osgi.org/javadoc/r4v42/org/osgi/service/log/LogReaderService.html
>>>
>>>
>>>
>
>
Re: Access Log as OSGi Events
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Carl,
Am Mittwoch, den 02.03.2011, 21:37 +0000 schrieb Carl Hall:
> Looks like I have bought some cycles to work on this. I am familiarizing
> myself with the code now. I'll plan to first replace the homegrown impl with
> logback. Any suggestions on direction or features are most welcomed.
The most important point is, that existing configurations and
configuration mechanisms (factory configurations for writers and
loggers) must still be supported.
Further points would then probably be extending the current
configuration mechanisms to support more logback features:
- different Appenders
- Appender extension
- add Sling to the list of open-source projects using it
(see http://logback.qos.ch)
I think this will be a major rework. How about starting this in a
whiteboard sandbox ?
Regards
Felix
>
>
> On Fri, Feb 18, 2011 at 10:09 AM, Felix Meschberger <fm...@adobe.com>wrote:
>
> > Hi,
> >
> > Am Donnerstag, den 17.02.2011, 08:58 +0000 schrieb Bertrand Delacretaz:
> > > Hi,
> > >
> > > On Wed, Feb 16, 2011 at 10:49 PM, Carl Hall <ca...@hallwaytech.com>
> > wrote:
> > > > Is it possible to send the access log entries as OSGi events? I see the
> > use
> > > > of RequestLogger which doesn't have such capabilities. To send access
> > log
> > > > entries to as events, would a patch be required for SlingMainServlet et
> > al?
> > >
> > > In theory the LogReaderService might help for that, but the way our
> > > logging is implemented does not allow us to use it currently, see
> > > http://markmail.org/message/dlx5yvbjr74d46mh
> > >
> > > I think improving this would be useful, if someone has the cycles...
> >
> > As I already mentioned in the reference mail thread, using LogReader
> > does not work. I thought about reverting the LogService-SLF4J
> > interconnection in that SLF4J would log to LogService. But this turns
> > out to not be practical -- mostly because LogService does not allow the
> > same level of flexibility regarding log categories ....
> >
> > I really think the correct solution going forward (and needing cycles
> > here) would be to replace our home-grown SLF4J implementation with an
> > existing implementation (logback comes to mind) which would allows us
> > for better extensibility and reuse.
> >
> > Regards
> > Felix
> >
> >
> > >
> > > -Bertrand
> > >
> > > [1]
> > http://www.osgi.org/javadoc/r4v42/org/osgi/service/log/LogReaderService.html
> >
> >
> >
Re: Access Log as OSGi Events
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Mar 3, 2011 at 9:12 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> ...I wanted to use the OSGi LogReaderService for this, but as Felix
> explained in [1] that only works for logs that use the OSGi LogService
> directly, not for slf4j logs....
[1] being http://markmail.org/thread/dlx5yvbjr74d46mh
-Bertrand
Re: Access Log as OSGi Events
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Carl,
On Wed, Mar 2, 2011 at 10:37 PM, Carl Hall <ca...@hallwaytech.com> wrote:
> Looks like I have bought some cycles to work on this. I am familiarizing
> myself with the code now. I'll plan to first replace the homegrown impl with
> logback. Any suggestions on direction or features are most welcomed....
Cool - one thing that I tried to do a while ago and wasn't possible is
to selectively intercept log messages in order to log them as
"application logs", for example to record important user or system
operations.
I wanted to use the OSGi LogReaderService for this, but as Felix
explained in [1] that only works for logs that use the OSGi LogService
directly, not for slf4j logs.
If you redesign our logging system, it would be nice to remove this
limitation, with a capture mechanism that gets both LogService and
slf4j logs.
-Bertrand