Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-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 D0DF77713 for ; Mon, 18 Jul 2011 23:48:03 +0000 (UTC) Received: (qmail 88825 invoked by uid 500); 18 Jul 2011 23:48:03 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 88641 invoked by uid 500); 18 Jul 2011 23:48:02 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 88632 invoked by uid 99); 18 Jul 2011 23:48:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Jul 2011 23:48:02 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jak-commons-dev@m.gmane.org designates 80.91.229.12 as permitted sender) Received: from [80.91.229.12] (HELO lo.gmane.org) (80.91.229.12) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Jul 2011 23:47:53 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QixXA-0005gs-UY for dev@commons.apache.org; Tue, 19 Jul 2011 01:47:32 +0200 Received: from hsi-kbw-046-005-048-163.hsi8.kabel-badenwuerttemberg.de ([46.5.48.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jul 2011 01:47:32 +0200 Received: from joerg.schaible by hsi-kbw-046-005-048-163.hsi8.kabel-badenwuerttemberg.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jul 2011 01:47:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: dev@commons.apache.org To: dev@commons.apache.org From: =?UTF-8?B?SsO2cmc=?= Schaible Subject: Re: [DISCOVERY][DISCUSS] additional class for Google Guice integration Followup-To: gmane.comp.jakarta.commons.devel Date: Tue, 19 Jul 2011 01:47:21 +0200 Lines: 142 Message-ID: References: Reply-To: joerg.schaible@gmx.de Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: hsi-kbw-046-005-048-163.hsi8.kabel-badenwuerttemberg.de Mail-Copies-To: nobody User-Agent: KNode/4.4.11 X-Virus-Checked: Checked by ClamAV on apache.org Simone Tripodi wrote: > Hi all guys, > looks there are not objections on adding 3rd parties integration > modules on [Discovery], I'll take care on it as soon as I receive my > new laptop with working development environment :) Is it all about to get a Java SPI that supports arguments for the ctor? I can provide this if required. - Jörg > Thanks a lot for your feedbacks Matt!!! > Have a nice day, all the best, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Mon, Jul 11, 2011 at 7:01 PM, Matt Benson wrote: >> On Mon, Jul 11, 2011 at 11:52 AM, Simone Tripodi >> wrote: >>> Hi Matt!!! >>> I still continue preferring Discovery over Java6 ServiceLoader just >>> for a small reason: it allows iterating over Classes instead of >>> Instances, that makes easier integration with DI/IoC frameworks. >>> Indeed, with the Guice module, like shown in the link in my first >>> email, I let instantiating the Service by Guice - that implies that >>> Service class can have a constructor that accepts arguments (the >>> dependencies) >>> Anyway that's just my PoV, I'm sure there are other aspects I didn't >>> take in consideration. >>> I'm open to any feedback/suggestion, what's your PoV about it? >> >> I don't so much have a point of view with regard to [discovery], never >> having really needed it. That's why I asked. ;) >> >> Matt >> >>> Have a nice day, all the best! >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Mon, Jul 11, 2011 at 5:25 PM, Matt Benson >>> wrote: >>>> On Mon, Jul 11, 2011 at 10:02 AM, Simone Tripodi >>>> wrote: >>>>> Hi Matt, >>>>> it sounds indeed reasonable, thanks for your feedbacks! >>>>> Moreover what is you are suggesting is what we did in BVAL... >>>> >>>> Yes, exactly like bval... :) >>>> >>>>> Do you see any risk on splitting current Discovery project structure >>>>> in multi module? >>>> >>>> I honestly am not that familiar with [discovery] per se. I have >>>> wondered if it is still relevant in a Java 6 environment with >>>> java.util.ServiceLoader making convenient the exploration of service >>>> impls provided by META-INF/services/* resources. I realize >>>> [discovery] uses other mechanisms as well, but do they continue to be >>>> necessary? >>>> >>>> Matt >>>> >>>>> Many thanks in advance, have a nice day! >>>>> Simo >>>>> >>>>> http://people.apache.org/~simonetripodi/ >>>>> http://www.99soft.org/ >>>>> >>>>> >>>>> >>>>> On Mon, Jul 11, 2011 at 4:54 PM, Matt Benson >>>>> wrote: >>>>>> On Mon, Jul 11, 2011 at 9:28 AM, Simone Tripodi >>>>>> wrote: >>>>>>> Hi all guys, >>>>>>> lately in my projects I've been frequently repeating the pattern >>>>>>> described in [1], so, to avoid useless c'n'p I would propose to >>>>>>> provide an already compiled module that makes easier the Google >>>>>>> Guice integration with Discovery. >>>>>>> Google Guice could be provided as a 'optional' or 'provided' >>>>>>> dependency, since it wouldn't be part of the core functionalities. >>>>>>> WDYT? Do you see any problem if I add such class? >>>>>>> Thanks in advance for any feedback, have a nice day! >>>>>>> Simo >>>>>>> >>>>>> >>>>>> FWIW, my personal preference for integration with non-ASF code would >>>>>> be the admittedly cumbersome multi-module project approach. >>>>>> >>>>>> Matt >>>>>> >>>>>>> [1] http://s.apache.org/Nai >>>>>>> >>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>> http://www.99soft.org/ >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>> For additional commands, e-mail: dev-help@commons.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>> For additional commands, e-mail: dev-help@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >> For additional commands, e-mail: dev-help@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org