You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by David Bosschaert <da...@gmail.com> on 2012/01/16 09:22:51 UTC
Aries JNDI dependencies
Hi all,
I'm looking at the dependencies of the Aries jndi-bundle component,
roughly they are:
the javax JNDI API
the OSGi JNDI API
aries-util
aries-proxy
aries-blueprint
slf4j
I'm wondering about the last two: aries-blueprint and slf4j.
* I *think* there is some blueprint-specific code in aries/jndi but I
wonder can this dependency be made optional?
* The SLF4J dependency always drags in at least 2 slf4j bundles. Would
it not be better to have the logging go through the OSGi log service?
If there is consensus about this I would be happy to help changing this...
Cheers,
David
Re: Aries JNDI dependencies
Posted by Felix Meschberger <fm...@adobe.com>.
Am 16.01.2012 um 10:08 schrieb Guillaume Nodet:
> Well, the point is that it removes a dependency as it's always
> provided by the JRE.
But IMHO the price you pay by far exceeds the gain...
> I'm far from being a fan of JUL myself, the only way I'm using it is
> when redirecting everything to a nicer backend in pax-logging ;-)
Which might not work if you run inside a container you don't control (for example the Apache Sling Web Application (which itself launches an OSGi framework).
Regards
Felix
>
> On Mon, Jan 16, 2012 at 10:05, Felix Meschberger <fm...@adobe.com> wrote:
>> Hi,
>>
>> Am 16.01.2012 um 10:01 schrieb Guillaume Nodet:
>>
>>> On Mon, Jan 16, 2012 at 09:57, Felix Meschberger <fm...@adobe.com> wrote:
>>>>
>>>>> * The SLF4J dependency always drags in at least 2 slf4j bundles. Would
>>>>> it not be better to have the logging go through the OSGi log service?
>>>>
>>>
>>> Or java.util.logging if the capabiilities of the log service are seen
>>> too limited.
>>
>> Oh, please, not ;-)
>>
>> Then rather stick with SLF4J. Thanks.
>>
>> Regards
>> Felix
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com
RE: Aries JNDI dependencies
Posted by Timothy Ward <ti...@apache.org>.
I'm afraid that this is where we disagree about uber-bundles. In my view they are a covenience for pulling in everything, usually for testing. If you are building a server you pull in the bundles for the function you need and dependencies you have.
Currently, as far as the JNDI uber bundle is concerned, proxy and blueprint are not optional. The uber bundle will throw errors if you don't have those packages, and I don't think we should be adding function to the regular bundles to support their non-optional dependencies being absent. IMO it makes the whole thing too complex to maintain and too hard to understand.
I'm not really looking to start a debate about the role of uber bundles here, as a group we've flogged that particular horse far beyond the grave, and I don't think that we'll get much use out of another one. Hopefully I have clarified why the dependencies are there in the current uber bundle. If people want to make changes then so be it.
Regards,
Tim Ward
-------------------
Apache Aries PMC member & Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------
> Date: Mon, 16 Jan 2012 10:50:54 +0100
> Subject: Re: Aries JNDI dependencies
> From: gnodet@gmail.com
> To: dev@aries.apache.org
>
> For uber-bundles, optional parts should have ... optional imports. So
> if blueprint is not a core part, even if very valuable, I'd suggest
> having its imports flagged as optional in the big bundle (if that's
> not already the case).
>
> On Mon, Jan 16, 2012 at 10:36, Timothy Ward <ti...@apache.org> wrote:
> >
> > Hi everyone,
> >
> > There seems to be a misunderstanding here. The JNDI core bundle does not depend on the proxy or blueprint APIs.
> >
> > The bundle David is talking about is the JNDI uber bundle, which by definition depends on everything because it *is* everything. The proxy API is used by the JNDI URL bundle to implement the osgi:service URL scheme. This spec requires damping, which is exactly the sort of thing that the proxy bundle is for. The blueprint API is used to implement the blueprint: URL scheme, which is designed to integrate with blueprint, and so absolutely needs the blueprint API.
> >
> > I would like to ask people not to be so hasty in assuming that dependencies are unnecessary. If you want minimal dependencies then you should be consuming the individual bundles and looking at what they pull in.
> >
> > In this case we could look at avoiding slf4j, although it seems to be popular and other Aries bundles use it. I would be a -1 for removing util, proxy or blueprint dependencies from the JNDI project. The first two because they are a good reuse of existing function, the last because it's part of a really useful feature. If you want to run in an environment that doesn't provide those packages then you can always cut back to the JNDI API and core bundles.
> >
> > Regards
> >
> > Tim Ward
> > -------------------
> > Apache Aries PMC member & Enterprise OSGi advocate
> > Enterprise OSGi in Action (http://www.manning.com/cummins)
> > -------------------
> >
> >
> >> Date: Mon, 16 Jan 2012 10:08:18 +0100
> >> Subject: Re: Aries JNDI dependencies
> >> From: gnodet@gmail.com
> >> To: dev@aries.apache.org
> >>
> >> Well, the point is that it removes a dependency as it's always
> >> provided by the JRE.
> >> I'm far from being a fan of JUL myself, the only way I'm using it is
> >> when redirecting everything to a nicer backend in pax-logging ;-)
> >>
> >> On Mon, Jan 16, 2012 at 10:05, Felix Meschberger <fm...@adobe.com> wrote:
> >> > Hi,
> >> >
> >> > Am 16.01.2012 um 10:01 schrieb Guillaume Nodet:
> >> >
> >> >> On Mon, Jan 16, 2012 at 09:57, Felix Meschberger <fm...@adobe.com> wrote:
> >> >>>
> >> >>>> * The SLF4J dependency always drags in at least 2 slf4j bundles. Would
> >> >>>> it not be better to have the logging go through the OSGi log service?
> >> >>>
> >> >>
> >> >> Or java.util.logging if the capabiilities of the log service are seen
> >> >> too limited.
> >> >
> >> > Oh, please, not ;-)
> >> >
> >> > Then rather stick with SLF4J. Thanks.
> >> >
> >> > Regards
> >> > Felix
> >> >
> >>
> >>
> >>
> >> --
> >> ------------------------
> >> 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: Aries JNDI dependencies
Posted by Guillaume Nodet <gn...@gmail.com>.
For uber-bundles, optional parts should have ... optional imports. So
if blueprint is not a core part, even if very valuable, I'd suggest
having its imports flagged as optional in the big bundle (if that's
not already the case).
On Mon, Jan 16, 2012 at 10:36, Timothy Ward <ti...@apache.org> wrote:
>
> Hi everyone,
>
> There seems to be a misunderstanding here. The JNDI core bundle does not depend on the proxy or blueprint APIs.
>
> The bundle David is talking about is the JNDI uber bundle, which by definition depends on everything because it *is* everything. The proxy API is used by the JNDI URL bundle to implement the osgi:service URL scheme. This spec requires damping, which is exactly the sort of thing that the proxy bundle is for. The blueprint API is used to implement the blueprint: URL scheme, which is designed to integrate with blueprint, and so absolutely needs the blueprint API.
>
> I would like to ask people not to be so hasty in assuming that dependencies are unnecessary. If you want minimal dependencies then you should be consuming the individual bundles and looking at what they pull in.
>
> In this case we could look at avoiding slf4j, although it seems to be popular and other Aries bundles use it. I would be a -1 for removing util, proxy or blueprint dependencies from the JNDI project. The first two because they are a good reuse of existing function, the last because it's part of a really useful feature. If you want to run in an environment that doesn't provide those packages then you can always cut back to the JNDI API and core bundles.
>
> Regards
>
> Tim Ward
> -------------------
> Apache Aries PMC member & Enterprise OSGi advocate
> Enterprise OSGi in Action (http://www.manning.com/cummins)
> -------------------
>
>
>> Date: Mon, 16 Jan 2012 10:08:18 +0100
>> Subject: Re: Aries JNDI dependencies
>> From: gnodet@gmail.com
>> To: dev@aries.apache.org
>>
>> Well, the point is that it removes a dependency as it's always
>> provided by the JRE.
>> I'm far from being a fan of JUL myself, the only way I'm using it is
>> when redirecting everything to a nicer backend in pax-logging ;-)
>>
>> On Mon, Jan 16, 2012 at 10:05, Felix Meschberger <fm...@adobe.com> wrote:
>> > Hi,
>> >
>> > Am 16.01.2012 um 10:01 schrieb Guillaume Nodet:
>> >
>> >> On Mon, Jan 16, 2012 at 09:57, Felix Meschberger <fm...@adobe.com> wrote:
>> >>>
>> >>>> * The SLF4J dependency always drags in at least 2 slf4j bundles. Would
>> >>>> it not be better to have the logging go through the OSGi log service?
>> >>>
>> >>
>> >> Or java.util.logging if the capabiilities of the log service are seen
>> >> too limited.
>> >
>> > Oh, please, not ;-)
>> >
>> > Then rather stick with SLF4J. Thanks.
>> >
>> > Regards
>> > Felix
>> >
>>
>>
>>
>> --
>> ------------------------
>> 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: Aries JNDI dependencies
Posted by David Bosschaert <da...@gmail.com>.
No problem, hopefully we can find a setup for logging going forward
that works for all of us...
I've committed the reverted code in r1239078.
Best regards,
David
On 1 February 2012 11:04, Graham Charters <gc...@gmail.com> wrote:
> Hi David, thank you. I can only apologise for not engaging earlier.
> I, and I think others, didn't appreciate the impact of the changes
> until recently.
>
> Regards, Graham.
>
> On 1 February 2012 10:46, Guillaume Nodet <gn...@gmail.com> wrote:
>> 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: Aries JNDI dependencies
Posted by Graham Charters <gc...@gmail.com>.
Hi David, thank you. I can only apologise for not engaging earlier.
I, and I think others, didn't appreciate the impact of the changes
until recently.
Regards, Graham.
On 1 February 2012 10:46, Guillaume Nodet <gn...@gmail.com> wrote:
> 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: Aries JNDI dependencies
Posted by Guillaume Nodet <gn...@gmail.com>.
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: Aries JNDI dependencies
Posted by David Bosschaert <da...@gmail.com>.
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
Re: Aries JNDI dependencies
Posted by Graham Charters <gc...@gmail.com>.
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 <da...@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 <mn...@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 <da...@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 <mn...@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 <da...@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
>>>>>>
>>>>
>
Re: Aries JNDI dependencies
Posted by David Jencks <da...@yahoo.com>.
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 <mn...@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 <da...@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 <mn...@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 <da...@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
>>>>>
>>>
Re: Aries JNDI dependencies
Posted by David Bosschaert <da...@gmail.com>.
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 <mn...@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 <da...@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 <mn...@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 <da...@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
>> >>
>>
Re: Aries JNDI dependencies
Posted by Mark Nuttall <mn...@apache.org>.
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 <da...@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 <mn...@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 <da...@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
> >>
>
Re: Aries JNDI dependencies
Posted by David Schmitz <Da...@gmx.net>.
Hi David,
I also agree with Mark that it is a loss not having SLF4J anymore.
As slf4j is facade one can make a choice which logging framework to use
behind it.
What are the pros of having your own logging backend?
I don't like handcrafting stuff which already exists with less
functionality.
If have a look at other enterprise projects SLF4J is kind of defacto
standard.
I would very much appreciate to have SLF4J again.
If that is should be no option for you then what about at least
providing an optional dependency to SLF4J with a mechanism to switch
between your log service and slf4j?
Regards
David
> 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<mn...@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<da...@gmail.com>wrote:
>>
>>> On 16 January 2012 15:54, David Bosschaert<da...@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
>>>
Re: Aries JNDI dependencies
Posted by David Bosschaert <da...@gmail.com>.
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 <mn...@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 <da...@gmail.com>wrote:
>
>> On 16 January 2012 15:54, David Bosschaert <da...@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
>>
Re: Aries JNDI dependencies
Posted by Mark Nuttall <mn...@apache.org>.
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 <da...@gmail.com>wrote:
> On 16 January 2012 15:54, David Bosschaert <da...@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
>
Re: Aries JNDI dependencies
Posted by David Bosschaert <da...@gmail.com>.
On 16 January 2012 15:54, David Bosschaert <da...@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
Re: Aries JNDI dependencies
Posted by David Bosschaert <da...@gmail.com>.
On 16 January 2012 14:41, David Bosschaert <da...@gmail.com> wrote:
> Hi Tim,
>
> I'm not sure I completely follow this. Would this not limit the
> reusability of the JNDI uber-bundle? I mean I can equally see use
> cases for an 'uber' bundle where the user *does* want to use the
> blueprint functionality and creating a separate 'uber' bundle for
> every type of use of the functionality certainly isn't right.
>
> I looked at the jndi-url module. This module already declares the
> blueprint dependency as optional and the code in there is written
> defensively to work in cases where blueprint is available and where is
> isn't. Shouldn't we do this for the current 'uber' bundle too?
I've done this now in commit 1232044.
Hope that's ok with everyone. If not I'm happy to revert...
I'll look at changing the SLF4J dependency to an OSGi Log Service
dependency next...
David
Re: Aries JNDI dependencies
Posted by David Bosschaert <da...@gmail.com>.
Hi Tim,
I'm not sure I completely follow this. Would this not limit the
reusability of the JNDI uber-bundle? I mean I can equally see use
cases for an 'uber' bundle where the user *does* want to use the
blueprint functionality and creating a separate 'uber' bundle for
every type of use of the functionality certainly isn't right.
I looked at the jndi-url module. This module already declares the
blueprint dependency as optional and the code in there is written
defensively to work in cases where blueprint is available and where is
isn't. Shouldn't we do this for the current 'uber' bundle too?
Cheers,
David
On 16 January 2012 10:44, Timothy Ward <ti...@apache.org> wrote:
>
> If we were going to do this then I'd suggest removing the blueprint: namespace from the uber bundle, and making it just a "JNDI spec" bundle.
>
>
> Tim Ward
> -------------------
> Apache Aries PMC member & Enterprise OSGi advocate
> Enterprise OSGi in Action (http://www.manning.com/cummins)
> -------------------
>
>
>> From: david.bosschaert@gmail.com
>> Date: Mon, 16 Jan 2012 09:57:16 +0000
>> Subject: Re: Aries JNDI dependencies
>> To: dev@aries.apache.org
>>
>> Hi Tim,
>>
>> I think we need to find the balance between 'super modular' and 'user
>> friendly'. To me, the jndi-uber bundle seems like the right level of
>> modularity for many cases. It provides the JNDI functionality in a
>> single bundle with a number of dependencies.
>>
>> I can understand the need for aries-util and aries-proxy (the
>> OSGi/JNDI spec specifies that references need to be proxied). On the
>> aries-blueprint dependency, my suggestion is to make it optional so
>> that the aries jndi-bundle (the uber bundle) can resolve without
>> aries-blueprint being there. It should function as long as you don't
>> use the blueprint-specific features...
>>
>> Cheers,
>>
>> David
>>
>> On 16 January 2012 09:36, Timothy Ward <ti...@apache.org> wrote:
>> >
>> > Hi everyone,
>> >
>> > There seems to be a misunderstanding here. The JNDI core bundle does not depend on the proxy or blueprint APIs.
>> >
>> > The bundle David is talking about is the JNDI uber bundle, which by definition depends on everything because it *is* everything. The proxy API is used by the JNDI URL bundle to implement the osgi:service URL scheme. This spec requires damping, which is exactly the sort of thing that the proxy bundle is for. The blueprint API is used to implement the blueprint: URL scheme, which is designed to integrate with blueprint, and so absolutely needs the blueprint API.
>> >
>> > I would like to ask people not to be so hasty in assuming that dependencies are unnecessary. If you want minimal dependencies then you should be consuming the individual bundles and looking at what they pull in.
>> >
>> > In this case we could look at avoiding slf4j, although it seems to be popular and other Aries bundles use it. I would be a -1 for removing util, proxy or blueprint dependencies from the JNDI project. The first two because they are a good reuse of existing function, the last because it's part of a really useful feature. If you want to run in an environment that doesn't provide those packages then you can always cut back to the JNDI API and core bundles.
>> >
>> > Regards
>> >
>> > Tim Ward
>> > -------------------
>> > Apache Aries PMC member & Enterprise OSGi advocate
>> > Enterprise OSGi in Action (http://www.manning.com/cummins)
>> > -------------------
>> >
>> >
>> >> Date: Mon, 16 Jan 2012 10:08:18 +0100
>> >> Subject: Re: Aries JNDI dependencies
>> >> From: gnodet@gmail.com
>> >> To: dev@aries.apache.org
>> >>
>> >> Well, the point is that it removes a dependency as it's always
>> >> provided by the JRE.
>> >> I'm far from being a fan of JUL myself, the only way I'm using it is
>> >> when redirecting everything to a nicer backend in pax-logging ;-)
>> >>
>> >> On Mon, Jan 16, 2012 at 10:05, Felix Meschberger <fm...@adobe.com> wrote:
>> >> > Hi,
>> >> >
>> >> > Am 16.01.2012 um 10:01 schrieb Guillaume Nodet:
>> >> >
>> >> >> On Mon, Jan 16, 2012 at 09:57, Felix Meschberger <fm...@adobe.com> wrote:
>> >> >>>
>> >> >>>> * The SLF4J dependency always drags in at least 2 slf4j bundles. Would
>> >> >>>> it not be better to have the logging go through the OSGi log service?
>> >> >>>
>> >> >>
>> >> >> Or java.util.logging if the capabiilities of the log service are seen
>> >> >> too limited.
>> >> >
>> >> > Oh, please, not ;-)
>> >> >
>> >> > Then rather stick with SLF4J. Thanks.
>> >> >
>> >> > Regards
>> >> > Felix
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> ------------------------
>> >> Guillaume Nodet
>> >> ------------------------
>> >> Blog: http://gnodet.blogspot.com/
>> >> ------------------------
>> >> FuseSource, Integration everywhere
>> >> http://fusesource.com
>> >
>
RE: Aries JNDI dependencies
Posted by Timothy Ward <ti...@apache.org>.
If we were going to do this then I'd suggest removing the blueprint: namespace from the uber bundle, and making it just a "JNDI spec" bundle.
Tim Ward
-------------------
Apache Aries PMC member & Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------
> From: david.bosschaert@gmail.com
> Date: Mon, 16 Jan 2012 09:57:16 +0000
> Subject: Re: Aries JNDI dependencies
> To: dev@aries.apache.org
>
> Hi Tim,
>
> I think we need to find the balance between 'super modular' and 'user
> friendly'. To me, the jndi-uber bundle seems like the right level of
> modularity for many cases. It provides the JNDI functionality in a
> single bundle with a number of dependencies.
>
> I can understand the need for aries-util and aries-proxy (the
> OSGi/JNDI spec specifies that references need to be proxied). On the
> aries-blueprint dependency, my suggestion is to make it optional so
> that the aries jndi-bundle (the uber bundle) can resolve without
> aries-blueprint being there. It should function as long as you don't
> use the blueprint-specific features...
>
> Cheers,
>
> David
>
> On 16 January 2012 09:36, Timothy Ward <ti...@apache.org> wrote:
> >
> > Hi everyone,
> >
> > There seems to be a misunderstanding here. The JNDI core bundle does not depend on the proxy or blueprint APIs.
> >
> > The bundle David is talking about is the JNDI uber bundle, which by definition depends on everything because it *is* everything. The proxy API is used by the JNDI URL bundle to implement the osgi:service URL scheme. This spec requires damping, which is exactly the sort of thing that the proxy bundle is for. The blueprint API is used to implement the blueprint: URL scheme, which is designed to integrate with blueprint, and so absolutely needs the blueprint API.
> >
> > I would like to ask people not to be so hasty in assuming that dependencies are unnecessary. If you want minimal dependencies then you should be consuming the individual bundles and looking at what they pull in.
> >
> > In this case we could look at avoiding slf4j, although it seems to be popular and other Aries bundles use it. I would be a -1 for removing util, proxy or blueprint dependencies from the JNDI project. The first two because they are a good reuse of existing function, the last because it's part of a really useful feature. If you want to run in an environment that doesn't provide those packages then you can always cut back to the JNDI API and core bundles.
> >
> > Regards
> >
> > Tim Ward
> > -------------------
> > Apache Aries PMC member & Enterprise OSGi advocate
> > Enterprise OSGi in Action (http://www.manning.com/cummins)
> > -------------------
> >
> >
> >> Date: Mon, 16 Jan 2012 10:08:18 +0100
> >> Subject: Re: Aries JNDI dependencies
> >> From: gnodet@gmail.com
> >> To: dev@aries.apache.org
> >>
> >> Well, the point is that it removes a dependency as it's always
> >> provided by the JRE.
> >> I'm far from being a fan of JUL myself, the only way I'm using it is
> >> when redirecting everything to a nicer backend in pax-logging ;-)
> >>
> >> On Mon, Jan 16, 2012 at 10:05, Felix Meschberger <fm...@adobe.com> wrote:
> >> > Hi,
> >> >
> >> > Am 16.01.2012 um 10:01 schrieb Guillaume Nodet:
> >> >
> >> >> On Mon, Jan 16, 2012 at 09:57, Felix Meschberger <fm...@adobe.com> wrote:
> >> >>>
> >> >>>> * The SLF4J dependency always drags in at least 2 slf4j bundles. Would
> >> >>>> it not be better to have the logging go through the OSGi log service?
> >> >>>
> >> >>
> >> >> Or java.util.logging if the capabiilities of the log service are seen
> >> >> too limited.
> >> >
> >> > Oh, please, not ;-)
> >> >
> >> > Then rather stick with SLF4J. Thanks.
> >> >
> >> > Regards
> >> > Felix
> >> >
> >>
> >>
> >>
> >> --
> >> ------------------------
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> FuseSource, Integration everywhere
> >> http://fusesource.com
> >
Re: Aries JNDI dependencies
Posted by David Bosschaert <da...@gmail.com>.
Hi Tim,
I think we need to find the balance between 'super modular' and 'user
friendly'. To me, the jndi-uber bundle seems like the right level of
modularity for many cases. It provides the JNDI functionality in a
single bundle with a number of dependencies.
I can understand the need for aries-util and aries-proxy (the
OSGi/JNDI spec specifies that references need to be proxied). On the
aries-blueprint dependency, my suggestion is to make it optional so
that the aries jndi-bundle (the uber bundle) can resolve without
aries-blueprint being there. It should function as long as you don't
use the blueprint-specific features...
Cheers,
David
On 16 January 2012 09:36, Timothy Ward <ti...@apache.org> wrote:
>
> Hi everyone,
>
> There seems to be a misunderstanding here. The JNDI core bundle does not depend on the proxy or blueprint APIs.
>
> The bundle David is talking about is the JNDI uber bundle, which by definition depends on everything because it *is* everything. The proxy API is used by the JNDI URL bundle to implement the osgi:service URL scheme. This spec requires damping, which is exactly the sort of thing that the proxy bundle is for. The blueprint API is used to implement the blueprint: URL scheme, which is designed to integrate with blueprint, and so absolutely needs the blueprint API.
>
> I would like to ask people not to be so hasty in assuming that dependencies are unnecessary. If you want minimal dependencies then you should be consuming the individual bundles and looking at what they pull in.
>
> In this case we could look at avoiding slf4j, although it seems to be popular and other Aries bundles use it. I would be a -1 for removing util, proxy or blueprint dependencies from the JNDI project. The first two because they are a good reuse of existing function, the last because it's part of a really useful feature. If you want to run in an environment that doesn't provide those packages then you can always cut back to the JNDI API and core bundles.
>
> Regards
>
> Tim Ward
> -------------------
> Apache Aries PMC member & Enterprise OSGi advocate
> Enterprise OSGi in Action (http://www.manning.com/cummins)
> -------------------
>
>
>> Date: Mon, 16 Jan 2012 10:08:18 +0100
>> Subject: Re: Aries JNDI dependencies
>> From: gnodet@gmail.com
>> To: dev@aries.apache.org
>>
>> Well, the point is that it removes a dependency as it's always
>> provided by the JRE.
>> I'm far from being a fan of JUL myself, the only way I'm using it is
>> when redirecting everything to a nicer backend in pax-logging ;-)
>>
>> On Mon, Jan 16, 2012 at 10:05, Felix Meschberger <fm...@adobe.com> wrote:
>> > Hi,
>> >
>> > Am 16.01.2012 um 10:01 schrieb Guillaume Nodet:
>> >
>> >> On Mon, Jan 16, 2012 at 09:57, Felix Meschberger <fm...@adobe.com> wrote:
>> >>>
>> >>>> * The SLF4J dependency always drags in at least 2 slf4j bundles. Would
>> >>>> it not be better to have the logging go through the OSGi log service?
>> >>>
>> >>
>> >> Or java.util.logging if the capabiilities of the log service are seen
>> >> too limited.
>> >
>> > Oh, please, not ;-)
>> >
>> > Then rather stick with SLF4J. Thanks.
>> >
>> > Regards
>> > Felix
>> >
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com
>
RE: Aries JNDI dependencies
Posted by Timothy Ward <ti...@apache.org>.
Hi everyone,
There seems to be a misunderstanding here. The JNDI core bundle does not depend on the proxy or blueprint APIs.
The bundle David is talking about is the JNDI uber bundle, which by definition depends on everything because it *is* everything. The proxy API is used by the JNDI URL bundle to implement the osgi:service URL scheme. This spec requires damping, which is exactly the sort of thing that the proxy bundle is for. The blueprint API is used to implement the blueprint: URL scheme, which is designed to integrate with blueprint, and so absolutely needs the blueprint API.
I would like to ask people not to be so hasty in assuming that dependencies are unnecessary. If you want minimal dependencies then you should be consuming the individual bundles and looking at what they pull in.
In this case we could look at avoiding slf4j, although it seems to be popular and other Aries bundles use it. I would be a -1 for removing util, proxy or blueprint dependencies from the JNDI project. The first two because they are a good reuse of existing function, the last because it's part of a really useful feature. If you want to run in an environment that doesn't provide those packages then you can always cut back to the JNDI API and core bundles.
Regards
Tim Ward
-------------------
Apache Aries PMC member & Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------
> Date: Mon, 16 Jan 2012 10:08:18 +0100
> Subject: Re: Aries JNDI dependencies
> From: gnodet@gmail.com
> To: dev@aries.apache.org
>
> Well, the point is that it removes a dependency as it's always
> provided by the JRE.
> I'm far from being a fan of JUL myself, the only way I'm using it is
> when redirecting everything to a nicer backend in pax-logging ;-)
>
> On Mon, Jan 16, 2012 at 10:05, Felix Meschberger <fm...@adobe.com> wrote:
> > Hi,
> >
> > Am 16.01.2012 um 10:01 schrieb Guillaume Nodet:
> >
> >> On Mon, Jan 16, 2012 at 09:57, Felix Meschberger <fm...@adobe.com> wrote:
> >>>
> >>>> * The SLF4J dependency always drags in at least 2 slf4j bundles. Would
> >>>> it not be better to have the logging go through the OSGi log service?
> >>>
> >>
> >> Or java.util.logging if the capabiilities of the log service are seen
> >> too limited.
> >
> > Oh, please, not ;-)
> >
> > Then rather stick with SLF4J. Thanks.
> >
> > Regards
> > Felix
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com
Re: Aries JNDI dependencies
Posted by Guillaume Nodet <gn...@gmail.com>.
Well, the point is that it removes a dependency as it's always
provided by the JRE.
I'm far from being a fan of JUL myself, the only way I'm using it is
when redirecting everything to a nicer backend in pax-logging ;-)
On Mon, Jan 16, 2012 at 10:05, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> Am 16.01.2012 um 10:01 schrieb Guillaume Nodet:
>
>> On Mon, Jan 16, 2012 at 09:57, Felix Meschberger <fm...@adobe.com> wrote:
>>>
>>>> * The SLF4J dependency always drags in at least 2 slf4j bundles. Would
>>>> it not be better to have the logging go through the OSGi log service?
>>>
>>
>> Or java.util.logging if the capabiilities of the log service are seen
>> too limited.
>
> Oh, please, not ;-)
>
> Then rather stick with SLF4J. Thanks.
>
> Regards
> Felix
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: Aries JNDI dependencies
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 16.01.2012 um 10:01 schrieb Guillaume Nodet:
> On Mon, Jan 16, 2012 at 09:57, Felix Meschberger <fm...@adobe.com> wrote:
>>
>>> * The SLF4J dependency always drags in at least 2 slf4j bundles. Would
>>> it not be better to have the logging go through the OSGi log service?
>>
>
> Or java.util.logging if the capabiilities of the log service are seen
> too limited.
Oh, please, not ;-)
Then rather stick with SLF4J. Thanks.
Regards
Felix
Re: Aries JNDI dependencies
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Jan 16, 2012 at 09:57, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> Am 16.01.2012 um 09:22 schrieb David Bosschaert:
>
>> Hi all,
>>
>> I'm looking at the dependencies of the Aries jndi-bundle component,
>> roughly they are:
>>
>> the javax JNDI API
>> the OSGi JNDI API
>> aries-util
>> aries-proxy
>> aries-blueprint
>> slf4j
>>
>> I'm wondering about the last two: aries-blueprint and slf4j.
>
> I'd even question aries-proxy. Is this for some Reference stuff ?
>
>>
>> * I *think* there is some blueprint-specific code in aries/jndi but I
>> wonder can this dependency be made optional?
>
> Or even moved out of the core bundle ?
>
>> * The SLF4J dependency always drags in at least 2 slf4j bundles. Would
>> it not be better to have the logging go through the OSGi log service?
>
Or java.util.logging if the capabiilities of the log service are seen
too limited.
> +1
>
> Regards
> Felix
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: Aries JNDI dependencies
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 16.01.2012 um 09:22 schrieb David Bosschaert:
> Hi all,
>
> I'm looking at the dependencies of the Aries jndi-bundle component,
> roughly they are:
>
> the javax JNDI API
> the OSGi JNDI API
> aries-util
> aries-proxy
> aries-blueprint
> slf4j
>
> I'm wondering about the last two: aries-blueprint and slf4j.
I'd even question aries-proxy. Is this for some Reference stuff ?
>
> * I *think* there is some blueprint-specific code in aries/jndi but I
> wonder can this dependency be made optional?
Or even moved out of the core bundle ?
> * The SLF4J dependency always drags in at least 2 slf4j bundles. Would
> it not be better to have the logging go through the OSGi log service?
+1
Regards
Felix