MyFaces Tomahawk
  1. MyFaces Tomahawk
  2. TOMAHAWK-1560

Tomahawk 1.1.10 for JSF 1.2 fails to deploy on JBoss AS 6 because of TLD errors

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.1.10
    • Fix Version/s: 1.1.11
    • Component/s: None
    • Labels:
      None

      Description

      Tomahawk 1.1.10 for JSF 1.2 fails to deploy on the recently released JBoss AS 6. This appears to be because of errors in tomahawk.tld. I managed to resolve it by taking the following steps (any of which may be sub-optimal):

      1. Changed xsi:schemaLocation="http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd" to xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd" (i.e. the first half of the schemaLocation was missing)

      2. Removed <display-name> tag (is a bad element name?)

      3. Removed all <description> tags (they contain invalid markup?)

      Regards,

      Richard.

      1. TOMAHAWK-1560.patch
        6 kB
        Christian Kaltepoth

        Activity

        Hide
        Christian Kaltepoth added a comment -

        I had similar issues with MyFaces Commons Converters 1.0.1 for JSF 1.2 on JBoss 6.0.0.Final. The root cause is that the MyFaces Builder Plugin creates an invalid TLD file that doesn't validate against the required XSD schema (http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd).

        I identified the following problems:

        • The "schemaLocation" attribute is missing the XML namespace (see 1. in original bug report).
        • The <description> and <display-name> elements inside the <taglib> element are misplaced. The correct order (according to the XSD schema) is: <description>, then <display-name> and then the other child elements.
        • A <description> element must be the first child element inside <tag> and <attribute> elements.

        JBoss 6.0.0 is very strict in parsing the TLD files and fails because of the reasons mentioned above. You can reproduce the schema incompatibility with Eclipse by renaming the TLD file to .xml and running the XML Validation on that file ("Right-Click on file -> Validate").

        I attached a patch against the current trunk of the MyFaces Builder Plugin's "tomahawk12.vm" which generates the TLD files for Tomahawk an Commons.

        Please note that I'm not completely sure whether Tomahawk and Commons for JSF 1.2 are the only artifacts that are affected. I saw that "trinidad-tld12.vm" is also erroneous but didn't check in detail.

        Show
        Christian Kaltepoth added a comment - I had similar issues with MyFaces Commons Converters 1.0.1 for JSF 1.2 on JBoss 6.0.0.Final. The root cause is that the MyFaces Builder Plugin creates an invalid TLD file that doesn't validate against the required XSD schema ( http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd ). I identified the following problems: The "schemaLocation" attribute is missing the XML namespace (see 1. in original bug report). The <description> and <display-name> elements inside the <taglib> element are misplaced. The correct order (according to the XSD schema) is: <description>, then <display-name> and then the other child elements. A <description> element must be the first child element inside <tag> and <attribute> elements. JBoss 6.0.0 is very strict in parsing the TLD files and fails because of the reasons mentioned above. You can reproduce the schema incompatibility with Eclipse by renaming the TLD file to .xml and running the XML Validation on that file ("Right-Click on file -> Validate"). I attached a patch against the current trunk of the MyFaces Builder Plugin's "tomahawk12.vm" which generates the TLD files for Tomahawk an Commons. Please note that I'm not completely sure whether Tomahawk and Commons for JSF 1.2 are the only artifacts that are affected. I saw that "trinidad-tld12.vm" is also erroneous but didn't check in detail.
        Hide
        Christian Kaltepoth added a comment -

        Patch for MyFaces Builder Plugin

        Show
        Christian Kaltepoth added a comment - Patch for MyFaces Builder Plugin
        Hide
        Christian Kaltepoth added a comment -

        Ups, just saw that I didn't click on "Grant license to ASF for inclusion in ASF works" radio button! Of cause I do!

        Show
        Christian Kaltepoth added a comment - Ups, just saw that I didn't click on "Grant license to ASF for inclusion in ASF works" radio button! Of cause I do!
        Hide
        Stan Silvert added a comment -

        I'd be interested to know if this workaround fixes the problem. Go to server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml. Set one or both of the validation properties to false:

        <bean name="TldParsingDeployer" class="org.jboss.deployment.TldParsingDeployer">
        <property name="relativeOrder">2002</property>
        <property name="useSchemaValidation">false</property>
        <property name="useValidation">false</property>
        </bean>

        Show
        Stan Silvert added a comment - I'd be interested to know if this workaround fixes the problem. Go to server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml. Set one or both of the validation properties to false: <bean name="TldParsingDeployer" class="org.jboss.deployment.TldParsingDeployer"> <property name="relativeOrder">2002</property> <property name="useSchemaValidation">false</property> <property name="useValidation">false</property> </bean>
        Hide
        Kennard Consulting added a comment - - edited

        Stan,

        Thanks for your time in looking at this.

        Your suggestion does not appear to have any effect. Even with both 'useSchemaValidation' and 'useValidation' set to false, the error is the same...

        Caused by: org.jboss.xb.binding.JBossXBRuntimeException: -1:-1 -1:-1 schema_reference.4: Failed to read schema document 'null', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.
        at org.jboss.xb.binding.sunday.unmarshalling.XsdBinderTerminatingErrorHandler.handleError(XsdBinderTerminatingErrorHandler.java:40) [jbossxb.jar:2.0.3.GA]
        at org.apache.xerces.impl.xs.XMLSchemaLoader.reportDOMFatalError(Unknown Source) [xercesImpl.jar:6.0.0.Final]
        at org.apache.xerces.impl.xs.XSLoaderImpl.load(Unknown Source) [xercesImpl.jar:6.0.0.Final]
        at org.jboss.xb.binding.Util.loadSchema(Util.java:394) [jbossxb.jar:2.0.3.GA]
        at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:178) [jbossxb.jar:2.0.3.GA]
        at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:149) [jbossxb.jar:2.0.3.GA]
        at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:342) [jbossxb.jar:2.0.3.GA]
        ... 72 more

        ...this is perhaps a little surprising, but maybe JBoss is trying to load the schema even though it doesn't intend to use it? If I remove the "TldParsingDeployer" bean altogether from war-deployers-jboss-beans.xml then there is no error (but presumably things will fail at a later stage).

        Regards,

        Richard.

        Show
        Kennard Consulting added a comment - - edited Stan, Thanks for your time in looking at this. Your suggestion does not appear to have any effect. Even with both 'useSchemaValidation' and 'useValidation' set to false, the error is the same... Caused by: org.jboss.xb.binding.JBossXBRuntimeException: -1:-1 -1:-1 schema_reference.4: Failed to read schema document 'null', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>. at org.jboss.xb.binding.sunday.unmarshalling.XsdBinderTerminatingErrorHandler.handleError(XsdBinderTerminatingErrorHandler.java:40) [jbossxb.jar:2.0.3.GA] at org.apache.xerces.impl.xs.XMLSchemaLoader.reportDOMFatalError(Unknown Source) [xercesImpl.jar:6.0.0.Final] at org.apache.xerces.impl.xs.XSLoaderImpl.load(Unknown Source) [xercesImpl.jar:6.0.0.Final] at org.jboss.xb.binding.Util.loadSchema(Util.java:394) [jbossxb.jar:2.0.3.GA] at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:178) [jbossxb.jar:2.0.3.GA] at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:149) [jbossxb.jar:2.0.3.GA] at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:342) [jbossxb.jar:2.0.3.GA] ... 72 more ...this is perhaps a little surprising, but maybe JBoss is trying to load the schema even though it doesn't intend to use it? If I remove the "TldParsingDeployer" bean altogether from war-deployers-jboss-beans.xml then there is no error (but presumably things will fail at a later stage). Regards, Richard.
        Hide
        Christian Kaltepoth added a comment -

        Here is a link to the JBoss issue that Stan created regarding this:

        https://issues.jboss.org/browse/JBAS-8800

        However, I think that this issue should also be fixed in the Trinidad/Tomahawk/Commons TLDs. It is undeniable that the current TLDs are not readable by a validating parser because they do not validate against the schema. And that is something that should be fixed for future versions.

        Show
        Christian Kaltepoth added a comment - Here is a link to the JBoss issue that Stan created regarding this: https://issues.jboss.org/browse/JBAS-8800 However, I think that this issue should also be fixed in the Trinidad/Tomahawk/Commons TLDs. It is undeniable that the current TLDs are not readable by a validating parser because they do not validate against the schema. And that is something that should be fixed for future versions.
        Hide
        Leonardo Uribe added a comment -

        Thanks to Christian Kaltepoth for provide this patch

        Show
        Leonardo Uribe added a comment - Thanks to Christian Kaltepoth for provide this patch

          People

          • Assignee:
            Leonardo Uribe
            Reporter:
            Kennard Consulting
          • Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1h
              1h
              Remaining:
              Remaining Estimate - 1h
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development