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
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
