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