commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [DISCOVERY][DISCUSS] additional class for Google Guice integration
Date Mon, 18 Jul 2011 23:47:21 GMT
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


Mime
View raw message