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: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
