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]
