aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <timothyjw...@apache.org>
Subject RE: Aries JNDI dependencies
Date Mon, 16 Jan 2012 10:44:08 GMT

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 <timothyjward@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 <fmeschbe@adobe.com>
wrote:
> >> > Hi,
> >> >
> >> > Am 16.01.2012 um 10:01 schrieb Guillaume Nodet:
> >> >
> >> >> On Mon, Jan 16, 2012 at 09:57, Felix Meschberger <fmeschbe@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
> >
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message