You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org> on 2011/06/20 17:46:47 UTC

[jira] [Commented] (MYFACES-3179) Inconsistent behaviour implementing and registering SystemEventListeners for PostAddToViewEvents

    [ https://issues.apache.org/jira/browse/MYFACES-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052017#comment-13052017 ] 

Leonardo Uribe commented on MYFACES-3179:
-----------------------------------------

Thanks for the example, it helps a lot. I checked it and:

    1) via @ListenerFor annotations : @ListenerFor only works for component and renderer classes. This was discussed on MYFACES-2509 and sended to the EG. The best we can do is create this issue on spec issue tracker:

  http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1020

    2) via definition in faces-config.xml : It is a bug on MyFaces. The code try to calculate the sourceClass, using some introspection, but there are cases like the one you described that sourceClass should be null, because PostAddToViewEvent can target multiple component classes. Thanks for the tip

    3) via programmatically adding the listener through an eagerly created application scoped bean: Everything works as expected.

Thanks for the comparison. I'll close this one as fixed as soon as I commit the patch.

> Inconsistent behaviour implementing and registering SystemEventListeners for PostAddToViewEvents
> ------------------------------------------------------------------------------------------------
>
>                 Key: MYFACES-3179
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3179
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: JSR-314
>    Affects Versions: 2.0.7, 2.1.0, 2.1.1
>         Environment: Tested on Tomcat 7
>            Reporter: Deryk Sinotte
>         Attachments: listeners.zip
>
>
> I've developed a test case (which will be attached) which is a simple JSF app that has 3 different methods of registering SystemEventListeners for PostAddToViewEvents:
>     1) via @ListenFor annotations
>     2) via definition in faces-config.xml
>     3) via programmatically adding the listener through an eagerly created application scoped bean
> Then I ran this tst case with the following JSF implemenations:
>     * Mojarra 2.1
>     * MyFaces 2.0.7
>     * MyFaces 2.1.0
>     * MyFaces 2.1.1
> The behaviour can be summarized as follows:
> Method 1 - Annotations
> All implementations: The listener instance is never constructed or used.  (Perhaps it's a limitation of the annotation processing in Tomcat?)
> Method 2 - Defining in faces-config.xml
> Mojarra 2.1: An instance of the listener is created and used appropriately.
> MyFaces 2.*: An instance of the listener is created but the isListenerFor() and processEvent() methods are never called.
> Method 3 - Programmatic registration
> All implementations: An instance of the listener is created and used appropriately.
> So the question is why, when the listeners are defined in the faces-config file, are the listeners created but never called.  Other MyFaces JIRAs that might have some relevance:
> https://issues.apache.org/jira/browse/MYFACES-2509
> https://issues.apache.org/jira/browse/MYFACES-2638
> Bottom line is that only the programmatic approach appears to be reliable across the 2 implementations.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira