Thanks, that's exactly the kind of explanation I was looking for. On Fri, Jun 10, 2011 at 3:31 PM, Richard S. Hall <[email protected]>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<[email protected]> > For additional commands, e-mail: [email protected] > > -- *Rémy MASSON UL ODISYS Developer* *ULLINK *23-25 rue de Provence 75009 Paris – France [email protected] <http://www.ullink.com/> http://www.ullink.com
