Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Mon, 27 Jun 2011 16:54:48 +0000 (UTC)
From: "Clement Escoffier (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: 
 <455245835.44313.1309193688425.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1112235008.29179.1308743508069.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (FELIX-3009) Abstract classes as service
 specifications generates warnings at runtime
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/FELIX-3009?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1305=
5650#comment-13055650 ]=20

Clement Escoffier commented on FELIX-3009:
------------------------------------------

Hi,

Do you mean the interfaces from the super class (should be done), or includ=
ing the super class(es) into 'all' ?

Anyway, the warning should not be printed if the component class extends th=
e super class

> 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=C3=A9my 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 f=
urther version of the API to remain compatible with previous API versions e=
ven if methods have been added. Using abstract methods, we provide default =
implementations for every new method, ensuring that pieces of software deve=
lopped using this API remain usable.
> We therefore end up having abstract classes both for @Requires and @Provi=
des annotations.
> We noticed runtime warnings are being printed by iPOJO.
> Firstly, for service requirements, such warnings are printed:
> =09(ERROR) [WARNING] com.SomeComponent : Proxies cannot be used on servic=
e dependency targetting non interface service specification com.AnAbstractC=
lass
> Disabling proxies (through annotation parameters or the "ipojo.proxy" sys=
tem property) prevents the warning from being printed. But shouldn't proxie=
s 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 co=
uld 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 dis=
abled with non final classes, since iPOJO should be (is?) able to handle th=
ose.
> Secondly, for service specifications, we get those:
> =09(ERROR) [WARNING] com.AnotherComponent : The specification com.AnAbstr=
actClassSpecification is not implemented by com.AnotherComponent it might b=
e a superclass or the class itself.
> Although, when look at com.A implementation, we have:
> public class AnotherComponent extends AbstractClassSpecificationWithAddit=
ions
> with=20
> public abstract class AbstractClassSpecificationWithAdditions extends AnA=
bstractClassSpecification
> 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:
> =09all =3D computeInterfaces(serviceSpecification, parent, desc.getBundle=
Context().getBundle());
> Where "all" is a Set of the known interfaces. When it'll go through the p=
rovided specifications, it will check if the provided interfaces are contai=
ned 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 b=
e 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