felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Masson <remy.mas...@ullink.com>
Subject Re: Abstract classes as service specifications
Date Mon, 13 Jun 2011 10:10:18 GMT
Thanks, that's exactly the kind of explanation I was looking for.

On Fri, Jun 10, 2011 at 3:31 PM, Richard S. Hall <heavy@ungoverned.org>wrote:

> On 6/10/11 4:34, Remy Masson wrote:
>
>> Hi!
>>
>> I would like your opinion on a specific issue we're encountering when
>> using
>> iPOJO.
>> For API compatibility reason, we're inclined to use only abstract classes,
>> not interfaces.
>> The reason behind this is that we want pieces of software based against
>> any
>> further version of the API to remain compatible with previous API versions
>> even if methods have been added. Using abstract methods, we provide
>> default
>> implementations for every new method, ensuring that pieces of software
>> developped using this API remain usable.
>>
>> We noticed that, by default, iPOJO prints a warning for @Requires
>> dependencies:
>>  [WARNING] package.Class : Proxies cannot be used on service dependency
>> targeting non interface service specification package.AbstractClass
>>
>> It is my understanding that disabling proxy use for the corresponding
>> dependency disable this warning, but I would like to understand what this
>> involves.
>>
>> First and foremost, what exactly are proxies for? Is this related to the
>> Nullable objects which provide empty implementations of optional and not
>> available dependencies, avoiding null checks on the component side? What's
>> the downside of not using proxies: having to check for null optional
>> dependencies if what I just said is relevant?
>> Does disabling proxy use also mean disabling the dynamic dependency
>> injection (Dynamic / Static / Dynamic-Priority)? I don't think so, but I
>> would like to make sure.
>>
>
> While it is likely true that it inhibits Nullable objects too, the main
> reason proxies were introduced as default injection approach for iPOJO was
> to provide a "smart reference" to a service. Originally iPOJO just injected
> the service object, but many people seems to expect that they could pass
> this service around freely to internal objects and not have to worry about
> service dynamism, which was not the case. Without proxies, only declared
> components had service dynamism handled for them automatically, which meant
> that you had to convert internal objects into components do get this
> managed. Proxies avoid that, since the component is injected with a "smart
> reference" that it can pass around internally and any internal object using
> it will be insulated from having to worry about dynamism. So, if you turn
> off proxies, you lose this feature.
>
>
>  Finally, and maybe I should have started, is there a reason not to be
>> using
>> abstract classes for service specifications with iPOJO, and more
>> generally,
>> OSGi?
>>
>
> The main issue is that it doesn't enforce a strict separation between
> implementation and interface.
>
> -> richard
>
>
>  I know there are a lot of questions there, but I'm sure most can be
>> answered
>> quite easily :))
>>
>> Thanks a lot for any piece of information you may provide me with ;)
>>
>> Regards,
>> Rémy
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<users-unsubscribe@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 

*Rémy MASSON
UL ODISYS Developer*

*ULLINK
*23-25 rue de Provence
75009 Paris – France
remy.masson@ullink.com <http://www.ullink.com/>
http://www.ullink.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message