From dev-return-8784-apmail-aries-dev-archive=aries.apache.org@aries.apache.org Mon Jan 16 14:42:12 2012 Return-Path: X-Original-To: apmail-aries-dev-archive@www.apache.org Delivered-To: apmail-aries-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5C735B8A8 for ; Mon, 16 Jan 2012 14:42:12 +0000 (UTC) Received: (qmail 42652 invoked by uid 500); 16 Jan 2012 14:42:12 -0000 Delivered-To: apmail-aries-dev-archive@aries.apache.org Received: (qmail 42603 invoked by uid 500); 16 Jan 2012 14:42:11 -0000 Mailing-List: contact dev-help@aries.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@aries.apache.org Delivered-To: mailing list dev@aries.apache.org Received: (qmail 42595 invoked by uid 99); 16 Jan 2012 14:42:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jan 2012 14:42:11 +0000 X-ASF-Spam-Status: No, hits=0.3 required=5.0 tests=FREEMAIL_REPLY,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of david.bosschaert@gmail.com designates 209.85.210.178 as permitted sender) Received: from [209.85.210.178] (HELO mail-iy0-f178.google.com) (209.85.210.178) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jan 2012 14:42:05 +0000 Received: by iabn5 with SMTP id n5so54170iab.23 for ; Mon, 16 Jan 2012 06:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=+BCq9TqNjOPfkNc2K7Dyo0IWxg7YN1W6FHaekQUwa78=; b=tBr5cdOBSxKZ0IZU/qq5kWNTWhejvm0lunCQy31/MDF/jOXerR73JYAjOnOeQB2Tn8 CjrZFCTBpLLiLU+1CUYnw4QCQLqBoyxAIn72DR27lU6IYPFuxHl6GRbt6LgMROKawFVK G3TRnJi9fNjw96fMguNd68tM52u8qqZOpmFXI= Received: by 10.50.95.169 with SMTP id dl9mr13212648igb.12.1326724903998; Mon, 16 Jan 2012 06:41:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.20.5 with HTTP; Mon, 16 Jan 2012 06:41:22 -0800 (PST) In-Reply-To: References: <11D33392-D820-4B3F-A707-A7DE52A287E4@adobe.com> From: David Bosschaert Date: Mon, 16 Jan 2012 14:41:22 +0000 Message-ID: Subject: Re: Aries JNDI dependencies To: dev@aries.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org 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 wrote: > > If we were going to do this then I'd suggest removing the blueprint: name= space 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 wrote: >> > >> > Hi everyone, >> > >> > There seems to be a misunderstanding here. The JNDI core bundle does n= ot depend on the proxy or blueprint APIs. >> > >> > The bundle David is talking about is the JNDI uber bundle, which by de= finition 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 b= undle is for. The blueprint API is used to implement the blueprint: URL sch= eme, 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 depende= ncies 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 becaus= e 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 co= re 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 = wrote: >> >> > Hi, >> >> > >> >> > Am 16.01.2012 um 10:01 schrieb Guillaume Nodet: >> >> > >> >> >> On Mon, Jan 16, 2012 at 09:57, Felix Meschberger 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 ser= vice? >> >> >>> >> >> >> >> >> >> Or java.util.logging if the capabiilities of the log service are s= een >> >> >> 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 >> > >