<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 02/10/2011, at 2:16 PM, Pete Muir wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>There is no need to refer to the interceptors spec to understand this. But the discussions about the interceptors spec is interesting :-)<br><br><blockquote type="cite"><blockquote type="cite">But what about my example 4, the shared @Inject method + @PostConstruct case?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Do we need to invoke all superclass injection first? thus do all @Inject fields + @Inject methods + @PostConstruct first, then the one from the Horse class?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Could we also specify that all @Inject methods needs to get called before @PostConstruct?<br></blockquote></blockquote><br>JSR-330 says that injected fields happen before methods, and always superclass-first i.e.<br><br>class X extends Y { ... }<br><br>any injected field in Y, followed by any injected method in Y followed by any injected field in X followed by any injected method in X.<br><br>CDI then covers the @PostConstruct in 5.5.2 of the CDI spec.<br><br>The container must ensure that:<br>•<span class="Apple-tab-span" style="white-space:pre"> </span>Initializer methods declared by a class X in the type hierarchy of the bean are called after all injected fields declared by X or by superclasses of X have been initialized, and after all Java EE component environment resource dependencies declared by X or by superclasses of X have been injected.<br>•<span class="Apple-tab-span" style="white-space:pre"> </span>Any @PostConstruct callback declared by a class X in the type hierarchy of the bean is called after all initializer meth- ods declared by X or by superclasses of X have been called, after all injected fields declared by X or by superclasses of X have been initialized, and after all Java EE component environment resource dependencies declared by X or by su- perclasses of X have been injected.<br><br>Thus, <br><br>You can be assured that the @PostConstruct for Y happens after injection, and the same for X. However you can't be certain that the @PostConstruct for Y happens before the injection for X.<br><br>Do we need to clarify this? I'm not sure we do? If we do, why?<br></div></blockquote><div><br></div><div>I don't think this needs clarification.</div><div><br></div><blockquote type="cite"><div><br>On 1 Oct 2011, at 06:21, Stuart Douglas wrote:<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On 01/10/2011, at 7:47 PM, Mark Struberg wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Oki found it there:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">most general superclass first.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">of course the interceptors_spec_1_1 only defines this for 'Lifycycle interceptors' <br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The spec is not very clear on this point, but @PostConstruct methods on a bean are considered lifecycle interceptors.<br></blockquote><br>Correct. I think this would need clarifying in the interceptors spec - Mark could you file an EJB spec issue for this?<br><br><blockquote type="cite">There is actually a fair bit of deviation between CDI and the interceptors and Managed bean spec on some points: <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">- CDI beans don't support interceptor methods on the beans themselves (at least Weld does not, the interceptors spec allows you to have an @AroundInvoke method on the managed bean itself).<br></blockquote><br>Wow, I totally missed that before. I think this is just a bug in Weld. Could you create an issue?<br></div></blockquote><div><br></div><div><a href="https://issues.jboss.org/browse/CDITCK-233">https://issues.jboss.org/browse/CDITCK-233</a></div><div><a href="https://issues.jboss.org/browse/WELD-980">https://issues.jboss.org/browse/WELD-980</a></div><br><blockquote type="cite"><div><br><blockquote type="cite">- @Resource @Psersitence* @EJB etc annotation of CDI managed beans do not create JNDI bindings like they are supposed to according to the EE platform spec.<br></blockquote><br>This is partly a Weld bug, partly a Java EE integration issue, which never got resolved properly. The CDI spec doesn't define this, where is it in Java EE? If it's there, then it's an impl bug, not a spec clarification I think.<br><br></div></blockquote><div><br></div><div>This is partly defined by the 'Common Annotations for the Java Platform' spec, and by chapter 5 in the EE platform spec (the section on resources naming and injection).</div><div><br></div><div>Stuart</div><br><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite">As far as I know no one actually really uses these 'features' anyway, but it is a deviation from the spec that we should probably clarify.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Stuart<br></blockquote><blockquote type="cite"><br></blockquote><br></div></blockquote></div><br></body></html>