Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Date: Sat, 12 Dec 2015 19:23:46 +0000 (UTC)
From: "Christian Schneider (JIRA)" <jira@apache.org>
To: dev@aries.apache.org
Message-ID: <JIRA.12921411.1449946414000.6931.1449948226886@Atlassian.JIRA>
In-Reply-To: <JIRA.12921411.1449946414000@Atlassian.JIRA>
References: <JIRA.12921411.1449946414000@Atlassian.JIRA>
 <JIRA.12921411.1449946414827@arcas>
Subject: [jira] [Commented] (ARIES-1474) blueprint-maven-plugin: Inherited
 init/destroy methods are ignored
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Christian Schneider commented on ARIES-1474:
--------------------------------------------

I think before doing changes we need to first have a common understanding of the rules to be in place. This is from JSR-250 Chapter 2.1:
1. Class-level annotations only affect the class they annotate and their members, that is, its methods and fields. They never affect a member declared by a superclass, even if it is not hidden or overridden by the class in question.
2. In addition to affecting the annotated class, class-level annotations may act as a shorthand for member-level annotations. If a member carries a specific memberlevel
annotation, any annotations of the same type implied by a class-level annotation are ignored. In other words, explicit member-level annotations have priority over member-level annotations implied by a class-level annotation. For example, @WebService annotation on a class implies that all the public methods in the class that it is applied on are annotated with @WebMethod if there is no @WebMethod annotation on any of the methods. However if there is a @WebMethod annotation on any method then the @WebService does not imply the presence of @WebMethod on the other public methods in the class.
3. The interfaces implemented by a class never contribute annotations to the class itself or any of its members.
4. Members inherited from a superclass and which are not hidden or overridden maintain the annotations they had in the class that declared them, including member-level annotations implied by class-level ones.
5. Member-level annotations on a hidden or overridden member are always ignored

As far as I understood these rules also apply to what we do.
So one immediate change I see from these rules is that we need to ignore annotations from interfaces.

About your example the expectation would be that for class C:
destroy="destroy" and init is not set.
Is that asumption correct?


> blueprint-maven-plugin: Inherited init/destroy methods are ignored
> ------------------------------------------------------------------
>
>                 Key: ARIES-1474
>                 URL: https://issues.apache.org/jira/browse/ARIES-1474
>             Project: Aries
>          Issue Type: Bug
>          Components: Blueprint
>            Reporter: Sam Wright
>
> Current behaviour:
> {code}
> public class A {
>     @PostConstruct
>     public void init() {}
>     @PreDestroy
>     public void destroy() {}
> }
> public class B extends A {}
> public class C extends B {
>     @Override
>     public void init() {}
>     @PostConstruct
>     public void secondInit()
> }
> {code}
> Three problems:
> * The A.destroy() method is ignored
> * The C.init() method overrides A.init() without the @PostConstruct annotation, but is still taken to be the init method. This means the subclass can't disable a superclass' init method.
> * The C.secondInit() method is silently ignored because another init method is found first. 
> Patch incoming...


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)