[weld-issues] [JBoss JIRA] Commented: (WELDX-44) Fix war:inplace target for Tomcat for numberguess example

[ https://jira.jboss.org/jira/browse/WELDX-44?page=com.atlassian.jira.plugi... ] Dan Allen commented on WELDX-44: -------------------------------- This is actual a problem with the Weld servlet extension on Tomcat <= 6.0.18 (the tomcat-maven-plugin uses Tomcat 6.0.16). The example works fine on Tomcat 6.0.20. What it comes down to is the order in which the listeners are called. In Tomcat 6.0.16, the JSF listener (com.sun.faces.ConfigureListener) is called first and the Weld Listener called second. The opposite is true for Tomcat 6.0.18. Now, why does this matter? Really it is an impl detail of Mojarra. Mojarra creates a composite EL resolver once in Application.getELResolver(), then uses the cached version from that point forward. Application.getELResolver() gets invoked by the JSF listener. When Application.getELResolver() creates the composite EL resolver, it calls through the WeldApplication (registered in faces-config.xml) to get the "application" el resolver Application.getApplicationELResolver(), which should be WeldELResolver. However, the problem is, WeldApplication does not register the WeldELResolver until the BeanManager is present in the servlet context. But at that point, it's too late, the composite EL resolver has already been created. Hence the ordering problem of the listeners. So WeldApplication is going to have to register the WeldELResolver even if the BeanManager is not there...either that, or instead of using addELResolver(), it is going to have to register it with the composite el resolver manually. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira