jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] [1121-FaceletCacheDefaultFacelet] DISCUSSION

From: Edward Burns <edward.burns_at_oracle.com>
Date: Thu, 12 Jul 2012 07:48:36 -0700

Hello Leonardo,

I've re-woredd some of your text to aid in my understanding. Please
correct me if I am wrong. I observe that your email calls out two
specific problems, which I have labeled 1121-FaceletCacheDefaultFacelet, and
PROBLEM_ViewIdentification.

>>>>> On Wed, 27 Jun 2012 17:11:44 +0200, Leonardo Uribe <lu4242_at_gmail.com> said:

LU> Today this issue has been created in MyFaces issue tracker:

LU> https://issues.apache.org/jira/browse/MYFACES-3575

LU> Inside the discussion, I realized the FaceletCache API has a flaw.

[...]

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

LU> private Map<String, URL> _relativeLocations;

[...]

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.

1121-FaceletCacheDefaultFacelet: Yes, I understand the problem and agree I need to
take action.

LU> But things get more confusing when you think about the changes done in
LU> javax.faces.application.ResourceHandler. In the latest javadoc draft
LU> there is one method:

LU> Resource createViewResource(String resourceName)

LU> Again, the "resourceName" is in practice the same "logical
LU> identifier" that is missing in the spec. For a specific view, that
LU> "logical identifier" is the physical viewId, but if the view is
LU> composed by other facelets bundled in the same jar, we need that
LU> concept too in the spec, and a way to deal with that logic too.

PROBLEM_ViewIdentification: I need you to be more concrete about this.
I do get the sense there is a problem here, but I don't see it as
clearly as with the 1121-FaceletCacheDefaultFacelet
problem above. I see that Leonardo's mail on this thread from "Fri, 29
Jun 2012 17:39:04 +0200" is also related to PROBLEM_ViewIdentification,
but goes in a different direction. That email is so deep that it
warrants its own response. Please let's all try to keep the threads
focused. Use the subject line for its intended purpose!

Can we solve 1121-FaceletCacheDefaultFacelet in isolation of
PROBLEM_ViewIdentification? If not, we need to isolate the problem more
cleanly.

LU> I hope you can see the relationship between FaceletCache and
LU> ResourceHandler. The intention is use ResourceHandler to load facelet
LU> definitions on the fly, but there is a logic involved in compile them
LU> store in memory, and finally dispose them that maybe is being ignored,
LU> right?

Yes, this is 1121-FaceletCacheDefaultFacelet, I understand that one. I
have filed JAVASERVERFACES_SPEC_PUBLIC-1121.

Ed

-- 
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage:               | http://ridingthecrest.com/
|  5 Business days til JSF 2.2 Public Review to EG