FaceletCache: some caching is incorrectly done in DefaultFaceletFactory

LU> I realized the FaceletCache API has a flaw.

LU> The original code from facelets 1.1.x has logic to cache the
LU> "conversion" between logical identifiers to find a specific facelet and
LU> its related URL.

LU> So inside DefaultFaceletFactory there is a map like this:

LU> private Map<String, URL> _relativeLocations;

LU> Checking the code deeper, I notice this cache store also the values
LU> returned by the ResourceResolver.

LU> Now suppose a scenario where you have a custom FaceletCache
LU> implementation, and by some coincidence there is some mechanism to load/
LU> unload some facelets in some way. Once a facelet is called,
LU> relativeLocations will hold the same key/value pair, so if a facelet is
LU> unloaded and then another one is loaded and it has the same association,
LU> it will fail to find the new one.

LU> A realistic scenario that will be part of JSF 2.2 spec is if you have
LU> a jar with some composite components and facelet files. For two
LU> different skins, there will be facelets with the same "logical
LU> identifiers", but with different URL. This issue prevents change the
LU> skins on the fly, because you can't clean that map.

LU> Who should hold that map? It should be hold by FaceletCache, not by
LU> FaceletFactory, because FaceletCache is the responsible to load/unload
LU> and hold facelets into memory.

Affected Versions

[2.2 Sprint 13]

Start by tracing DefaultFaceletFactory and FaceletCache to identify where the logical-identifier-to-URL map is stored and how ResourceResolver results are cached. Verify the unload/reload and different-skin scenarios described in the issue, and consider the work complete when the cache owner can replace or clear those associations correctly.