commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [DISCOVERY][DISCUSS] additional class for Google Guice integration
Date Tue, 19 Jul 2011 08:02:49 GMT
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.schaible@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 <gudnabrsam@gmail.com> wrote:
>>> On Mon, Jul 11, 2011 at 11:52 AM, Simone Tripodi
>>> <simonetripodi@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 <gudnabrsam@gmail.com>
>>>> wrote:
>>>>> On Mon, Jul 11, 2011 at 10:02 AM, Simone Tripodi
>>>>> <simonetripodi@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 <gudnabrsam@gmail.com>
>>>>>> wrote:
>>>>>>> On Mon, Jul 11, 2011 at 9:28 AM, Simone Tripodi
>>>>>>> <simonetripodi@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-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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message