[jboss-jira] [JBoss JIRA] (WFLY-3277) Fix for JAVASERVERFACES-3189 causes memory leak

[ https://issues.jboss.org/browse/WFLY-3277?page=com.atlassian.jira.plugin.... ] Farah Juma commented on WFLY-3277: ---------------------------------- Because the JSF implementation module dependency is added to every deployment, one ConfigureListener gets registered for every deployment even if it doesn't use JSF (the ConfigureListener is defined in the jsf_core.tld file in the jsf-impl.jar). For apps that use JSF, a second ConfigureListener ends up getting added by Mojarra if the app doesn't contain a mapping of FacesServlet in its web.xml file (this is because of a [workaround | https://issues.jboss.org/browse/WFLY-2594?focusedCommentId=12946617&p...] for a GlassFish issue that was added to Mojarra 2.x). I found that the memory leak only affects non-JSF apps though. As discussed with Tomaz, one way to work around the issue is to have the JSF subsystem remove the ConfigureListener from the TLD metadata unless the app has a mapping of FacesServlet in its web.xml. I tried this out (see [here| https://github.com/fjuma/wildfly/commit/fc9157ffc734960f20feb2262ea8c0509...]) and it does work. However, I think I just found a better way to fix this in ConfigureListener by making sure that appropriate clean up is done when ConfigureListener.contextInitialized() is called for an app that doesn't use JSF. I've created the following upstream issue and if my fix looks good to the Mojarra team, I can apply it to our fork: https://java.net/jira/browse/JAVASERVERFACES-3260 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira