Hi
Today this issue has been created in MyFaces issue tracker:
https://issues.apache.org/jira/browse/MYFACES-3575
Inside the discussion, I realized a flaw it has FaceletCache API.
The original code from facelets 1.1.x has a logic to cache the
"conversion" between logical identifiers to find a specific facelet
and its related URL.
So inside DefaultFaceletFactory there is a map like this:
private Map<String, URL> _relativeLocations;
Checking the code in deep, I notice this cache store also the values
of ResourceResolver.
Now suppose an scenario where you has a custom FaceletCache
implementation, and by some coincidence there is some mechanism to
load / unload some facelets by whatever reason. Once a facelet is
called, relativeLocations will hold the same key/value pair, so if a
facelet is unloaded and then another one is loaded and it has the same
association, it will fail.
A realistic scenario that will be part of JSF 2.2 spec is if you have
a jar with some composite components and facelet files. For two
different skins, there will be facelets with the same "logical
identifiers", but with different URL. This issue prevents change the
skins on the fly, because you can't clean that map.
Who should hold that map? It should be hold by FaceletCache, not by
FaceletFactory, because FaceletCache is the responsible to load/unload
and hold facelets into memory.
But things get more confusing when you think about the changes done
into javax.faces.application.ResourceHandler. In the latest javadoc
draft there is one method:
Resource createViewResource(String resourceName)
Again, the "resourceName" is in practice the same "logical identifier"
that is missing in the spec. For an specific view is the physical
viewId, but if the view is composed by other facelets bundled in the
same jar, we need that concept too in the spec, and a way to deal with
that logic too.
I hope you can see the relationship between FaceletCache and
ResourceHandler. The intention is use ResourceHandler to load facelet
definitions on the fly, but there is a logic involved in compile them
store in memory, and finally dispose them that maybe is being ignored,
right?
I know this is a topic still under discussion, but I just wanted to
warn you guys about the problem.
regards,
Leonardo Uribe