Logging quo vadis

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Logging quo vadis

Felix Meschberger-3
Hi all,

Over the last few week I have been thinking about our logging bundle and
what we do and include.

Basically, the logging bundle is/does...

  - Implements OSGi LogService on top of SLF4J
  - Implements SLF4J
  - Provides Configuration Admin driven configuration
  - Exports SLF4J API
  - Exports Commons Logging API
  - Exports Log4J API
  - Exports OSGi LogService API

Now, many of these things can be ripped apart into separate bundles.
Actually the SLF4J project libraries SLF4J API, Log4J-over-SLF4J, and
Commons-Logging-over-SLF4J already come as bundles.

Likewise we could separate the implementation of the OSGi LogService
over SLF4J into its own small bundle.

Finally remains the actual SLF4J implementation: This can be its own
bundle again (SLF4J API actually imports the SLF4J impl package) and
provide the well-known and beloved Configuration Admin support while
internally (over time) change the implementation to, say, logback for
even more logging options.

The drawback is, that we are talking about 5 bundles instead of just a
single one.

WDYT ?

Regards
Felix
--
[hidden email]
+41 61 226 98 44

Reply | Threaded
Open this post in threaded view
|

Re: Logging quo vadis

justzzzz
On Mon, Jan 10, 2011 at 5:08 PM, Felix Meschberger <[hidden email]>wrote:

> Hi all,
>
> Over the last few week I have been thinking about our logging bundle and
> what we do and include.
>
> Basically, the logging bundle is/does...
>
>  - Implements OSGi LogService on top of SLF4J
>  - Implements SLF4J
>  - Provides Configuration Admin driven configuration
>  - Exports SLF4J API
>  - Exports Commons Logging API
>  - Exports Log4J API
>  - Exports OSGi LogService API
>
> Now, many of these things can be ripped apart into separate bundles.
> Actually the SLF4J project libraries SLF4J API, Log4J-over-SLF4J, and
> Commons-Logging-over-SLF4J already come as bundles.
>
> Likewise we could separate the implementation of the OSGi LogService
> over SLF4J into its own small bundle.
>
> Finally remains the actual SLF4J implementation: This can be its own
> bundle again (SLF4J API actually imports the SLF4J impl package) and
> provide the well-known and beloved Configuration Admin support while
> internally (over time) change the implementation to, say, logback for
> even more logging options.
>
> The drawback is, that we are talking about 5 bundles instead of just a
> single one.
>
> WDYT ?
>

Personally, I like our unified bundle approach. I suppose it is slightly
inefficient, but I think the simplicity of installing a single bundle and
getting all the major logging APIs directed to a single logging service is
worth the inefficiency.

Justin


>
> Regards
> Felix
> --
> [hidden email]
> +41 61 226 98 44
>
>
JCR
Reply | Threaded
Open this post in threaded view
|

Conditional GET/is-modified-since

JCR
Hi all,

After browsing through some email archives, in particular the treffic of
28-apr-2010, it does not become quite clear if there is support for
conditional GET/caching, and in particular for is-modified-since headers
in Sling.

Can somebody shed light, if and per which version there is some
"built-in" support for this mechanism?

Thanks,
Jurg

Reply | Threaded
Open this post in threaded view
|

Re: Conditional GET/is-modified-since

Felix Meschberger-3
Hi

Am Dienstag, den 11.01.2011, 09:00 +0000 schrieb Jurg:
> Hi all,
>
> After browsing through some email archives, in particular the treffic of
> 28-apr-2010, it does not become quite clear if there is support for
> conditional GET/caching, and in particular for is-modified-since headers
> in Sling.
>
> Can somebody shed light, if and per which version there is some
> "built-in" support for this mechanism?

The DefaultGetServlet for streaming binary data (used e.g. if you stored
an image in the repository you and you GET it) supports
if-modified-since for quite some time now.

Regards
Felix

>
> Thanks,
> Jurg
>


Reply | Threaded
Open this post in threaded view
|

Re: Logging quo vadis

Mike Moulton
In reply to this post by Felix Meschberger-3
For what it's worth, my feeling is that you shouldn't re-invent the wheel when there appears to be a good solution maintained by those whose primary objective is logging. Not to mention, the thought of switching to logback over time is very intriguing.

+1 for replacing the single bundle with SLF4J (non-binding)

--

mike moulton | meltmedia

[hidden email]
w | 602.648.6810
c | 602.432.2568
@mmoulton



On Jan 10, 2011, at 3:08 PM, Felix Meschberger wrote:

> Hi all,
>
> Over the last few week I have been thinking about our logging bundle and
> what we do and include.
>
> Basically, the logging bundle is/does...
>
>  - Implements OSGi LogService on top of SLF4J
>  - Implements SLF4J
>  - Provides Configuration Admin driven configuration
>  - Exports SLF4J API
>  - Exports Commons Logging API
>  - Exports Log4J API
>  - Exports OSGi LogService API
>
> Now, many of these things can be ripped apart into separate bundles.
> Actually the SLF4J project libraries SLF4J API, Log4J-over-SLF4J, and
> Commons-Logging-over-SLF4J already come as bundles.
>
> Likewise we could separate the implementation of the OSGi LogService
> over SLF4J into its own small bundle.
>
> Finally remains the actual SLF4J implementation: This can be its own
> bundle again (SLF4J API actually imports the SLF4J impl package) and
> provide the well-known and beloved Configuration Admin support while
> internally (over time) change the implementation to, say, logback for
> even more logging options.
>
> The drawback is, that we are talking about 5 bundles instead of just a
> single one.
>
> WDYT ?
>
> Regards
> Felix
> --
> [hidden email]
> +41 61 226 98 44
>

Reply | Threaded
Open this post in threaded view
|

Re: Logging quo vadis

Carsten Ziegeler
In reply to this post by justzzzz
Justin Edelson  wrote
>
> Personally, I like our unified bundle approach. I suppose it is slightly
> inefficient, but I think the simplicity of installing a single bundle and
> getting all the major logging APIs directed to a single logging service is
> worth the inefficiency.
>
Yes, I agree with Justin - especially as the logging libs are not
changing that much anymore (well, there are exceptions to this of course...)

Carsten
--
Carsten Ziegeler
[hidden email]