[
https://issues.apache.org/jira/browse/ARIES-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15054873#comment-15054873
]
Sam Wright commented on ARIES-1474:
-----------------------------------
Very interesting - I didn't realise those rules were formalised in a JSR.
As per those rules for a bean for class C, A.init() should be ignored because
it is overridden by a method which doesn't have @PostConstruct due to rule 5,
and A.destroy() should be the destroy method due to rule 4. So I would expect
<bean class="C" init-method="secondInit" destroy-method="destroy".
Currently blueprint-maven-plugin looks for methods declared in the class,
parent class, and interface. This is a bit weird as it ignores grandparent
classes (meaning A.destroy() is ignored, violating rule 4), and as per rule 3
the interfaces shouldn't contribute annotations. If A.init() were
defined/overridden in B then blueprint-maven-plugin would use it as the init
method, ignoring the fact that it is overridden in C.init() without
@PostConstruct, violating rule 5. It also only chooses the first method found
with @PostConstruct and silently ignores other ones.
My PR gives the behaviour I expect by using Class.getMethods() on the class
being inspected, instead of Class.getDeclaredMethods() on the class, superclass
and interface. That way all methods are included in the search apart from
overriden methods (the overriding methods take their place). It also throws an
exception when multiple methods are found with @PostConstruct/PreDestroy.
> 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)
