You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Graham Charters <gc...@gmail.com> on 2012/02/01 12:05:50 UTC
[DISCUSS] Logging for Aries modules
Guillaume's starter....
"Can't we simply do something in aries until that would be shared by
all aries modules (since they kinda all depend on it already) ?
A very small api that could be configured to either use slf4j, jul or
osgi logging ? Using optional imports, it should limit to what's
available and default to a good one, falling back to jul if nothing"
---------- Forwarded message ----------
From: Guillaume Nodet <gn...@gmail.com>
Date: 1 February 2012 10:46
Subject: Re: Aries JNDI dependencies
To: dev@aries.apache.org
Can't we simply do something in aries until that would be shared by
all aries modules (since they kinda all depend on it already) ?
A very small api that could be configured to either use slf4j, jul or
osgi logging ? Using optional imports, it should limit to what's
available and default to a good one, falling back to jul if nothing
else.
On Wed, Feb 1, 2012 at 11:26, David Bosschaert
<da...@gmail.com> wrote:
> Hi all,
>
> On 1 February 2012 09:58, Graham Charters <gc...@gmail.com> wrote:
>> Hi David,
>>
>> Prior to these changes, Apache Aries had the ability to filter logging
>> per class, and this was consistent across all Aries modules.
>
> Well apparently not because the Aries JMX component used the
> LogService already...
>
>> I don't
>> think we should be doing piecemeal infrastructure dependency changes
>> like these without a proper consideration.
>
> Well, you can see at the beginning of this thread (Jan 16) that I'm
> asking for opinions re removing to the LogService and that the
> responses where positive...
>
>> Although nobody really wants to have a logging conversation, I don't
>> think we can avoid one, and until then, I think we need to go back to
>> the consistent approach that, until now, Aries consumers seemed happy
>> with.
>
> ... sigh ... ok we'll have a logging discussion and I'll revert those
> changes for the moment.
>
> @David J: we can explore the capabilities of the log service in that discussion.
>
> Best regards,
>
> David
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: [DISCUSS] Logging for Aries modules
Posted by Łukasz Dywicki <lu...@code-house.org>.
I see the issue,
Can't you simply write a slf4j backed which uses a LogService or start using pax-logging? It exposes a LogService and lets you to use slf4, log4j, commons api to feed event stream.
This is not really typical scenario when you have log service (which, I belive, uses some logging library) and you have not slf4j addapter for it.
Best regards,
Lukasz Dywicki
--
Code-House
http://code-house.org
Wiadomość napisana przez David Bosschaert w dniu 1 lut 2012, o godz. 14:53:
> My issue with it is that it brings in 2 dependencies: the SLF4J api
> and an SLF4J implementation bundle.
> In the context where I want to use the JNDI component there is already
> a log subsystem in place, which can be reached through the OSGi
> LogService, so adding those 2 SLF4J bundles brings in dependencies
> that appear like noise.
>
> I would like components to have minimal dependencies which makes them
> more suitable for reuse in different contexts.
>
> Although I'm not a big fan of yet-another-logging-abstraction-layer,
> if we do the logging through an API in the Aries Util component which
> then forwards to whatever is configured with it I think it can satisfy
> everybody's needs, although I'm open to other suggestions...
>
> On 1 February 2012 13:16, Graham Charters <gc...@gmail.com> wrote:
>> Hi David,
>>
>> Could you clarify the issues with SLF4J? It would seem we could end
>> up replacing one logging wrapper API with our own. You mentioned you
>> require two bundles that are unnecessary. Is their size an issue? Is
>> there some refactoring that could be done in SLF4J to improve the
>> situation? Could your own logging sit behind SLF4J or does this cause
>> other issues?
>>
>> Regards, Graham.
>>
>> On 1 February 2012 12:38, Guillaume Nodet <gn...@gmail.com> wrote:
>>> Because the osgi log service has a crappy api which is too limited ?
>>>
>>> On Wed, Feb 1, 2012 at 12:56, Felix Meschberger <fm...@adobe.com> wrote:
>>>> Hi
>>>>
>>>> Really ? YALA ?
>>>>
>>>> Why not just settle all Aries on LogService (maybe even through some utility to guard against LogService being away) or SLF4J ?
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>> Am 01.02.2012 um 12:51 schrieb David Bosschaert:
>>>>
>>>>> Yes, I'd like to have something that has minimal dependencies, but
>>>>> putting it in Aries Util is fine with me as most components depend on
>>>>> that anyway.
>>>>>
>>>>> While working with the LogService I put some code that I found in the
>>>>> Aries JMX component that makes working with the OSGi LogService easier
>>>>> in Util. You can find it here:
>>>>> http://svn.apache.org/repos/asf/aries/trunk/util/util-r42/src/main/java/org/apache/aries/util/log/Logger.java
>>>>>
>>>>> Maybe we can extend this class to provide a simple API that provides
>>>>> all the needed inputs for all uses (including classname-based
>>>>> initialization) so it can delegate appropriately.
>>>>>
>>>>> David
>>>>>
>>>>> On 1 February 2012 11:05, Graham Charters <gc...@gmail.com> wrote:
>>>>>> Guillaume's starter....
>>>>>>
>>>>>> "Can't we simply do something in aries until that would be shared by
>>>>>> all aries modules (since they kinda all depend on it already) ?
>>>>>> A very small api that could be configured to either use slf4j, jul or
>>>>>> osgi logging ? Using optional imports, it should limit to what's
>>>>>> available and default to a good one, falling back to jul if nothing"
>>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Guillaume Nodet <gn...@gmail.com>
>>>>>> Date: 1 February 2012 10:46
>>>>>> Subject: Re: Aries JNDI dependencies
>>>>>> To: dev@aries.apache.org
>>>>>>
>>>>>>
>>>>>> Can't we simply do something in aries until that would be shared by
>>>>>> all aries modules (since they kinda all depend on it already) ?
>>>>>> A very small api that could be configured to either use slf4j, jul or
>>>>>> osgi logging ? Using optional imports, it should limit to what's
>>>>>> available and default to a good one, falling back to jul if nothing
>>>>>> else.
>>>>>>
>>>>>> On Wed, Feb 1, 2012 at 11:26, David Bosschaert
>>>>>> <da...@gmail.com> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> On 1 February 2012 09:58, Graham Charters <gc...@gmail.com> wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> Prior to these changes, Apache Aries had the ability to filter logging
>>>>>>>> per class, and this was consistent across all Aries modules.
>>>>>>>
>>>>>>> Well apparently not because the Aries JMX component used the
>>>>>>> LogService already...
>>>>>>>
>>>>>>>> I don't
>>>>>>>> think we should be doing piecemeal infrastructure dependency changes
>>>>>>>> like these without a proper consideration.
>>>>>>>
>>>>>>> Well, you can see at the beginning of this thread (Jan 16) that I'm
>>>>>>> asking for opinions re removing to the LogService and that the
>>>>>>> responses where positive...
>>>>>>>
>>>>>>>> Although nobody really wants to have a logging conversation, I don't
>>>>>>>> think we can avoid one, and until then, I think we need to go back to
>>>>>>>> the consistent approach that, until now, Aries consumers seemed happy
>>>>>>>> with.
>>>>>>>
>>>>>>> ... sigh ... ok we'll have a logging discussion and I'll revert those
>>>>>>> changes for the moment.
>>>>>>>
>>>>>>> @David J: we can explore the capabilities of the log service in that discussion.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> David
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> FuseSource, Integration everywhere
>>>>>> http://fusesource.com
>>>>
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> FuseSource, Integration everywhere
>>> http://fusesource.com
Re: [DISCUSS] Logging for Aries modules
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi David,
why YALA?
If you really are in need of the LogService, just use Pax-Logging. You can
use any kind of Logging api you like, log4j, slf4j, etc.., you name it
pax-logging got it.
If there is still one missing, it's open source add it. I just do not
understand why re-inventing the wheel does help here.
just my 2 cents here, Achim
2012/2/3 David Bosschaert <da...@gmail.com>
> Hi all,
>
> Although I do acknowledge Graham's point that if Util gets refactored
> into a number of separate modules that we will end up with additional
> modules for logging again, I'm not sure how realistic the need for
> this is in the medium-long term, I would say we cross that bridge when
> we get there :)
>
> As an Enterprise OSGi Component project it seems natural to me that
> Aries would natively support the OSGi LogService.
>
> Having a solution in Aries Util could address the needs of everyone on
> the thread (except for those who are totally against adding a layer
> here):
> * It could connect to SLF4J, if available, in which case the ultimate
> logged message would end up exactly as it is today (addressing Mark
> and David J's requirements).
> * It could connect to the OSGi LogService, if available, addressing my
> use-case.
> * It could capture the current classname when the logger is object is
> contructed. When bound to SLF4J this is simply passed on to SLF4J, but
> in the case of the OSGi LogService it can be prefixed to the log
> messages sent to it effectively adding this feature to the OSGi
> LogService.
> * It can provide a more user-friendly API than the OSGi LogService -
> I'm thinking similar to SLF4J debug(), info(), warn() etc (addressing
> Guillaumes' point).
> * Other bridges (e.g. for java.util.logging) could be provided too.
> It would not add any additional mandatory imports to Aries Util and
> would remove the mandatory dependency on SLF4J.
>
> Some of the suggestions here are how I can make my usecase work with
> SLF4J. This is not my problem. As stated before, my main interest is
> in reducing mandatory dependencies.
>
> I'm happy to come up with an actual prototype for this...
>
> Best regards,
>
> David
>
> On 1 February 2012 17:16, David Jencks <da...@yahoo.com> wrote:
> > AFAICT no one disputes that slf4j has more capabilities than LogService
> (logging per category/class).
> >
> > Slf4j is designed as a minimal logging interface with easliy pluggable
> backends, and its really widely used as such.
> >
> > I'm strongly in favor of keeping using slf4j.
> > I'm strongly against duplicating slf4j in an aries package.
> >
> > David B, since your logging backend already has several adaptation
> capabilities, can you add the slf4j-api classes to your logging backend
> along with adapter classes like pax-logging?
> >
> > -rw-rw-rw- 11150 10-Jan-2012 16:41:00
> org/ops4j/pax/logging/slf4j/Slf4jLogger.class
> > -rw-rw-rw- 2622 10-Jan-2012 16:41:00
> org/ops4j/pax/logging/slf4j/Slf4jLoggerFactory.class
> > -rw-rw-rw- 2205 10-Jan-2012 16:41:00
> org/ops4j/pax/logging/slf4j/Slf4jMDCAdapter.class
> >
> > This is what pax-logging does. Maybe it's possible to leave out some of
> the slf4j api classes, I didn't look.
> >
> > thanks
> > david jencks
> >
> > On Feb 1, 2012, at 7:43 AM, David Bosschaert wrote:
> >
> >> On 1 February 2012 15:29, Felix Meschberger <fm...@adobe.com> wrote:
> >>> Hi,
> >>>
> >>> Am 01.02.2012 um 14:53 schrieb David Bosschaert:
> >>>
> >>>> My issue with it is that it brings in 2 dependencies: the SLF4J api
> >>>> and an SLF4J implementation bundle.
> >>>> In the context where I want to use the JNDI component there is already
> >>>> a log subsystem in place, which can be reached through the OSGi
> >>>> LogService, so adding those 2 SLF4J bundles brings in dependencies
> >>>> that appear like noise.
> >>>
> >>> Got it.
> >>>
> >>> In my setup I already use SLF4J (and LogService and Log4J and Commons
> Logging). Adding yet another logging API just adds another dependency to my
> setup and adds CPU consumption and learning curve experiences and makes my
> users wonder.
> >>
> >> Well, if Aries has a small log API in its util component that wouldn't
> >> add any dependencies, because most things in Aries already depend on
> >> util.
> >> That component could then delegate to SLF4J, the OSGi LogService or
> >> whatever bringing only those dependencies in that are actually used.
> >> So for your use-case you should still be able to use it with SLF4J,
> >> but for my usecase I don't need to.
> >
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Re: [DISCUSS] Logging for Aries modules
Posted by Łukasz Dywicki <lu...@code-house.org>.
David,
Most of people here opted to stay with slf4j and, as I understand they do not see any need to change aries util and implement logging adapter. As you see in points provided by you from Mark, David J., Guillaume, Graham, Christian Schneider, they are happy with how the logging is done.
If you wish to use LogService as backend then implement adapter for slf4j. This is the purpose of using slf4j - to be independant from logging implementation and have pluggable backend. The dependency to logging API is really small, and most of libraries depends on that. I see nothing wrong it this.
Best regards,
Lukasz Dywicki
--
Code-House
http://code-house.org
Wiadomość napisana przez David Bosschaert w dniu 3 lut 2012, o godz. 11:37:
> Hi all,
>
> Although I do acknowledge Graham's point that if Util gets refactored
> into a number of separate modules that we will end up with additional
> modules for logging again, I'm not sure how realistic the need for
> this is in the medium-long term, I would say we cross that bridge when
> we get there :)
>
> As an Enterprise OSGi Component project it seems natural to me that
> Aries would natively support the OSGi LogService.
>
> Having a solution in Aries Util could address the needs of everyone on
> the thread (except for those who are totally against adding a layer
> here):
> * It could connect to SLF4J, if available, in which case the ultimate
> logged message would end up exactly as it is today (addressing Mark
> and David J's requirements).
> * It could connect to the OSGi LogService, if available, addressing my use-case.
> * It could capture the current classname when the logger is object is
> contructed. When bound to SLF4J this is simply passed on to SLF4J, but
> in the case of the OSGi LogService it can be prefixed to the log
> messages sent to it effectively adding this feature to the OSGi
> LogService.
> * It can provide a more user-friendly API than the OSGi LogService -
> I'm thinking similar to SLF4J debug(), info(), warn() etc (addressing
> Guillaumes' point).
> * Other bridges (e.g. for java.util.logging) could be provided too.
> It would not add any additional mandatory imports to Aries Util and
> would remove the mandatory dependency on SLF4J.
>
> Some of the suggestions here are how I can make my usecase work with
> SLF4J. This is not my problem. As stated before, my main interest is
> in reducing mandatory dependencies.
>
> I'm happy to come up with an actual prototype for this...
>
> Best regards,
>
> David
>
> On 1 February 2012 17:16, David Jencks <da...@yahoo.com> wrote:
>> AFAICT no one disputes that slf4j has more capabilities than LogService (logging per category/class).
>>
>> Slf4j is designed as a minimal logging interface with easliy pluggable backends, and its really widely used as such.
>>
>> I'm strongly in favor of keeping using slf4j.
>> I'm strongly against duplicating slf4j in an aries package.
>>
>> David B, since your logging backend already has several adaptation capabilities, can you add the slf4j-api classes to your logging backend along with adapter classes like pax-logging?
>>
>> -rw-rw-rw- 11150 10-Jan-2012 16:41:00 org/ops4j/pax/logging/slf4j/Slf4jLogger.class
>> -rw-rw-rw- 2622 10-Jan-2012 16:41:00 org/ops4j/pax/logging/slf4j/Slf4jLoggerFactory.class
>> -rw-rw-rw- 2205 10-Jan-2012 16:41:00 org/ops4j/pax/logging/slf4j/Slf4jMDCAdapter.class
>>
>> This is what pax-logging does. Maybe it's possible to leave out some of the slf4j api classes, I didn't look.
>>
>> thanks
>> david jencks
>>
>> On Feb 1, 2012, at 7:43 AM, David Bosschaert wrote:
>>
>>> On 1 February 2012 15:29, Felix Meschberger <fm...@adobe.com> wrote:
>>>> Hi,
>>>>
>>>> Am 01.02.2012 um 14:53 schrieb David Bosschaert:
>>>>
>>>>> My issue with it is that it brings in 2 dependencies: the SLF4J api
>>>>> and an SLF4J implementation bundle.
>>>>> In the context where I want to use the JNDI component there is already
>>>>> a log subsystem in place, which can be reached through the OSGi
>>>>> LogService, so adding those 2 SLF4J bundles brings in dependencies
>>>>> that appear like noise.
>>>>
>>>> Got it.
>>>>
>>>> In my setup I already use SLF4J (and LogService and Log4J and Commons Logging). Adding yet another logging API just adds another dependency to my setup and adds CPU consumption and learning curve experiences and makes my users wonder.
>>>
>>> Well, if Aries has a small log API in its util component that wouldn't
>>> add any dependencies, because most things in Aries already depend on
>>> util.
>>> That component could then delegate to SLF4J, the OSGi LogService or
>>> whatever bringing only those dependencies in that are actually used.
>>> So for your use-case you should still be able to use it with SLF4J,
>>> but for my usecase I don't need to.
>>
Re: [DISCUSS] Logging for Aries modules
Posted by David Bosschaert <da...@gmail.com>.
Hi all,
Although I do acknowledge Graham's point that if Util gets refactored
into a number of separate modules that we will end up with additional
modules for logging again, I'm not sure how realistic the need for
this is in the medium-long term, I would say we cross that bridge when
we get there :)
As an Enterprise OSGi Component project it seems natural to me that
Aries would natively support the OSGi LogService.
Having a solution in Aries Util could address the needs of everyone on
the thread (except for those who are totally against adding a layer
here):
* It could connect to SLF4J, if available, in which case the ultimate
logged message would end up exactly as it is today (addressing Mark
and David J's requirements).
* It could connect to the OSGi LogService, if available, addressing my use-case.
* It could capture the current classname when the logger is object is
contructed. When bound to SLF4J this is simply passed on to SLF4J, but
in the case of the OSGi LogService it can be prefixed to the log
messages sent to it effectively adding this feature to the OSGi
LogService.
* It can provide a more user-friendly API than the OSGi LogService -
I'm thinking similar to SLF4J debug(), info(), warn() etc (addressing
Guillaumes' point).
* Other bridges (e.g. for java.util.logging) could be provided too.
It would not add any additional mandatory imports to Aries Util and
would remove the mandatory dependency on SLF4J.
Some of the suggestions here are how I can make my usecase work with
SLF4J. This is not my problem. As stated before, my main interest is
in reducing mandatory dependencies.
I'm happy to come up with an actual prototype for this...
Best regards,
David
On 1 February 2012 17:16, David Jencks <da...@yahoo.com> wrote:
> AFAICT no one disputes that slf4j has more capabilities than LogService (logging per category/class).
>
> Slf4j is designed as a minimal logging interface with easliy pluggable backends, and its really widely used as such.
>
> I'm strongly in favor of keeping using slf4j.
> I'm strongly against duplicating slf4j in an aries package.
>
> David B, since your logging backend already has several adaptation capabilities, can you add the slf4j-api classes to your logging backend along with adapter classes like pax-logging?
>
> -rw-rw-rw- 11150 10-Jan-2012 16:41:00 org/ops4j/pax/logging/slf4j/Slf4jLogger.class
> -rw-rw-rw- 2622 10-Jan-2012 16:41:00 org/ops4j/pax/logging/slf4j/Slf4jLoggerFactory.class
> -rw-rw-rw- 2205 10-Jan-2012 16:41:00 org/ops4j/pax/logging/slf4j/Slf4jMDCAdapter.class
>
> This is what pax-logging does. Maybe it's possible to leave out some of the slf4j api classes, I didn't look.
>
> thanks
> david jencks
>
> On Feb 1, 2012, at 7:43 AM, David Bosschaert wrote:
>
>> On 1 February 2012 15:29, Felix Meschberger <fm...@adobe.com> wrote:
>>> Hi,
>>>
>>> Am 01.02.2012 um 14:53 schrieb David Bosschaert:
>>>
>>>> My issue with it is that it brings in 2 dependencies: the SLF4J api
>>>> and an SLF4J implementation bundle.
>>>> In the context where I want to use the JNDI component there is already
>>>> a log subsystem in place, which can be reached through the OSGi
>>>> LogService, so adding those 2 SLF4J bundles brings in dependencies
>>>> that appear like noise.
>>>
>>> Got it.
>>>
>>> In my setup I already use SLF4J (and LogService and Log4J and Commons Logging). Adding yet another logging API just adds another dependency to my setup and adds CPU consumption and learning curve experiences and makes my users wonder.
>>
>> Well, if Aries has a small log API in its util component that wouldn't
>> add any dependencies, because most things in Aries already depend on
>> util.
>> That component could then delegate to SLF4J, the OSGi LogService or
>> whatever bringing only those dependencies in that are actually used.
>> So for your use-case you should still be able to use it with SLF4J,
>> but for my usecase I don't need to.
>
Re: [DISCUSS] Logging for Aries modules
Posted by David Jencks <da...@yahoo.com>.
AFAICT no one disputes that slf4j has more capabilities than LogService (logging per category/class).
Slf4j is designed as a minimal logging interface with easliy pluggable backends, and its really widely used as such.
I'm strongly in favor of keeping using slf4j.
I'm strongly against duplicating slf4j in an aries package.
David B, since your logging backend already has several adaptation capabilities, can you add the slf4j-api classes to your logging backend along with adapter classes like pax-logging?
-rw-rw-rw- 11150 10-Jan-2012 16:41:00 org/ops4j/pax/logging/slf4j/Slf4jLogger.class
-rw-rw-rw- 2622 10-Jan-2012 16:41:00 org/ops4j/pax/logging/slf4j/Slf4jLoggerFactory.class
-rw-rw-rw- 2205 10-Jan-2012 16:41:00 org/ops4j/pax/logging/slf4j/Slf4jMDCAdapter.class
This is what pax-logging does. Maybe it's possible to leave out some of the slf4j api classes, I didn't look.
thanks
david jencks
On Feb 1, 2012, at 7:43 AM, David Bosschaert wrote:
> On 1 February 2012 15:29, Felix Meschberger <fm...@adobe.com> wrote:
>> Hi,
>>
>> Am 01.02.2012 um 14:53 schrieb David Bosschaert:
>>
>>> My issue with it is that it brings in 2 dependencies: the SLF4J api
>>> and an SLF4J implementation bundle.
>>> In the context where I want to use the JNDI component there is already
>>> a log subsystem in place, which can be reached through the OSGi
>>> LogService, so adding those 2 SLF4J bundles brings in dependencies
>>> that appear like noise.
>>
>> Got it.
>>
>> In my setup I already use SLF4J (and LogService and Log4J and Commons Logging). Adding yet another logging API just adds another dependency to my setup and adds CPU consumption and learning curve experiences and makes my users wonder.
>
> Well, if Aries has a small log API in its util component that wouldn't
> add any dependencies, because most things in Aries already depend on
> util.
> That component could then delegate to SLF4J, the OSGi LogService or
> whatever bringing only those dependencies in that are actually used.
> So for your use-case you should still be able to use it with SLF4J,
> but for my usecase I don't need to.
Re: [DISCUSS] Logging for Aries modules
Posted by Graham Charters <gc...@gmail.com>.
My worry is that this YALA approach is a solution set in the context
of our current module structure. The aries util module risks becoming
the one module that binds them all and so may become to focus of
refactoring. A consequence would likely be the separation of the
different utility concerns and I think you'd then end up in the same
place. An alternative way to look at this is you could achieve the
same number of modules and capabilities by creating a utility uber
bundle from aries util and slf4j.
Graham.
On 1 February 2012 15:43, David Bosschaert <da...@gmail.com> wrote:
> On 1 February 2012 15:29, Felix Meschberger <fm...@adobe.com> wrote:
>> Hi,
>>
>> Am 01.02.2012 um 14:53 schrieb David Bosschaert:
>>
>>> My issue with it is that it brings in 2 dependencies: the SLF4J api
>>> and an SLF4J implementation bundle.
>>> In the context where I want to use the JNDI component there is already
>>> a log subsystem in place, which can be reached through the OSGi
>>> LogService, so adding those 2 SLF4J bundles brings in dependencies
>>> that appear like noise.
>>
>> Got it.
>>
>> In my setup I already use SLF4J (and LogService and Log4J and Commons Logging). Adding yet another logging API just adds another dependency to my setup and adds CPU consumption and learning curve experiences and makes my users wonder.
>
> Well, if Aries has a small log API in its util component that wouldn't
> add any dependencies, because most things in Aries already depend on
> util.
> That component could then delegate to SLF4J, the OSGi LogService or
> whatever bringing only those dependencies in that are actually used.
> So for your use-case you should still be able to use it with SLF4J,
> but for my usecase I don't need to.
Re: [DISCUSS] Logging for Aries modules
Posted by David Bosschaert <da...@gmail.com>.
On 1 February 2012 15:29, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> Am 01.02.2012 um 14:53 schrieb David Bosschaert:
>
>> My issue with it is that it brings in 2 dependencies: the SLF4J api
>> and an SLF4J implementation bundle.
>> In the context where I want to use the JNDI component there is already
>> a log subsystem in place, which can be reached through the OSGi
>> LogService, so adding those 2 SLF4J bundles brings in dependencies
>> that appear like noise.
>
> Got it.
>
> In my setup I already use SLF4J (and LogService and Log4J and Commons Logging). Adding yet another logging API just adds another dependency to my setup and adds CPU consumption and learning curve experiences and makes my users wonder.
Well, if Aries has a small log API in its util component that wouldn't
add any dependencies, because most things in Aries already depend on
util.
That component could then delegate to SLF4J, the OSGi LogService or
whatever bringing only those dependencies in that are actually used.
So for your use-case you should still be able to use it with SLF4J,
but for my usecase I don't need to.
Re: [DISCUSS] Logging for Aries modules
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 01.02.2012 um 14:53 schrieb David Bosschaert:
> My issue with it is that it brings in 2 dependencies: the SLF4J api
> and an SLF4J implementation bundle.
> In the context where I want to use the JNDI component there is already
> a log subsystem in place, which can be reached through the OSGi
> LogService, so adding those 2 SLF4J bundles brings in dependencies
> that appear like noise.
Got it.
In my setup I already use SLF4J (and LogService and Log4J and Commons Logging). Adding yet another logging API just adds another dependency to my setup and adds CPU consumption and learning curve experiences and makes my users wonder.
Whose argument is more valid ? ;-)
Regards
Felix
Re: [DISCUSS] Logging for Aries modules
Posted by David Bosschaert <da...@gmail.com>.
My issue with it is that it brings in 2 dependencies: the SLF4J api
and an SLF4J implementation bundle.
In the context where I want to use the JNDI component there is already
a log subsystem in place, which can be reached through the OSGi
LogService, so adding those 2 SLF4J bundles brings in dependencies
that appear like noise.
I would like components to have minimal dependencies which makes them
more suitable for reuse in different contexts.
Although I'm not a big fan of yet-another-logging-abstraction-layer,
if we do the logging through an API in the Aries Util component which
then forwards to whatever is configured with it I think it can satisfy
everybody's needs, although I'm open to other suggestions...
On 1 February 2012 13:16, Graham Charters <gc...@gmail.com> wrote:
> Hi David,
>
> Could you clarify the issues with SLF4J? It would seem we could end
> up replacing one logging wrapper API with our own. You mentioned you
> require two bundles that are unnecessary. Is their size an issue? Is
> there some refactoring that could be done in SLF4J to improve the
> situation? Could your own logging sit behind SLF4J or does this cause
> other issues?
>
> Regards, Graham.
>
> On 1 February 2012 12:38, Guillaume Nodet <gn...@gmail.com> wrote:
>> Because the osgi log service has a crappy api which is too limited ?
>>
>> On Wed, Feb 1, 2012 at 12:56, Felix Meschberger <fm...@adobe.com> wrote:
>>> Hi
>>>
>>> Really ? YALA ?
>>>
>>> Why not just settle all Aries on LogService (maybe even through some utility to guard against LogService being away) or SLF4J ?
>>>
>>> Regards
>>> Felix
>>>
>>> Am 01.02.2012 um 12:51 schrieb David Bosschaert:
>>>
>>>> Yes, I'd like to have something that has minimal dependencies, but
>>>> putting it in Aries Util is fine with me as most components depend on
>>>> that anyway.
>>>>
>>>> While working with the LogService I put some code that I found in the
>>>> Aries JMX component that makes working with the OSGi LogService easier
>>>> in Util. You can find it here:
>>>> http://svn.apache.org/repos/asf/aries/trunk/util/util-r42/src/main/java/org/apache/aries/util/log/Logger.java
>>>>
>>>> Maybe we can extend this class to provide a simple API that provides
>>>> all the needed inputs for all uses (including classname-based
>>>> initialization) so it can delegate appropriately.
>>>>
>>>> David
>>>>
>>>> On 1 February 2012 11:05, Graham Charters <gc...@gmail.com> wrote:
>>>>> Guillaume's starter....
>>>>>
>>>>> "Can't we simply do something in aries until that would be shared by
>>>>> all aries modules (since they kinda all depend on it already) ?
>>>>> A very small api that could be configured to either use slf4j, jul or
>>>>> osgi logging ? Using optional imports, it should limit to what's
>>>>> available and default to a good one, falling back to jul if nothing"
>>>>>
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Guillaume Nodet <gn...@gmail.com>
>>>>> Date: 1 February 2012 10:46
>>>>> Subject: Re: Aries JNDI dependencies
>>>>> To: dev@aries.apache.org
>>>>>
>>>>>
>>>>> Can't we simply do something in aries until that would be shared by
>>>>> all aries modules (since they kinda all depend on it already) ?
>>>>> A very small api that could be configured to either use slf4j, jul or
>>>>> osgi logging ? Using optional imports, it should limit to what's
>>>>> available and default to a good one, falling back to jul if nothing
>>>>> else.
>>>>>
>>>>> On Wed, Feb 1, 2012 at 11:26, David Bosschaert
>>>>> <da...@gmail.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> On 1 February 2012 09:58, Graham Charters <gc...@gmail.com> wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> Prior to these changes, Apache Aries had the ability to filter logging
>>>>>>> per class, and this was consistent across all Aries modules.
>>>>>>
>>>>>> Well apparently not because the Aries JMX component used the
>>>>>> LogService already...
>>>>>>
>>>>>>> I don't
>>>>>>> think we should be doing piecemeal infrastructure dependency changes
>>>>>>> like these without a proper consideration.
>>>>>>
>>>>>> Well, you can see at the beginning of this thread (Jan 16) that I'm
>>>>>> asking for opinions re removing to the LogService and that the
>>>>>> responses where positive...
>>>>>>
>>>>>>> Although nobody really wants to have a logging conversation, I don't
>>>>>>> think we can avoid one, and until then, I think we need to go back to
>>>>>>> the consistent approach that, until now, Aries consumers seemed happy
>>>>>>> with.
>>>>>>
>>>>>> ... sigh ... ok we'll have a logging discussion and I'll revert those
>>>>>> changes for the moment.
>>>>>>
>>>>>> @David J: we can explore the capabilities of the log service in that discussion.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> David
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> FuseSource, Integration everywhere
>>>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com
Re: [DISCUSS] Logging for Aries modules
Posted by Graham Charters <gc...@gmail.com>.
Hi David,
Could you clarify the issues with SLF4J? It would seem we could end
up replacing one logging wrapper API with our own. You mentioned you
require two bundles that are unnecessary. Is their size an issue? Is
there some refactoring that could be done in SLF4J to improve the
situation? Could your own logging sit behind SLF4J or does this cause
other issues?
Regards, Graham.
On 1 February 2012 12:38, Guillaume Nodet <gn...@gmail.com> wrote:
> Because the osgi log service has a crappy api which is too limited ?
>
> On Wed, Feb 1, 2012 at 12:56, Felix Meschberger <fm...@adobe.com> wrote:
>> Hi
>>
>> Really ? YALA ?
>>
>> Why not just settle all Aries on LogService (maybe even through some utility to guard against LogService being away) or SLF4J ?
>>
>> Regards
>> Felix
>>
>> Am 01.02.2012 um 12:51 schrieb David Bosschaert:
>>
>>> Yes, I'd like to have something that has minimal dependencies, but
>>> putting it in Aries Util is fine with me as most components depend on
>>> that anyway.
>>>
>>> While working with the LogService I put some code that I found in the
>>> Aries JMX component that makes working with the OSGi LogService easier
>>> in Util. You can find it here:
>>> http://svn.apache.org/repos/asf/aries/trunk/util/util-r42/src/main/java/org/apache/aries/util/log/Logger.java
>>>
>>> Maybe we can extend this class to provide a simple API that provides
>>> all the needed inputs for all uses (including classname-based
>>> initialization) so it can delegate appropriately.
>>>
>>> David
>>>
>>> On 1 February 2012 11:05, Graham Charters <gc...@gmail.com> wrote:
>>>> Guillaume's starter....
>>>>
>>>> "Can't we simply do something in aries until that would be shared by
>>>> all aries modules (since they kinda all depend on it already) ?
>>>> A very small api that could be configured to either use slf4j, jul or
>>>> osgi logging ? Using optional imports, it should limit to what's
>>>> available and default to a good one, falling back to jul if nothing"
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Guillaume Nodet <gn...@gmail.com>
>>>> Date: 1 February 2012 10:46
>>>> Subject: Re: Aries JNDI dependencies
>>>> To: dev@aries.apache.org
>>>>
>>>>
>>>> Can't we simply do something in aries until that would be shared by
>>>> all aries modules (since they kinda all depend on it already) ?
>>>> A very small api that could be configured to either use slf4j, jul or
>>>> osgi logging ? Using optional imports, it should limit to what's
>>>> available and default to a good one, falling back to jul if nothing
>>>> else.
>>>>
>>>> On Wed, Feb 1, 2012 at 11:26, David Bosschaert
>>>> <da...@gmail.com> wrote:
>>>>> Hi all,
>>>>>
>>>>> On 1 February 2012 09:58, Graham Charters <gc...@gmail.com> wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> Prior to these changes, Apache Aries had the ability to filter logging
>>>>>> per class, and this was consistent across all Aries modules.
>>>>>
>>>>> Well apparently not because the Aries JMX component used the
>>>>> LogService already...
>>>>>
>>>>>> I don't
>>>>>> think we should be doing piecemeal infrastructure dependency changes
>>>>>> like these without a proper consideration.
>>>>>
>>>>> Well, you can see at the beginning of this thread (Jan 16) that I'm
>>>>> asking for opinions re removing to the LogService and that the
>>>>> responses where positive...
>>>>>
>>>>>> Although nobody really wants to have a logging conversation, I don't
>>>>>> think we can avoid one, and until then, I think we need to go back to
>>>>>> the consistent approach that, until now, Aries consumers seemed happy
>>>>>> with.
>>>>>
>>>>> ... sigh ... ok we'll have a logging discussion and I'll revert those
>>>>> changes for the moment.
>>>>>
>>>>> @David J: we can explore the capabilities of the log service in that discussion.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> David
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> FuseSource, Integration everywhere
>>>> http://fusesource.com
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com
Re: [DISCUSS] Logging for Aries modules
Posted by Guillaume Nodet <gn...@gmail.com>.
Because the osgi log service has a crappy api which is too limited ?
On Wed, Feb 1, 2012 at 12:56, Felix Meschberger <fm...@adobe.com> wrote:
> Hi
>
> Really ? YALA ?
>
> Why not just settle all Aries on LogService (maybe even through some utility to guard against LogService being away) or SLF4J ?
>
> Regards
> Felix
>
> Am 01.02.2012 um 12:51 schrieb David Bosschaert:
>
>> Yes, I'd like to have something that has minimal dependencies, but
>> putting it in Aries Util is fine with me as most components depend on
>> that anyway.
>>
>> While working with the LogService I put some code that I found in the
>> Aries JMX component that makes working with the OSGi LogService easier
>> in Util. You can find it here:
>> http://svn.apache.org/repos/asf/aries/trunk/util/util-r42/src/main/java/org/apache/aries/util/log/Logger.java
>>
>> Maybe we can extend this class to provide a simple API that provides
>> all the needed inputs for all uses (including classname-based
>> initialization) so it can delegate appropriately.
>>
>> David
>>
>> On 1 February 2012 11:05, Graham Charters <gc...@gmail.com> wrote:
>>> Guillaume's starter....
>>>
>>> "Can't we simply do something in aries until that would be shared by
>>> all aries modules (since they kinda all depend on it already) ?
>>> A very small api that could be configured to either use slf4j, jul or
>>> osgi logging ? Using optional imports, it should limit to what's
>>> available and default to a good one, falling back to jul if nothing"
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Guillaume Nodet <gn...@gmail.com>
>>> Date: 1 February 2012 10:46
>>> Subject: Re: Aries JNDI dependencies
>>> To: dev@aries.apache.org
>>>
>>>
>>> Can't we simply do something in aries until that would be shared by
>>> all aries modules (since they kinda all depend on it already) ?
>>> A very small api that could be configured to either use slf4j, jul or
>>> osgi logging ? Using optional imports, it should limit to what's
>>> available and default to a good one, falling back to jul if nothing
>>> else.
>>>
>>> On Wed, Feb 1, 2012 at 11:26, David Bosschaert
>>> <da...@gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> On 1 February 2012 09:58, Graham Charters <gc...@gmail.com> wrote:
>>>>> Hi David,
>>>>>
>>>>> Prior to these changes, Apache Aries had the ability to filter logging
>>>>> per class, and this was consistent across all Aries modules.
>>>>
>>>> Well apparently not because the Aries JMX component used the
>>>> LogService already...
>>>>
>>>>> I don't
>>>>> think we should be doing piecemeal infrastructure dependency changes
>>>>> like these without a proper consideration.
>>>>
>>>> Well, you can see at the beginning of this thread (Jan 16) that I'm
>>>> asking for opinions re removing to the LogService and that the
>>>> responses where positive...
>>>>
>>>>> Although nobody really wants to have a logging conversation, I don't
>>>>> think we can avoid one, and until then, I think we need to go back to
>>>>> the consistent approach that, until now, Aries consumers seemed happy
>>>>> with.
>>>>
>>>> ... sigh ... ok we'll have a logging discussion and I'll revert those
>>>> changes for the moment.
>>>>
>>>> @David J: we can explore the capabilities of the log service in that discussion.
>>>>
>>>> Best regards,
>>>>
>>>> David
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> FuseSource, Integration everywhere
>>> http://fusesource.com
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: [DISCUSS] Logging for Aries modules
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Really ? YALA ?
Why not just settle all Aries on LogService (maybe even through some utility to guard against LogService being away) or SLF4J ?
Regards
Felix
Am 01.02.2012 um 12:51 schrieb David Bosschaert:
> Yes, I'd like to have something that has minimal dependencies, but
> putting it in Aries Util is fine with me as most components depend on
> that anyway.
>
> While working with the LogService I put some code that I found in the
> Aries JMX component that makes working with the OSGi LogService easier
> in Util. You can find it here:
> http://svn.apache.org/repos/asf/aries/trunk/util/util-r42/src/main/java/org/apache/aries/util/log/Logger.java
>
> Maybe we can extend this class to provide a simple API that provides
> all the needed inputs for all uses (including classname-based
> initialization) so it can delegate appropriately.
>
> David
>
> On 1 February 2012 11:05, Graham Charters <gc...@gmail.com> wrote:
>> Guillaume's starter....
>>
>> "Can't we simply do something in aries until that would be shared by
>> all aries modules (since they kinda all depend on it already) ?
>> A very small api that could be configured to either use slf4j, jul or
>> osgi logging ? Using optional imports, it should limit to what's
>> available and default to a good one, falling back to jul if nothing"
>>
>>
>> ---------- Forwarded message ----------
>> From: Guillaume Nodet <gn...@gmail.com>
>> Date: 1 February 2012 10:46
>> Subject: Re: Aries JNDI dependencies
>> To: dev@aries.apache.org
>>
>>
>> Can't we simply do something in aries until that would be shared by
>> all aries modules (since they kinda all depend on it already) ?
>> A very small api that could be configured to either use slf4j, jul or
>> osgi logging ? Using optional imports, it should limit to what's
>> available and default to a good one, falling back to jul if nothing
>> else.
>>
>> On Wed, Feb 1, 2012 at 11:26, David Bosschaert
>> <da...@gmail.com> wrote:
>>> Hi all,
>>>
>>> On 1 February 2012 09:58, Graham Charters <gc...@gmail.com> wrote:
>>>> Hi David,
>>>>
>>>> Prior to these changes, Apache Aries had the ability to filter logging
>>>> per class, and this was consistent across all Aries modules.
>>>
>>> Well apparently not because the Aries JMX component used the
>>> LogService already...
>>>
>>>> I don't
>>>> think we should be doing piecemeal infrastructure dependency changes
>>>> like these without a proper consideration.
>>>
>>> Well, you can see at the beginning of this thread (Jan 16) that I'm
>>> asking for opinions re removing to the LogService and that the
>>> responses where positive...
>>>
>>>> Although nobody really wants to have a logging conversation, I don't
>>>> think we can avoid one, and until then, I think we need to go back to
>>>> the consistent approach that, until now, Aries consumers seemed happy
>>>> with.
>>>
>>> ... sigh ... ok we'll have a logging discussion and I'll revert those
>>> changes for the moment.
>>>
>>> @David J: we can explore the capabilities of the log service in that discussion.
>>>
>>> Best regards,
>>>
>>> David
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com
Re: [DISCUSS] Logging for Aries modules
Posted by David Bosschaert <da...@gmail.com>.
Yes, I'd like to have something that has minimal dependencies, but
putting it in Aries Util is fine with me as most components depend on
that anyway.
While working with the LogService I put some code that I found in the
Aries JMX component that makes working with the OSGi LogService easier
in Util. You can find it here:
http://svn.apache.org/repos/asf/aries/trunk/util/util-r42/src/main/java/org/apache/aries/util/log/Logger.java
Maybe we can extend this class to provide a simple API that provides
all the needed inputs for all uses (including classname-based
initialization) so it can delegate appropriately.
David
On 1 February 2012 11:05, Graham Charters <gc...@gmail.com> wrote:
> Guillaume's starter....
>
> "Can't we simply do something in aries until that would be shared by
> all aries modules (since they kinda all depend on it already) ?
> A very small api that could be configured to either use slf4j, jul or
> osgi logging ? Using optional imports, it should limit to what's
> available and default to a good one, falling back to jul if nothing"
>
>
> ---------- Forwarded message ----------
> From: Guillaume Nodet <gn...@gmail.com>
> Date: 1 February 2012 10:46
> Subject: Re: Aries JNDI dependencies
> To: dev@aries.apache.org
>
>
> Can't we simply do something in aries until that would be shared by
> all aries modules (since they kinda all depend on it already) ?
> A very small api that could be configured to either use slf4j, jul or
> osgi logging ? Using optional imports, it should limit to what's
> available and default to a good one, falling back to jul if nothing
> else.
>
> On Wed, Feb 1, 2012 at 11:26, David Bosschaert
> <da...@gmail.com> wrote:
>> Hi all,
>>
>> On 1 February 2012 09:58, Graham Charters <gc...@gmail.com> wrote:
>>> Hi David,
>>>
>>> Prior to these changes, Apache Aries had the ability to filter logging
>>> per class, and this was consistent across all Aries modules.
>>
>> Well apparently not because the Aries JMX component used the
>> LogService already...
>>
>>> I don't
>>> think we should be doing piecemeal infrastructure dependency changes
>>> like these without a proper consideration.
>>
>> Well, you can see at the beginning of this thread (Jan 16) that I'm
>> asking for opinions re removing to the LogService and that the
>> responses where positive...
>>
>>> Although nobody really wants to have a logging conversation, I don't
>>> think we can avoid one, and until then, I think we need to go back to
>>> the consistent approach that, until now, Aries consumers seemed happy
>>> with.
>>
>> ... sigh ... ok we'll have a logging discussion and I'll revert those
>> changes for the moment.
>>
>> @David J: we can explore the capabilities of the log service in that discussion.
>>
>> Best regards,
>>
>> David
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com
Re: [DISCUSS] Logging for Aries modules
Posted by Christian Schneider <ch...@die-schneider.net>.
In Camel we recently changed to slf4j. Exactly because it has minimal
dependencies and allows
easy switching of the log impl ... and of course it works great in OSGi.
So why not use slf4j as the only frontend in aries.
CXF has its own little logging abstraction that can then switch between
impls but I think slf4j does that much better.
Christian
Am 01.02.2012 12:05, schrieb Graham Charters:
> Guillaume's starter....
>
> "Can't we simply do something in aries until that would be shared by
> all aries modules (since they kinda all depend on it already) ?
> A very small api that could be configured to either use slf4j, jul or
> osgi logging ? Using optional imports, it should limit to what's
> available and default to a good one, falling back to jul if nothing"
>
>
> ---------- Forwarded message ----------
> From: Guillaume Nodet<gn...@gmail.com>
> Date: 1 February 2012 10:46
> Subject: Re: Aries JNDI dependencies
> To: dev@aries.apache.org
>
>
> Can't we simply do something in aries until that would be shared by
> all aries modules (since they kinda all depend on it already) ?
> A very small api that could be configured to either use slf4j, jul or
> osgi logging ? Using optional imports, it should limit to what's
> available and default to a good one, falling back to jul if nothing
> else.
>
> On Wed, Feb 1, 2012 at 11:26, David Bosschaert
> <da...@gmail.com> wrote:
>> Hi all,
>>
>> On 1 February 2012 09:58, Graham Charters<gc...@gmail.com> wrote:
>>> Hi David,
>>>
>>> Prior to these changes, Apache Aries had the ability to filter logging
>>> per class, and this was consistent across all Aries modules.
>> Well apparently not because the Aries JMX component used the
>> LogService already...
>>
>>> I don't
>>> think we should be doing piecemeal infrastructure dependency changes
>>> like these without a proper consideration.
>> Well, you can see at the beginning of this thread (Jan 16) that I'm
>> asking for opinions re removing to the LogService and that the
>> responses where positive...
>>
>>> Although nobody really wants to have a logging conversation, I don't
>>> think we can avoid one, and until then, I think we need to go back to
>>> the consistent approach that, until now, Aries consumers seemed happy
>>> with.
>> ... sigh ... ok we'll have a logging discussion and I'll revert those
>> changes for the moment.
>>
>> @David J: we can explore the capabilities of the log service in that discussion.
>>
>> Best regards,
>>
>> David
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com