You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Guillaume Nodet <gn...@gmail.com> on 2010/02/16 11:01:51 UTC
[DISCUSS] Logging framework
It seems we use different mechanism for logging in various parts.
Blueprint uses slf4j api, jmx-core uses a facade on the osgi logging
service (but which won't work if the logging service package isn't
available at all), jmx-blueprint-core uses System.out.
I'd like us to choose one way and stick with it.
The slf4j api is a nice api to use, but it brings an additional
dependency. If the goal is really to reduce the amount of
dependencies, we can use either java.util.logging or a cleaner facade
on top of the osgi logging service (were we can actually not require
the logging pacakge). If we want to use a facade, i'd suggest moving
it into its own maven module and including it in various osgi bundles
(to keep standalone bundles). The size of this facade should be small
enough so that it does not really matter to duplicate it.
Thoughts ?
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Logging framework
Posted by David Jencks <da...@yahoo.com>.
I like slf4j. I don't see how writing our own logging facade would
have fewer dependencies than using slf4j. So far in osgi-land I'm
pretty happy with pax-logging which exports slf4j apis.
thanks
david jencks
On Feb 16, 2010, at 2:01 AM, Guillaume Nodet wrote:
> It seems we use different mechanism for logging in various parts.
> Blueprint uses slf4j api, jmx-core uses a facade on the osgi logging
> service (but which won't work if the logging service package isn't
> available at all), jmx-blueprint-core uses System.out.
> I'd like us to choose one way and stick with it.
>
> The slf4j api is a nice api to use, but it brings an additional
> dependency. If the goal is really to reduce the amount of
> dependencies, we can use either java.util.logging or a cleaner facade
> on top of the osgi logging service (were we can actually not require
> the logging pacakge). If we want to use a facade, i'd suggest moving
> it into its own maven module and including it in various osgi bundles
> (to keep standalone bundles). The size of this facade should be small
> enough so that it does not really matter to duplicate it.
>
> Thoughts ?
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: [DISCUSS] Logging framework
Posted by Alasdair Nottingham <no...@apache.org>.
I agree we should standardize on a single logging library. I'm happy
for it to be SLF4J since you can choose to plug it into other logging
frameworks such as java.util.logging or the OSGi LogService by
installing a different log adapter.
I'd rather not write a new adapter layer, logging is not core to what
we do in aries.
Alasdair
On 16 February 2010 10:13, Guillaume Nodet <gn...@gmail.com> wrote:
> On Tue, Feb 16, 2010 at 11:09, Felix Meschberger <fm...@gmail.com> wrote:
>> Hi,
>>
>> From the peanout gallery of an interested observer ....
>>
>> On 16.02.2010 11:01, Guillaume Nodet wrote:
>>> It seems we use different mechanism for logging in various parts.
>>> Blueprint uses slf4j api, jmx-core uses a facade on the osgi logging
>>> service (but which won't work if the logging service package isn't
>>> available at all), jmx-blueprint-core uses System.out.
>>> I'd like us to choose one way and stick with it.
>>>
>>> The slf4j api is a nice api to use, but it brings an additional
>>> dependency. If the goal is really to reduce the amount of
>>> dependencies, we can use either java.util.logging or a cleaner facade
>>> on top of the osgi logging service (were we can actually not require
>>> the logging pacakge). If we want to use a facade, i'd suggest moving
>>> it into its own maven module and including it in various osgi bundles
>>> (to keep standalone bundles). The size of this facade should be small
>>> enough so that it does not really matter to duplicate it.
>>
>> I would suggest to go for SLF4J since it has a really nice API for
>> lazy-formatting messages and is simple to implement.
>
> I personally agree with that.
>
>>
>> As for the OSGi LogService, I suggest to integrate this with the logging
>> implementation used.
>>
>> Finally, I suggest to not reinvent the wheel but to draw on existing
>> open-source (and ASL2 licensed) stuff, like Apache Felix log bundle, the
>> Apache Sling log bundle (providing SLF4J API, a LogService
>> implementation as well as support for Log4J and Commons Logging API) or
>> the OPS4J logging bundle(s) (which provide a similar level of
>> integration as provided by the Sling log bundle).
>
> I wasn't suggesting rewriting a log service at all. Sorry if that was
> not clear.
> My point of using a facade was only something like the log utility
> class in fileinstall:
> http://svn.apache.org/repos/asf/felix/trunk/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/Util.java
>
>
>> Regards
>> Felix
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: [DISCUSS] Logging framework
Posted by Guillaume Nodet <gn...@gmail.com>.
On Tue, Feb 16, 2010 at 11:09, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> From the peanout gallery of an interested observer ....
>
> On 16.02.2010 11:01, Guillaume Nodet wrote:
>> It seems we use different mechanism for logging in various parts.
>> Blueprint uses slf4j api, jmx-core uses a facade on the osgi logging
>> service (but which won't work if the logging service package isn't
>> available at all), jmx-blueprint-core uses System.out.
>> I'd like us to choose one way and stick with it.
>>
>> The slf4j api is a nice api to use, but it brings an additional
>> dependency. If the goal is really to reduce the amount of
>> dependencies, we can use either java.util.logging or a cleaner facade
>> on top of the osgi logging service (were we can actually not require
>> the logging pacakge). If we want to use a facade, i'd suggest moving
>> it into its own maven module and including it in various osgi bundles
>> (to keep standalone bundles). The size of this facade should be small
>> enough so that it does not really matter to duplicate it.
>
> I would suggest to go for SLF4J since it has a really nice API for
> lazy-formatting messages and is simple to implement.
I personally agree with that.
>
> As for the OSGi LogService, I suggest to integrate this with the logging
> implementation used.
>
> Finally, I suggest to not reinvent the wheel but to draw on existing
> open-source (and ASL2 licensed) stuff, like Apache Felix log bundle, the
> Apache Sling log bundle (providing SLF4J API, a LogService
> implementation as well as support for Log4J and Commons Logging API) or
> the OPS4J logging bundle(s) (which provide a similar level of
> integration as provided by the Sling log bundle).
I wasn't suggesting rewriting a log service at all. Sorry if that was
not clear.
My point of using a facade was only something like the log utility
class in fileinstall:
http://svn.apache.org/repos/asf/felix/trunk/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/Util.java
> Regards
> Felix
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Logging framework
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
>From the peanout gallery of an interested observer ....
On 16.02.2010 11:01, Guillaume Nodet wrote:
> It seems we use different mechanism for logging in various parts.
> Blueprint uses slf4j api, jmx-core uses a facade on the osgi logging
> service (but which won't work if the logging service package isn't
> available at all), jmx-blueprint-core uses System.out.
> I'd like us to choose one way and stick with it.
>
> The slf4j api is a nice api to use, but it brings an additional
> dependency. If the goal is really to reduce the amount of
> dependencies, we can use either java.util.logging or a cleaner facade
> on top of the osgi logging service (were we can actually not require
> the logging pacakge). If we want to use a facade, i'd suggest moving
> it into its own maven module and including it in various osgi bundles
> (to keep standalone bundles). The size of this facade should be small
> enough so that it does not really matter to duplicate it.
I would suggest to go for SLF4J since it has a really nice API for
lazy-formatting messages and is simple to implement.
As for the OSGi LogService, I suggest to integrate this with the logging
implementation used.
Finally, I suggest to not reinvent the wheel but to draw on existing
open-source (and ASL2 licensed) stuff, like Apache Felix log bundle, the
Apache Sling log bundle (providing SLF4J API, a LogService
implementation as well as support for Log4J and Commons Logging API) or
the OPS4J logging bundle(s) (which provide a similar level of
integration as provided by the Sling log bundle).
Regards
Felix