You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Remy Masson <re...@ullink.com> on 2011/06/10 10:34:04 UTC
Abstract classes as service specifications
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.
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?
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
Re: Abstract classes as service specifications
Posted by Remy Masson <re...@ullink.com>.
Thanks, that's exactly the kind of explanation I was looking for.
On Fri, Jun 10, 2011 at 3:31 PM, Richard S. Hall <he...@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<us...@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
Re: Abstract classes as service specifications
Posted by Peter Kriens <pe...@aqute.biz>.
There is actually no technical reason why you could not proxy with classes as long as they're not final. With iPOJO's byte weaving capabilities already in place you can easily create a subclass.
Kind regards,
Peter Kriens
On 10 jun 2011, at 15:31, Richard S. Hall 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
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Abstract classes as service specifications
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
For additional commands, e-mail: users-help@felix.apache.org