[JAVASERVERFACES_SPEC_PUBLIC-1121] FaceletCache: some caching is incorrectly done in DefaultFaceletFactory Created: 12/Jul/12  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.2 Sprint 13
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Issue Links:
depends on JAVASERVERFACES_SPEC_PUBLIC-777 Define API to allow pluggable Facelet... Closed


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.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Set priority to Minor

Generated at Sat Dec 10 17:30:13 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.