[
https://issues.apache.org/jira/browse/FELIX-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13056368#comment-13056368
]
Rémy Masson edited comment on FELIX-3009 at 6/28/11 8:03 AM:
-------------------------------------------------------------
Hi,
The interfaces from the super classes are already included, I think.
I did mean to include the super classes, one way or another. They could be
added to the 'all' set, which would allow the current check not to print the
warning.
was (Author: rmasson):
Hi,
The interfaces from the super class are already included, I think.
I did mean to include the super classes, one way or another. They could be
added to the 'all' set, which would allow the current check not to print the
warning.
> 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
