Hi<br><br>This issue is related to<br><br><a href="https://issues.apache.org/jira/browse/MYFACES-2509">https://issues.apache.org/jira/browse/MYFACES-2509</a> @ListenerFor not processed for global system events<br><br>On JSF 2.0 the following system events were added:<br>
<br>javax.faces.event.PostConstructApplicationEvent<br>javax.faces.event.PreDestroyApplicationEvent<br><br>javax.faces.event.PostConstructCustomScopeEvent<br>javax.faces.event.PreDestroyCustomScopeEvent<br><br>javax.faces.event.PostConstructViewMapEvent<br>
javax.faces.event.PreDestroyViewMapEvent<br><br>And the following component system events were added:<br><br>javax.faces.event.PostAddToViewEvent<br>javax.faces.event.PreRemoveFromViewEvent<br>javax.faces.event.PostRestoreStateEvent<br>
<br>javax.faces.event.PreValidateEvent<br>javax.faces.event.PostValidateEvent<br><br>javax.faces.event.PreRenderComponentEvent<br>javax.faces.event.PreRenderViewEvent<br><br>The javadoc of @ListenerFor annotation is clear to say which classes could be a valid target for this annotation:<br>
<br>&quot;....The default implementation must support attaching this annotation to UIComponent or Renderer classes. In both cases, the <br>annotation processing described herein must commence during the implementation of any variant of Application.createComponent()  and <br>
must complete before the UIComponent instance is returned from createComponent()....&quot;<br><br>Long time ago on MYFACES-2509, it was mentioned those classes could not be the only target:<br><br>Jan-Kees van Andel<br><br>
JK&gt;&gt; Hrm, it looks like the JavaDoc can be interpreted in multiple ways.<br>JK&gt;&gt; <br>JK&gt;&gt; What I read, is that it should be possible for classes that implement <br>JK&gt;&gt; SystemEventListener, to listen to SystemEvents.<br>
JK&gt;&gt; <br>JK&gt;&gt; For example: PostConstructApplicationEvent<br>JK&gt;&gt; <br>JK&gt;&gt; The current implementation cannot deal with this event, because it occurs <br>JK&gt;&gt; before the ApplicationImpl code is invoked (there is no component tree at <br>
JK&gt;&gt; that time). For this reason, we need to check it @startup.<br>JK&gt;&gt; <br>JK&gt;&gt; But because its so ambiguous, I suggest to leave it out of the (myfaces core) beta release.<br><br>Thinking about how to enhance some myfaces projects and reading some documentation I notice this usage on the book The Complete <br>
Reference JavaServer Faces 2.0 Page 509 (just type on google @ListenerFor PostConstructApplicationEvent and you will find it):<br><br>@ListenerFor(systemEventClass = javax.faces.event.PostConstructApplicationEvent.class)<br>
public class TestSystemEventListener implements SystemEventListener {<br>   ...<br>}<br><br>The previous example does not work on both myfaces and mojarra, because both implement what @ListenerFor javadoc says. But note this <br>
syntax should be valid on JSF 2.0, at least for PostConstructApplicationEvent and PreDestroyApplicationEvent.<br><br>I tried something more elaborated like this:<br><br>@ManagedBean(name=&quot;myCustomListener&quot;, eager=true)<br>
@ApplicationScoped<br>@ListenersFor({<br>@ListenerFor(systemEventClass=PostConstructApplicationEvent.class),<br>@ListenerFor(systemEventClass=PreDestroyApplicationEvent.class)<br>})<br>public class SimpleFacesConfigListener implements SystemEventListener<br>
{<br>   ...<br>}<br><br>Does not work too, but the fact is that syntax should be valid too. Well, maybe we can use @PostConstruct and @PreDestroy and have the <br>same effect, but it is worth to mention it.<br><br>It could be good to know what do you think about it. I feel inclined to include it in myfaces, but better to ask first.<br>
<br>Anyway, it could be good if you can consider if it is worth or not adding @ListenerFor annotation support for JSF application scope objects and<br>factories (ex: Application, RenderKit, StateManager, ViewHandler .....). I&#39;m not very sure about it, but better to mention it.<br>
<br>Should I create a spec issue for this one? I think yes.<br><br>In another topic, looking for more issues, I notice a side effect testing this example:<br><br>  &lt;system-event-listener&gt;<br>    &lt;system-event-listener-class&gt;org.apache.myfaces.testListenerFor.SimpleFacesConfigListener&lt;/system-event-listener-class&gt;<br>
    &lt;system-event-class&gt;javax.faces.event.PostConstructApplicationEvent&lt;/system-event-class&gt;<br>  &lt;/system-event-listener&gt;<br>  &lt;system-event-listener&gt;<br>    &lt;system-event-listener-class&gt;org.apache.myfaces.testListenerFor.SimpleFacesConfigListener&lt;/system-event-listener-class&gt;<br>
    &lt;system-event-class&gt;javax.faces.event.PreDestroyApplicationEvent&lt;/system-event-class&gt;<br>  &lt;/system-event-listener&gt;<br><br>public class SimpleFacesConfigListener implements SystemEventListener<br>{<br>
   ...<br>}<br><br>In this case according to both myfaces and mojarra implementation, the object instance that receive PostConstructApplicationEvent is <br>not the same that receive PreDestroyApplicationEvent, so the listener should be &quot;stateless&quot;, but the spec does not warn about this <br>
fact (in theory it should be). <br><br>regards,<br><br>Leonardo Uribe<br>