aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Charters <gchart...@gmail.com>
Subject Re: Aries JNDI dependencies
Date Wed, 01 Feb 2012 09:58:36 GMT
Hi David,

Prior to these changes, Apache Aries had the ability to filter logging
per class, and this was consistent across all Aries modules.  I don't
think we should be doing piecemeal infrastructure dependency changes
like these without a proper consideration.  As a community we agreed
to SLF4J and I don't think the wider implications of these JNDI
changes were appreciated.  Yes, we care about our product, as do you,
and any other contributors to Apache Aries who then consume the
modules, but these changes have essentially deviated from the Aries
standard logging and broken/inconvenienced a number of consumers
(judging by the comments on this thread).

I'd like to think I'm not taking a selfish and inconsistent view here
as there are a number of precedents for reverting changes that have
broken existing consumers.  Dan and Guillaume have both done this for
Karaf and CXF, and the contributors whose changes were undone accepted
their need.

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.  Could I ask that you revert your changes, as you originally
offered, and maybe make them in a branch, and then start a discussion
on how to evolve Aries logging to support your new requirement without
regressing existing consumers.

Many thanks.

Graham.

On 31 January 2012 19:33, David Jencks <david_jencks@yahoo.com> wrote:
> Hi David B
>
> another David joins the thread :-)
>
> I'm not that familiar with the osgi log service.
>
> Your discussion below missed the IMO important part about logging, how you get the logger
and what information is embedded in that logger.  The slf4j api is generally used to get
a logger for a given class and the logging backend is usually set up to include that information
in the logged message.  This makes it very easy to trace the message back to the class that
logged the information.
>
> The jndi logging you show doesn't include any such contextual information about the source
of the logging.  The osgi log service lets you supply a ServiceReference to provide such
information, but the jndi code isn't doing that.   The 4.2 compendium 101.1.1 says you can
also specify a Bundle as context info, but it's not obvious to me how.  Maybe the log service
is a service factory and the instance you get includes the bundle the log service instance
is supplied for?
>
> Everyone using slf4j is used to filtering their log messages on class name and using
this to trace the message back to the source.  If we want to use something else such as the
osgi log service I think we need a clear path to doing something equivalent with the osgi
provided context information.
>
> BTW pax logging provides a osgi log service implementation backed with (I think) log4j
or logback, but I don't know how the log4j "Category" is related to the osgi context info.
>
> thanks
> david jencks
>
>
> On Jan 31, 2012, at 11:07 AM, David Bosschaert wrote:
>
>> Hi Mark, David S,
>>
>> I generally try to stay out of logging conversations because there
>> generally seems to be a large amount of opinions around this.
>> Personally the main thing I care about in this case is to minimize the
>> amount of dependencies.
>> It's true that SLF4J has a pluggable backend for the logging messages,
>> but the OSGi LogService [1] is also fully customizable wrt to the
>> backend and as an OSGi specification it seems highly suitable for use
>> in Aries. In fact I noticed that the Aries JMX component was already
>> using it before... (David S I certainly don't suggest writing my own
>> logging system!)
>>
>> As the LogService interfaces are provided as part of most OSGi
>> frameworks it doesn't create an extra mandatory dependency.
>>
>> But let's look at the actual changes made here (as relating to the
>> JNDI) component [2].
>> The dependencies on SLF4J were actually quite small. Only in the 3
>> activators, where most of the logging messages are warnings and one of
>> them is an actual error condition. Here's an example of such a
>> warning::
>>             NamingManager.setInitialContextFactoryBuilder(builder);
>>             icfBuilder = builder;
>>         } catch (NamingException e) {
>> -            LOGGER.info(Utils.MESSAGES.getMessage("unable.to.set.static.ICFB"),
>> e);
>> +            logger.log(LogService.LOG_INFO,
>> Utils.MESSAGES.getMessage("unable.to.set.static.ICFB"),
>>
>> rather than bluntly reverting the commit, maybe there is some way we
>> can come to a solution that would work for both of us? Would you have
>> an alternate suggestion?
>> You mention as a problem that the OSGi LogService does not have a
>> pluggable back-end. This is clearly untrue. You can plug in any
>> back-end you like as it's only an API. Have you looked into this?
>>
>> Best regards,
>>
>> David
>>
>> [1] Chapter 101 in the OSGi 4.2 compendium spec
>> http://www.osgi.org/Download/Release4V42
>> [2] http://mail-archives.apache.org/mod_mbox/aries-commits/201201.mbox/%3C20120117113557.8231E23889E1%40eris.apache.org%3E
>>
>> On 31 January 2012 14:18, Mark Nuttall <mnuttall@apache.org> wrote:
>>> Hi David,
>>>
>>>> Hmmm, I have to say that I don't really like message like: 'please
>>>> revert your changes because our product does x, y or z'.
>>>
>>> While that is not an unusual conversation on this list, I was in this case
>>> responding to your note in this thread of Jan 16th in which you wrote,
>>>
>>>>> I've done this now in commit 1232044. Hope that's ok with everyone. If
>>> not I'm happy to revert...
>>>
>>> I know that you wrote this two weeks ago, but I was hopeful that your offer
>>> was still valid. I know that we didn't spot this at the time: we've had to
>>> attempt to reconsume your changes in order to appreciate their impact. I
>>> asked you to revert your changes because I believed that you had made an
>>> offer to do so.
>>>
>>>> * SLF4J brings in dependencies that not everybody may want. In our
>>>> use-case in JBoss the SLF4J dep brings in at least 2 additional
>>>> bundles, which is unnecessary as we already have our own logging
>>>> system.
>>>
>>> I understand that SLF4J brings in dependencies that you do not want, but it
>>> also brings in the benefit of permitting us each to choose the logging
>>> implementation behind it. Again, I may be wrong, but that flexibility seems
>>> to have been removed from consumers of the JNDI module.
>>>
>>>> * SLF4J may have been decided on in Feb 2010, but a vibrant project
>>>> must show its agility to work in a number a settings. It's a good
>>>> thing that Aries is now used in more and more settings, but this
>>>> brings with it the notion of being able to accommodate.
>>>
>>> If you want to reopen the discussion of how logging is done across Apache
>>> Aries, then by all means let's have that discussion. The problem that we
>>> have now is that anyone consuming more than just JNDI from Aries must deal
>>> with two different logging technologies: the OSGi LoggingService for JNDI,
>>> and SLF4J for everything else. We've previously agreed on this list that it
>>> is desirable and appropriate for there to be one common logging approach
>>> across all the Aries modules.
>>>
>>> Again, I would still like to take you up on your offer on Jan 16th. Please,
>>> can I ask you to restore SLF4J logging to JNDI while we reopen the
>>> discussion of how logging is done across Aries? Thank you very much in
>>> advance.
>>>
>>> Regards,
>>> Mark
>>>
>>>
>>> On 31 January 2012 12:19, David Bosschaert <david.bosschaert@gmail.com>wrote:
>>>
>>>> Hi Mark,
>>>>
>>>> Hmmm, I have to say that I don't really like message like: 'please
>>>> revert your changes because our product does x, y or z'. Apache Aries
>>>> is an opensource community that provides components that are used in
>>>> more than one product, not only yours.
>>>>
>>>> I would prefer a more constructive approach where we can weigh the
>>>> pros and cons of the various approaches.
>>>>
>>>> * SLF4J brings in dependencies that not everybody may want. In our
>>>> use-case in JBoss the SLF4J dep brings in at least 2 additional
>>>> bundles, which is unnecessary as we already have our own logging
>>>> system.
>>>> * SLF4J may have been decided on in Feb 2010, but a vibrant project
>>>> must show its agility to work in a number a settings. It's a good
>>>> thing that Aries is now used in more and more settings, but this
>>>> brings with it the notion of being able to accommodate.
>>>>
>>>> So... I'm not entirely sure what the actual problem is with the
>>>> LogService, you mention:
>>>> * logging against specific classes
>>>> * other behavioural changes (what are they?)
>>>>
>>>> Instead of simply going back to SLF4J, I would like to have a discussion
>>>> about:
>>>> * possible alternatives, can we maybe change how the LogService is
>>>> used to accommodate your needs?
>>>> * or we could look at other logging alternatives, java.util.logging
>>>> comes to mind, since that can be configured to go to anything you like
>>>> as well and has the advantage over SLF4J in that the dependencies are
>>>> part of the JDK...
>>>>
>>>> Best regards,
>>>>
>>>> David
>>>>
>>>>
>>>> On 31 January 2012 09:56, Mark Nuttall <mnuttall@apache.org> wrote:
>>>>> Hi David,
>>>>> We've started running into what are for us serious consequences of your
>>>>> recent changes to JNDI. I'm sorry that it's taken us a few weeks to
>>>> notice
>>>>> this. When JNDI logged via the SLF4J API, we had a pluggable logging
API
>>>>> that allowed us to log to our product's standard infrastructure. In
>>>>> removing SLF4J, your changes appear to have bound us
>>>>> to org.osgi.service.log.LogService, which we do not want, removed
>>>> important
>>>>> logging capabilities, such as the ability to log against specific
>>>> classes,
>>>>> and made other unwanted bahevioural changes. This is a problematic
>>>>> regression for us. Please can you revert JNDI to logging via the SLF4J
>>>> API?
>>>>> SLF4J has been the Apache Aries standard for logging since the "[DISCUSS]
>>>>> Logging framework" thread in February 2010. Thank you very much in
>>>> advance.
>>>>>
>>>>> Regards,
>>>>> Mark
>>>>>
>>>>>
>>>>> On 17 January 2012 11:38, David Bosschaert <david.bosschaert@gmail.com
>>>>> wrote:
>>>>>
>>>>>> On 16 January 2012 15:54, David Bosschaert <david.bosschaert@gmail.com>
>>>>>> wrote:
>>>>>>> I'll look at changing the SLF4J dependency to an OSGi Log Service
>>>>>>> dependency next...
>>>>>>
>>>>>> That's done now too: see revision 1232390
>>>>>> Hope this is ok with everyone...
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> David
>>>>>>
>>>>
>

Mime
View raw message