aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Aries JNDI dependencies
Date Tue, 31 Jan 2012 19:33:31 GMT
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