felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rémy Masson (JIRA) <j...@apache.org>
Subject [jira] [Commented] (FELIX-3009) Abstract classes as service specifications generates warnings at runtime
Date Tue, 28 Jun 2011 07:46:17 GMT

    [ https://issues.apache.org/jira/browse/FELIX-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13056368#comment-13056368
] 

Rémy Masson commented on FELIX-3009:
------------------------------------

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

       

Mime
View raw message