You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Bernhard Huemer (JIRA)" <de...@myfaces.apache.org> on 2007/08/16 02:23:30 UTC

[jira] Created: (MYFACES-1709) faces-config.xml validation using an XML Schema

faces-config.xml validation using an XML Schema
-----------------------------------------------

                 Key: MYFACES-1709
                 URL: https://issues.apache.org/jira/browse/MYFACES-1709
             Project: MyFaces Core
          Issue Type: Improvement
          Components: JSR-252
    Affects Versions:  1.2.0, 1.2.1-SNAPSHOT
            Reporter: Bernhard Huemer


According to an inline comment ("validation set to false during implementation of 1.2", DigesterFacesConfigUnmarshallerImpl) and my personal experience, configuration file validation hasn't been implemented so far. However, as far as I know the JSF specification says that "JSF implementations that are part of a
Java EE technology-compliant implementation are required to validate the application resource file against the XML schema" (section 10.4.2). I'll attach a sample application reproducing the "error" (the fact that there is no error is incorrect this time) and the corresponding patch.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (MYFACES-1709) faces-config.xml validation using an XML Schema

Posted by "Paul McMahan (JIRA)" <de...@myfaces.apache.org>.
    [ https://issues.apache.org/jira/browse/MYFACES-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520869 ] 

Paul McMahan commented on MYFACES-1709:
---------------------------------------

I agree that this is a good improvement for myfaces.  As an aside, I also want to point out that the spec says that validating the resource file against the schema is only required for JSF in a Java EE environment.  It is recommended but optional for JSF outside the Java EE environment.   Geronimo 2.0, for example, which embeds MyFaces 1.2 already performs schema validation at deployment time.  

So if myfaces implements its own validation then it would be good to do this in a way that is complimentary to the validation that occurs in the Java EE container.  From a visual inspection of this patch it looks like this goal is accomplished quite nicely by toggling schema validation via an init parameter, and that it is disabled by default:

        String validateConfig = context.getInitParameter(VALIDATE_CONFIG);
        return "true".equals(validateConfig); // by default, configuration files won't be validated

My only suggestion would be to add a little more doc in the code making it clear that changing the default to true instead of false would have an effect on how MyFaces behaves in a Java EE container which is probably not desirable.   If I get a chance to commit this patch then I will add that comment, or you may want to add something along those lines into the patch for anyone else who might be taking a look.

> faces-config.xml validation using an XML Schema
> -----------------------------------------------
>
>                 Key: MYFACES-1709
>                 URL: https://issues.apache.org/jira/browse/MYFACES-1709
>             Project: MyFaces Core
>          Issue Type: Improvement
>          Components: JSR-252
>    Affects Versions:  1.2.0, 1.2.1-SNAPSHOT
>            Reporter: Bernhard Huemer
>         Attachments: configuration-webapp.zip, MYFACES-1709.patch
>
>
> According to an inline comment ("validation set to false during implementation of 1.2", DigesterFacesConfigUnmarshallerImpl) and my personal experience, configuration file validation hasn't been implemented so far. However, as far as I know the JSF specification says that "JSF implementations that are part of a Java EE technology-compliant implementation are required to validate the application resource file against the XML schema" (section 10.4.2). I'll attach a sample application reproducing the "error" (the fact that there is no error is incorrect this time) and the corresponding patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.