[seam-issues] [JBoss JIRA] Closed: (JBSEAM-1710) Support multiple life cycle methods (per inheritance) on JavaBean classes

Support multiple life cycle methods (per inheritance) on JavaBean classes ------------------------------------------------------------------------- Key: JBSEAM-1710 URL: https://jira.jboss.org/jira/browse/JBSEAM-1710 Project: Seam Issue Type: Bug Components: Core Affects Versions: 2.0.0.BETA1, 2.0.0.CR1 Reporter: Dan Allen Priority: Minor Original Estimate: 2 days Remaining Estimate: 2 days EJB supports multiple life cycle methods for a bean, as long as two life cycle methods do not appear in the same class in the inheritance hierarchy. Thus, you can define a @PostConstruct method on the concrete class, and a different @PostConstruct method on its superclass. As per the EJB specification (with minor corrections for clarity): "Life cycle callback interceptor methods may be defined on super classes of the bean class, the bean class itself, or interceptor classes. However, a given class may not have more than one life cycle callback interceptor method for the same life cycle event." The following comment is found in Component.java regarding this issue: // TODO: check the EJB3 spec, I think you are allowed to have multiple life cycle methods on a bean! The comment is correct in that multiple life cycle methods are not allowed on a single bean class. However, through inheritance, it is possible to have two different life cycle methods for the same Seam component. Currently, Component#initMembers() works backwards up the inheritance chain while scanning methods. Therefore, the life cycle method on the highest member of the hierarchy currently wins. So, as it stands now, the handling of life cycle callbacks for JavaBeans is inconsistent with how they are handled by the EJB container on session and message-driven beans. I was able to verify this with a simple demonstration I conducted. This incompatibility shouldn't be too difficult to fix. Just switch the life cycle method properties to an array and ensure that superclass methods are called first.