« Return to Thread: DS or iPOJO or peaberry
Re: DS or iPOJO or peaberry
by gnodet
::
Rate this Message:
I guess what I mean is that iPojo imposes some contraints on the pojo
you build and wire together.
Whereas the goal of blueprint is to be able to wire any legacy code
without introducing any dependency on the OSGi API.
IPojo hides some of the OSGi internals but if you take a look at
http://felix.apache.org/site/white-board-pattern-handler.html, it it
tightly bound to the OSGi api imho.
I certainly did not want to start a flame war here ;-) just to point
to another possibility.
On Thu, Jun 18, 2009 at 17:03, Richard S. Hall<heavy@...> wrote:
> On 6/18/09 10:56 AM, Guillaume Nodet wrote:
>>
>> Yeah, dependency injection, the fact that you can inject much more
>> things than just simple values (collections, maps, arrays.
>>
>
> This doesn't make sense to me. Dependency injection is covered by iPOJO.
> Property injection is no DI, it is configuration injection, no? At a
> minimum, let's try to differentiate between the two.
>
> Are you saying collections, maps, arrays are simple values? If so, what kind
> of complex values supported by BP?
>
> -> richard
>
>> You can also define custom converters to handle legacy code.
>>
>> On Thu, Jun 18, 2009 at 16:50, Richard S. Hall<heavy@...>
>> wrote:
>>
>>>
>>> On 6/18/09 10:35 AM, Guillaume Nodet wrote:
>>>
>>>>
>>>> FWIW, Spring-DM is being standardized as Blueprint services.
>>>> You can find an implementation of the spec (soon to be published) at
>>>> http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/
>>>>
>>>> Blueprint is much more powerfull wrt dependency injection than DS /
>>>> iPojo.
>>>>
>>>>
>>>
>>> I'd like to hear how it is "much more powerful wrt to DI" than iPOJO...I
>>> can
>>> only assume you are referring to property injection, which could be more
>>> flexible, but I cannot imagine anything else.
>>>
>>> -> richard
>>>
>>>
>>>>
>>>> The runtime is< 300k, so it's not too eavyweight either.
>>>>
>>>> On Mon, Jun 15, 2009 at 15:31, Dmitry Skavish<skavish@...>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> Hello all,
>>>>> I am trying to understand the differences between those technologies,
>>>>> but
>>>>> I
>>>>> could not find any article which compares all them side by side.
>>>>> Can somebody summarize pros and cons or point me to page where this is
>>>>> already done?
>>>>>
>>>>> We are using Guice, so I guess the logical way is to use peaberry, but
>>>>> I
>>>>> don't want to make a decision without knowing all the differences.
>>>>>
>>>>> I guess I am somewhat confused about iPOJO and DS because they look to
>>>>> me
>>>>> strikingly similar. What is the main difference between them?
>>>>>
>>>>> Thanks a lot!
>>>>>
>>>>> --
>>>>> Dmitry Skavish
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
you build and wire together.
Whereas the goal of blueprint is to be able to wire any legacy code
without introducing any dependency on the OSGi API.
IPojo hides some of the OSGi internals but if you take a look at
http://felix.apache.org/site/white-board-pattern-handler.html, it it
tightly bound to the OSGi api imho.
I certainly did not want to start a flame war here ;-) just to point
to another possibility.
On Thu, Jun 18, 2009 at 17:03, Richard S. Hall<heavy@...> wrote:
> On 6/18/09 10:56 AM, Guillaume Nodet wrote:
>>
>> Yeah, dependency injection, the fact that you can inject much more
>> things than just simple values (collections, maps, arrays.
>>
>
> This doesn't make sense to me. Dependency injection is covered by iPOJO.
> Property injection is no DI, it is configuration injection, no? At a
> minimum, let's try to differentiate between the two.
>
> Are you saying collections, maps, arrays are simple values? If so, what kind
> of complex values supported by BP?
>
> -> richard
>
>> You can also define custom converters to handle legacy code.
>>
>> On Thu, Jun 18, 2009 at 16:50, Richard S. Hall<heavy@...>
>> wrote:
>>
>>>
>>> On 6/18/09 10:35 AM, Guillaume Nodet wrote:
>>>
>>>>
>>>> FWIW, Spring-DM is being standardized as Blueprint services.
>>>> You can find an implementation of the spec (soon to be published) at
>>>> http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/
>>>>
>>>> Blueprint is much more powerfull wrt dependency injection than DS /
>>>> iPojo.
>>>>
>>>>
>>>
>>> I'd like to hear how it is "much more powerful wrt to DI" than iPOJO...I
>>> can
>>> only assume you are referring to property injection, which could be more
>>> flexible, but I cannot imagine anything else.
>>>
>>> -> richard
>>>
>>>
>>>>
>>>> The runtime is< 300k, so it's not too eavyweight either.
>>>>
>>>> On Mon, Jun 15, 2009 at 15:31, Dmitry Skavish<skavish@...>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> Hello all,
>>>>> I am trying to understand the differences between those technologies,
>>>>> but
>>>>> I
>>>>> could not find any article which compares all them side by side.
>>>>> Can somebody summarize pros and cons or point me to page where this is
>>>>> already done?
>>>>>
>>>>> We are using Guice, so I guess the logical way is to use peaberry, but
>>>>> I
>>>>> don't want to make a decision without knowing all the differences.
>>>>>
>>>>> I guess I am somewhat confused about iPOJO and DS because they look to
>>>>> me
>>>>> strikingly similar. What is the main difference between them?
>>>>>
>>>>> Thanks a lot!
>>>>>
>>>>> --
>>>>> Dmitry Skavish
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
« Return to Thread: DS or iPOJO or peaberry
| Free embeddable forum powered by Nabble | Forum Help |
