Affects Version/s: 2.2 Sprint 13
Fix Version/s: None
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.