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 Mon, 18 Jul 2011 12:22:26 GMT
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 :)
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


Mime
View raw message