On Mon, Jul 11, 2011 at 11:52 AM, Simone Tripodi <simonetrip...@apache.org> 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 <gudnabr...@gmail.com> wrote: >> On Mon, Jul 11, 2011 at 10:02 AM, Simone Tripodi >> <simonetrip...@apache.org> 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 <gudnabr...@gmail.com> wrote: >>>> On Mon, Jul 11, 2011 at 9:28 AM, Simone Tripodi >>>> <simonetrip...@apache.org> 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-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
