Nice to have Joerg, every contributions is always welcome :) Feel free to add that feature, I'd like to add the Guice integration as well since it is a common pattern I've been repeating over the time :P Have a nice day, all the best!!! Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Jul 19, 2011 at 1:47 AM, Jörg Schaible <joerg.schai...@gmx.de> wrote: > 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 <gudnabr...@gmail.com> wrote: >>> 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 >>> >>> > > > > --------------------------------------------------------------------- > 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
