>>>>> On Wed, 13 Mar 2013 12:13:15 -0400, Andy Schwartz <andy.schwartz_at_oracle.com> said:
AS> Prior to the addition of this class, we've got three APIs in the
AS> top-level javax.faces package:
AS> - FacesWrapper
AS> - FactoryFinder
AS> - FacesException
AS> ApplicationConfigurationResourceDocumentPopulator looks very out of
AS> place here - almost like we forgot to assign it a package.
AS> Can we push this class down to javax.faces.application?
Yes.
AS> The name ApplicationConfigurationResourceDocumentPopulator seems
AS> unnecessarily verbose. Why not just ApplicationConfigurationPopulator?
Yes.
AS> Similar comment for this method name:
AS> + public abstract void
AS> populateApplicationConfigurationResource(Document toPopulate);
AS> Seems like "populateApplicationConfiguration" is plenty descriptive.
AS> This also avoids any association with javax.faces.application.Resource.
Yes.
AS> One thing that strikes me as awkward is that the Document is passed in
AS> rather than returned. This means that an implementation that uses an
AS> XML parser to produce a Document needs to copy the contents over to the
AS> provided Document.
AS> Why impose this extra step on implementations of this contract?
AS> (Possible this might be necessary, but I am not clear on why.)
I like the ability of the current API to constrain the XML Schema
version to one that the implementation wants, not the leave it open to
the callee.
[...]
AS> I think we need to verify that this contract is sufficient to address
AS> the requirements for the use case identified by the original filer.
AS> Since the issue was filed by members of the ADF team, I am following up
AS> with them on this topic.
As for verifying the sufficiency of the contract, I refer you to this
comment in the feature request for the issue [1]:
EB> I spoke with David Schneider from ADFc on 20120207. He advised me
EB> that a simple specification for this issue would satisfy. Here it
EB> is.
EB> Modify the spec so that there's an API that is called exactly once,
EB> at startup, that will give an instance of org.w3c.dom.Document when
EB> called. This Document will be included in the list of Documents that
EB> form the runtime representation of the Application Configuration
EB> Resources.
EB> As usual, items specified in WEB-INF/faces-config.xml will take
EB> precedence over other items.
Given this information, I'm going to apply the changes I've agreed to in
this email and close this out for 2.2.
Ed
--
[1] http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-533?focusedCommentId=331606&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_331606