[
https://issues.apache.org/jira/browse/FELIX-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier reassigned FELIX-3009:
----------------------------------------
Assignee: Clement Escoffier
> Abstract classes as service specifications generates warnings at runtime
> ------------------------------------------------------------------------
>
> Key: FELIX-3009
> URL: https://issues.apache.org/jira/browse/FELIX-3009
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
> Affects Versions: iPOJO-1.6.0
> Reporter: Rémy Masson
> Assignee: Clement Escoffier
>
> Hi,
> For API compatibility reason, we're inclined to use only abstract classes,
> not interfaces.
> Releasing a versioned API, 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 therefore end up having abstract classes both for @Requires and @Provides
> annotations.
> We noticed runtime warnings are being printed by iPOJO.
> Firstly, for service requirements, such warnings are printed:
> (ERROR) [WARNING] com.SomeComponent : Proxies cannot be used on service
> dependency targetting non interface service specification com.AnAbstractClass
> Disabling proxies (through annotation parameters or the "ipojo.proxy" system
> property) prevents the warning from being printed. But shouldn't proxies
> still be working with abstract classes? I'm quoting Peter Kriens's answer to
> the mail I sent to the users mailing-list subject, "Abstract classes as
> service specifications": "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.".
> The matter here is therefore to know whether or not proxies should be
> disabled with non final classes, since iPOJO should be (is?) able to handle
> those.
> Secondly, for service specifications, we get those:
> (ERROR) [WARNING] com.AnotherComponent : The specification
> com.AnAbstractClassSpecification is not implemented by com.AnotherComponent
> it might be a superclass or the class itself.
> Although, when look at com.A implementation, we have:
> public class AnotherComponent extends AbstractClassSpecificationWithAdditions
> with
> public abstract class AbstractClassSpecificationWithAdditions extends
> AnAbstractClassSpecification
> While it's true that the specification is not "implemented", it is still
> being provided. The specification is extended instead of being implemented.
> I took a look at the code implementation, and this seems to be handled in
> ProvidedServiceHandler.java:
> all = computeInterfaces(serviceSpecification, parent,
> desc.getBundleContext().getBundle());
> Where "all" is a Set of the known interfaces. When it'll go through the
> provided specifications, it will check if the provided interfaces are
> contained in that Set. If not, the warning is printed.
> Could it be possible to also take a look at superclasses?
> Filed this as a bug, because non interface service requirements seem to be
> handled already and I'm not sure the current behavior is expected. Might be
> an evolution.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
