Sorry for the late answer.
> I see that my suggestion about "clear" the map was not very clear. I was thinking on add some code inside org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(ServletContext) to do proper cleanup (if you have a WeakHashMap somewhere, call a method that removes the key).
> For the case of MetaRulesetImpl, I think use a WeakHashMap and do proper cleanup on AbstractFacesInitializer.destroyFaces is better. There is no reason to call FacesContext.getCurrentInstance(), since the returned instances are "application scope" and once initialized does not change.
You're right, Leo. In this case it might be better to use the static WeakHashMap<ClassLoader, WeakHashMap<String, MetadataTarget>> and ensure a cleanup on application shutdown. This will be faster. The reason I put this on ApplicationMap was simply to use the advantage of ApplicationMap beeing cleared automatically. I'll change this.
> There are valid cases where ThreadLocal usage is required. For example, in FlashELResolver it is possible that an EL expression could be resolved outside normal JSF lifecycle, where there is no FacesContext set, so the code committed will not work as expected. The same applies for VariableResolverToELResolver, so that code must be reverted to its original form.
I disagree, because the FlashELResolver only makes sence for JSF and it actually really does use the FacesContext, however indirectly, because it gets the ExternalContext via the FacesContext. So if you have no FacesContext at all the FlashElResolver will fail no matter what (no FacesContext means no ExternalContext means no Flash). Furthermore you can't really remove() the ThreadLocal in FlashELResolver in a consistent way other than using an additional request-listener. I think that using the FacesContext here instead of the ThreadLocal is a better alternative, but please feel free to convince me otherwise!