Hi,
I am pretty sure most containers will do something similar, as according to the spec we need to be able to run listeners defined in TLD's, which mean they need to be parsed at deployment time.
The only way around it is to try and determine earlier if Mojarra is actually needed or not in app server code, which has a lot more flexibility. Mojarra can only do what the various specs allow it to do, and there is not really any way around this just using Servlet/JSP API's.
That's not quite correct any more I think. jsf_core.tld is an ancient artefact that's only there for backwards compatibility. Since quite a long time Mojarra adds `com.sun.faces.config.ConfigureListener` itself using the ServletContainerInitializer and Servlet 3.0 programmatic registration:
servletContext.addListener(com.sun.faces.config.ConfigureListener.class);
The *-taglib.xml variants are the current versions. (Mojarra 2.4 pre-parses its own internal ones during the build.) I'm also patching in my friend Bauke who may be able to confirm or further explain this if needed.
You are right though that other containers have somewhat similar potentially outdated code present. GlassFish/Payara for instance look whether the "javax.faces.webapp.FacesServlet" is actually added (programmatically or otherwise), so they'll leave the detection part to the JSF implementation (Mojarra) and only use a single trigger point. I'm fairly sure this can be removed in Payara as well, so I'll look into removing it there if indeed possible.
You are also right that the container often has more flexibility, although technically a JSF implementation is not constrained to just using Servlet or EE APIs, but since we want Mojarra to be able to run on other container we practically do constrain ourselves of course ;)
Kind regards,
Arjan