12 Replies Latest reply on Sep 15, 2010 11:46 PM by Mick H

    Problem deploying war file on JBoss AS6.0.0 M4

    Mick H Newbie

      Hi there,

       

      I am trying to deploy the blog engine pebble version 2.4 on JBoss AS6.0.0 M4.  I'm running on linux with java 1.6.0_20.  However when I copy the pebble.war file to the deploy directory I get the following at the console:

       

      11:29:32,050 WARN  [org.jboss.util.xml.JBossEntityResolver] Trying to resolve systemId as a non-file URL: http://java.sun.com/xml/ns/j2ee
      11:29:37,000 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Parse: name=vfs:///usr/share/jboss6/server/default/deploy/pebble.war state=PreParse mode=Manual requiredState=Parse: org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfs:///usr/share/jboss6/server/default/deploy/pebble.war
              at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) [:2.2.0.Alpha6]
              at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:383) [:2.2.0.Alpha6]
              at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:343) [:2.2.0.Alpha6]
              at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:315) [:2.2.0.Alpha6]
              at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.deploy(AbstractParsingDeployerWithOutput.java:255) [:2.2.0.Alpha6]
              at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha6]
              at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.Alpha6]
              at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.Alpha6]
              at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.Alpha6]
              at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
              at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
              at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
              at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
              at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
              at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
              at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.Alpha10]
              at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.Alpha10]
              at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.Alpha6]
              at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.Alpha6]
              at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.Alpha6]
              at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.20100721-M4]
              at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:130) [:0.1.0.Alpha1]
              at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.1.0.Alpha1]
              at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.1.0.Alpha1]
              at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:59) [:0.1.0.Alpha1]
              at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.1.0.Alpha1]
              at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:94) [:0.1.0.Alpha1]
              at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.1.0.Alpha1]
              at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.1.0.Alpha1]
              at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.1.0.Alpha1]
              at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.1.0.Alpha1]
              at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.1.0.Alpha1]
              at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.1.0.Alpha1]
              at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.1.0.Alpha1]
              at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_20]
              at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_20]
              at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_20]
              at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_20]
              at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0_20]
              at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [:1.6.0_20]
              at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
              at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
      Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Failed to parse schema for nsURI=http://java.sun.com/xml/ns/j2ee, baseURI=null, schemaLocation=null
              at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:195) [jbossxb.jar:2.0.2.Beta7]
              at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168) [jbossxb.jar:2.0.2.Beta7]
              at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:229) [jbossxb.jar:2.0.2.Beta7]
              at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:206) [jbossxb.jar:2.0.2.Beta7]
              at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:137) [:2.2.0.Alpha6]
              at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:64) [:6.0.0.20100721-M4]
              at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:38) [:6.0.0.20100721-M4]
              at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:121) [:2.2.0.Alpha6]
              at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.handleMultipleFiles(AbstractVFSParsingDeployer.java:446) [:2.2.0.Alpha6]
              at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:319) [:2.2.0.Alpha6]
              at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:376) [:2.2.0.Alpha6]
              ... 41 more
      Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to parse schema for nsURI=http://java.sun.com/xml/ns/j2ee, baseURI=null, schemaLocation=null
              at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:347) [jbossxb.jar:2.0.2.Beta7]
              at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:177) [jbossxb.jar:2.0.2.Beta7]
              at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.startElement(SaxJBossXBParser.java:370) [jbossxb.jar:2.0.2.Beta7]
              at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:191) [jbossxb.jar:2.0.2.Beta7]
              ... 51 more
      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.2.Beta7]
              at org.apache.xerces.impl.xs.XMLSchemaLoader.reportDOMFatalError(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.apache.xerces.impl.xs.XSLoaderImpl.load(Unknown Source) [xercesImpl.jar:6.0.0.20100721-M4]
              at org.jboss.xb.binding.Util.loadSchema(Util.java:394) [jbossxb.jar:2.0.2.Beta7]
              at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:178) [jbossxb.jar:2.0.2.Beta7]
              at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:149) [jbossxb.jar:2.0.2.Beta7]
              at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:339) [jbossxb.jar:2.0.2.Beta7]
              ... 66 more

       

      It appears to be choking on the schemaLocation in the web.xml file, but it looks OK to me:

       

      <?xml version="1.0" encoding="ISO-8859-1"?>


      <web-app version="2.4"

          xmlns="http://java.sun.com/xml/ns/j2ee"

          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

          xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">


        <display-name>Pebble</display-name>

        <description>My blog, powered by Pebble</description>


        <context-param>

          <param-name>contextConfigLocation</param-name>

          <param-value>

            /WEB-INF/applicationContext-acegi-security.xml

            /WEB-INF/applicationContext-xmlrpc.xml

            /WEB-INF/applicationContext-pebble.xml

          </param-value>

        </context-param>


        <jsp-config>

          <jsp-property-group>

            <url-pattern>*.jsp</url-pattern>

            <scripting-invalid>true</scripting-invalid>

            <include-prelude>/WEB-INF/fragments/prelude.jspf</include-prelude>

            <include-coda>/WEB-INF/fragments/coda.jspf</include-coda>

          </jsp-property-group>


          <jsp-property-group>

            <url-pattern>*.xml</url-pattern>

            <scripting-invalid>true</scripting-invalid>

            <include-prelude>/WEB-INF/xml/prelude.jspf</include-prelude>

            <include-prelude>/WEB-INF/xml/coda.jspf</include-prelude>

          </jsp-property-group>


          <jsp-property-group>

            <url-pattern>*.txt</url-pattern>

            <scripting-invalid>true</scripting-invalid>

          </jsp-property-group>

        </jsp-config>


        <filter>

          <filter-name>BlogLookupFilter</filter-name>

          <filter-class>net.sourceforge.pebble.web.filter.BlogLookupFilter</filter-class>

        </filter>


        <filter>

          <filter-name>TransformingFilter</filter-name>

          <filter-class>net.sourceforge.pebble.web.filter.TransformingFilter</filter-class>

        </filter>


        <filter>

          <filter-name>Acegi Filter Chain Proxy</filter-name>

          <filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>

          <init-param>

            <param-name>targetClass</param-name>

            <param-value>org.acegisecurity.util.FilterChainProxy</param-value>

          </init-param>

        </filter>


        <filter>

          <filter-name>PreProcessingFilter</filter-name>

          <filter-class>net.sourceforge.pebble.web.filter.PreProcessingFilter</filter-class>

        </filter>


        <filter>

          <filter-name>DispatchingFilter</filter-name>

          <filter-class>net.sourceforge.pebble.web.filter.DispatchingFilter</filter-class>

        </filter>


        <filter>

          <filter-name>GZIPFilter</filter-name>

          <filter-class>net.sourceforge.pebble.web.filter.GZIPFilter</filter-class>

        </filter>


        <filter-mapping>

          <filter-name>GZIPFilter</filter-name>

          <url-pattern>*.html</url-pattern>

          <dispatcher>REQUEST</dispatcher>

        </filter-mapping>


        <filter-mapping>

          <filter-name>GZIPFilter</filter-name>

          <url-pattern>*.js</url-pattern>

          <dispatcher>REQUEST</dispatcher>

        </filter-mapping>


        <filter-mapping>

          <filter-name>GZIPFilter</filter-name>

          <url-pattern>*.css</url-pattern>

          <dispatcher>REQUEST</dispatcher>

        </filter-mapping>


        <filter-mapping>

          <filter-name>BlogLookupFilter</filter-name>

          <url-pattern>/*</url-pattern>

          <dispatcher>REQUEST</dispatcher>

        </filter-mapping>


        <filter-mapping>

          <filter-name>TransformingFilter</filter-name>

          <url-pattern>/*</url-pattern>

          <dispatcher>REQUEST</dispatcher>

        </filter-mapping>


        <filter-mapping>

          <filter-name>Acegi Filter Chain Proxy</filter-name>

          <url-pattern>/*</url-pattern>

          <dispatcher>REQUEST</dispatcher>

        </filter-mapping>


        <filter-mapping>

          <filter-name>PreProcessingFilter</filter-name>

          <url-pattern>/*</url-pattern>

          <dispatcher>REQUEST</dispatcher>

        </filter-mapping>


        <filter-mapping>

          <filter-name>DispatchingFilter</filter-name>

          <url-pattern>/*</url-pattern>

          <dispatcher>REQUEST</dispatcher>

        </filter-mapping>


        <listener>

          <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>

        </listener>


        <listener>

          <listener-class>net.sourceforge.pebble.web.listener.PebbleContextListener</listener-class>

        </listener>


        <listener>

          <listener-class>net.sourceforge.pebble.aggregator.NewsFeedContextListener</listener-class>

        </listener>


        <servlet>

          <servlet-name>HttpController</servlet-name>

          <servlet-class>net.sourceforge.pebble.web.controller.HttpController</servlet-class>


          <init-param>

            <param-name>actions</param-name>

            <param-value>action.properties</param-value>

          </init-param>


          <init-param>

            <param-name>actionExtension</param-name>

            <param-value>.action</param-value>

          </init-param>

        </servlet>


        <servlet>

          <servlet-name>SecureController</servlet-name>

          <servlet-class>net.sourceforge.pebble.web.controller.HttpController</servlet-class>


          <init-param>

            <param-name>actions</param-name>

            <param-value>secure-action.properties</param-value>

          </init-param>


          <init-param>

            <param-name>actionExtension</param-name>

            <param-value>.secureaction</param-value>

          </init-param>

        </servlet>


        <servlet>

          <servlet-name>XmlRpcController</servlet-name>

          <servlet-class>net.sourceforge.pebble.web.controller.XmlRpcController</servlet-class>

        </servlet>


        <servlet>

          <servlet-name>index.jsp</servlet-name>

          <jsp-file>/index.jsp</jsp-file>

        </servlet>


        <servlet>

          <servlet-name>jcaptcha</servlet-name>

          <servlet-class>net.sourceforge.pebble.confirmation.ImageCaptchaServlet</servlet-class>

          <load-on-startup>0</load-on-startup>

        </servlet>


        <servlet>

          <servlet-name>dwr-invoker</servlet-name>

          <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>

          <init-param>

            <param-name>debug</param-name>

            <param-value>true</param-value>

          </init-param>

          <init-param>

            <param-name>allowGetForSafariButMakeForgeryEasier</param-name>

            <param-value>true</param-value>

          </init-param>

          <load-on-startup>1</load-on-startup>

        </servlet>


        <servlet-mapping>

          <servlet-name>dwr-invoker</servlet-name>

          <url-pattern>/dwr/*</url-pattern>

        </servlet-mapping>


        <servlet-mapping>

          <servlet-name>HttpController</servlet-name>

          <url-pattern>*.action</url-pattern>

        </servlet-mapping>


        <servlet-mapping>

          <servlet-name>SecureController</servlet-name>

          <url-pattern>*.secureaction</url-pattern>

        </servlet-mapping>


        <servlet-mapping>

          <servlet-name>XmlRpcController</servlet-name>

          <url-pattern>/xmlrpc/*</url-pattern>

        </servlet-mapping>


        <servlet-mapping>

          <servlet-name>index.jsp</servlet-name>

          <url-pattern>/index.html</url-pattern>

        </servlet-mapping>


        <servlet-mapping>

          <servlet-name>jcaptcha</servlet-name>

          <url-pattern>/jcaptcha</url-pattern>

        </servlet-mapping>


        <session-config>

          <session-timeout>60</session-timeout>

        </session-config>


        <welcome-file-list>

          <welcome-file>index.jsp</welcome-file>

          <welcome-file>index.html</welcome-file>

        </welcome-file-list>


        <!--

        <error-page>

          <error-code>401</error-code>

          <location>/401.action</location>

        </error-page>

        -->


        <error-page>

          <error-code>403</error-code>

          <location>/403.action</location>

        </error-page>


        <error-page>

          <error-code>404</error-code>

          <location>/404.action</location>

        </error-page>


        <error-page>

          <error-code>500</error-code>

          <location>/error.action</location>

        </error-page>


        <error-page>

          <exception-type>java.lang.Exception</exception-type>

          <location>/error.action</location>

        </error-page>


        <!-- uncomment this if you would like to use a JNDI-based JavaMail Session

        -->

        <resource-ref>

          <description>

            Resource reference to a factory for javax.mail.Session

            instances that may be used for sending e-mail notifications.

          </description>

          <res-ref-name>mail/Session</res-ref-name>

          <res-type>javax.mail.Session</res-type>

          <res-auth>Container</res-auth>

        </resource-ref>


      </web-app>

       

      Any help much appreciated.

       

      Mick

       

      Message was edited by: Mick Heywood

        • 1. Re: Problem deploying war file on JBoss AS6.0.0 M4
          Wolfgang Knauf Master

          Hi,

           

          I pasted your web.xml in an Eclipse project, and I saw only a warning, but no validation error:

           

          CHKJ4019W: Invalid res-sharing-scope; valid values are "Shareable" or "Unshareable".

           

          See e.g. this for a fix: http://webdeveloperlogbook.blogspot.com/2009/04/webxml-warning-chkj4019w-invalid-res.html

           

          Hopefully this helps.

           

          Are you sure that "web.xml" is the root cause? Maybe the error is from a "jboss-web.xml"?

           

          Best regards

           

          Wolfgang

          • 2. Re: Problem deploying war file on JBoss AS6.0.0 M4
            Mick H Newbie

            Wolfgang,

             

            Thanks for responding.  I tried implementing that fix you referenced but it made no difference.  The errors being thrown are the same as they originally were.

             

            I have searched the content of the war file for other references to http://java.sun.com/xml/ns/j2ee but I couldn't find any.  It really does look like it's failing to handle the xsi:schemaLocation attribute, but this is such a basic xml schema feature and it appears to be perfectly correct.  Very frustrating...

             

            Mick

            • 3. Re: Problem deploying war file on JBoss AS6.0.0 M4
              jaikiran pai Master

              This weekend, I investigated to see what was wrong and it appeared to be related more to JBossXB than anything to do with your application. It however is triggered by a xsd which doesn't have a schema location. I'll rerun the app today and get the logs to show what I mean.

              • 4. Re: Problem deploying war file on JBoss AS6.0.0 M4
                jaikiran pai Master

                jaikiran pai wrote:

                 

                This weekend, I investigated to see what was wrong and it appeared to be related more to JBossXB than anything to do with your application. It however is triggered by a xsd which doesn't have a schema location. I'll rerun the app today and get the logs to show what I mean.

                I was a bit wrong there. Looking at the logs, I had thought it was a JBossXB issue, but now I'm not sure (read the next paragraph to understand why). Anyway, the issue is that the pebble.war ships with a url.tld in pebble.war/WEB-INF folder which looks like:

                 

                <taglib xmlns="http://java.sun.com/xml/ns/j2ee" version="2.0">  
                <tlib-version>1.0</tlib-version>  
                <short-name>url</short-name>  
                <uri>http://pebble.sourceforge.net/tags/url.tld</uri> 
                    <function>
                        <name>rewrite</name>
                        <function-class>net.sourceforge.pebble.web.tagext.UrlFunctions</function-class>
                        <function-signature>java.lang.String rewrite(java.lang.String)</function-signature>
                    </function> 
                    <function>
                        <name>escape</name>
                        <function-class>net.sourceforge.pebble.web.tagext.UrlFunctions</function-class>
                        <function-signature>java.lang.String escape(java.lang.String)</function-signature>
                    </function> 
                </taglib>

                 

                As can be seen, the schemaLocation is missing for that tld, which causes this issue. Fixing that url.tld to:

                 

                <taglib xmlns="http://java.sun.com/xml/ns/j2ee" version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
                 http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd">  
                <tlib-version>1.0</tlib-version>  
                <short-name>url</short-name>  
                <uri>http://pebble.sourceforge.net/tags/url.tld</uri> 
                    <function>
                        <name>rewrite</name>
                        <function-class>net.sourceforge.pebble.web.tagext.UrlFunctions</function-class>
                        <function-signature>java.lang.String rewrite(java.lang.String)</function-signature>
                    </function> 
                    <function>
                        <name>escape</name>
                        <function-class>net.sourceforge.pebble.web.tagext.UrlFunctions</function-class>
                        <function-signature>java.lang.String escape(java.lang.String)</function-signature>
                    </function> 
                </taglib>

                 

                should get you past the issue.

                 

                Now the reasons why I think this is a problem in JBossXB is:

                 

                1) The error message does not print the file which causes this issue. There's a JIRA which was created to report the file name https://jira.jboss.org/jira/browse/JBXB-246. I'll have to check if that made it to AS trunk.

                 

                2) From what I have read, the schemaLocation is just a hint. So the absence of that shouldn't really be an issue. But I guess, there isn't enough information to fall back on in the absence of the schemaLocation which causes this issue.

                 

                3) I guess, this JIRA https://jira.jboss.org/browse/JBAS-8268 would be helpful for issues like this

                1 of 1 people found this helpful
                • 5. Re: Problem deploying war file on JBoss AS6.0.0 M4
                  jaikiran pai Master

                  jaikiran pai wrote:

                   


                   

                  1) The error message does not print the file which causes this issue. There's a JIRA which was created to report the file name https://jira.jboss.org/jira/browse/JBXB-246. I'll have to check if that made it to AS trunk.

                   

                  That hasn't yet made to AS trunk. But I just built it manually and tried it against the AS and this failing deployment. The good news is that the error is now more explicit (it contains the exact file and line number information):

                   

                  Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: vfs:///home/me/jboss-6.0.0.M4/server/default/deploy/dummy.war/WEB-INF/url.tld@1,63
                      at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:224) [jbossxb.jar:2.0.2-SNAPSHOT]
                      at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:178) [jbossxb.jar:2.0.2-SNAPSHOT]
                      at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:231) [jbossxb.jar:2.0.2-SNAPSHOT]
                      at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:206) [jbossxb.jar:2.0.2-SNAPSHOT]
                      at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:137) [:2.2.0.Alpha6]
                      at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:64) [:6.0.0.20100721-M4]
                      at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:38) [:6.0.0.20100721-M4]
                      at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:121) [:2.2.0.Alpha6]
                      at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.handleMultipleFiles(AbstractVFSParsingDeployer.java:446) [:2.2.0.Alpha6]
                  • 6. Re: Problem deploying war file on JBoss AS6.0.0 M4
                    Mick H Newbie

                    Jaikiran,

                     

                    Thanks for looking at this.  Everything you've said sounds correct, and when I get a moment I'll fix up that tld file and deploy.  The correction to show the file causing the problem would be a big step forward.

                     

                    I guess the real question is whether this is required.  The war file deploys on Glassfish without (noticeable) problems.  I dereferenced the URI in question and it returns a web page which describes the different XSD's available at that location, which is obviously useless to the parser.  I wonder whether Glassfish just doesn't bother validating the file when there isn't a useable schemaLocation, and it probably then becomes a question of what does the spec say?

                     

                    UPDATE: I tried updating the tld file, and it didn't work.  The pertinent entries in the log seem to be:

                     

                    Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Failed to resolve global element {http://java.sun.com/xml/ns/j2ee}taglib

                    Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve global element {http://java.sun.com/xml/ns/j2ee}taglib

                    DEPLOYMENTS IN ERROR:
                      Deployment "vfs:///usr/share/jboss6/server/paddy/deploy/pebble.war" is in error due to the following reason(s): org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve global element {http://java.sun.com/xml/ns/j2ee}taglib

                     

                    I had amended the opening tag to be:

                     

                    <taglib xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                        xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd" version="2.0">

                    • 7. Re: Problem deploying war file on JBoss AS6.0.0 M4
                      jaikiran pai Master

                      Mick H wrote:

                       


                      I guess the real question is whether this is required.  The war file deploys on Glassfish without (noticeable) problems.  I dereferenced the URI in question and it returns a web page which describes the different XSD's available at that location, which is obviously useless to the parser.  I wonder whether Glassfish just doesn't bother validating the file when there isn't a useable schemaLocation, and it probably then becomes a question of what does the spec say?

                       

                      JBoss AS much stricter in xml validations. The spec (AFAIK) doesn't say anything about how strict the schema validations should be

                       

                      Mick H wrote:

                       


                       

                      UPDATE: I tried updating the tld file, and it didn't work.  The pertinent entries in the log seem to be:

                       

                      Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Failed to resolve global element {http://java.sun.com/xml/ns/j2ee}taglib

                      Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve global element {http://java.sun.com/xml/ns/j2ee}taglib

                      DEPLOYMENTS IN ERROR:
                        Deployment "vfs:///usr/share/jboss6/server/paddy/deploy/pebble.war" is in error due to the following reason(s): org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve global element {http://java.sun.com/xml/ns/j2ee}taglib

                       

                      I had amended the opening tag to be:

                       

                      <taglib xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                          xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd" version="2.0">

                       

                      Are you sure it's failing for this file and not something else? Also are you sure nothing else crept in when you changed that file? I don't see anything that looks wrong with that change.

                      • 8. Re: Problem deploying war file on JBoss AS6.0.0 M4
                        Mick H Newbie

                        jaikiran pai wrote:

                         

                        Are you sure it's failing for this file and not something else? Also are you sure nothing else crept in when you changed that file? I don't see anything that looks wrong with that change.

                        Well not 100%, but grep says no other file (besides web.xml) refers to that namespace.  The tld file is included in a stack of other files including other taglib files but none of them reference that namespace directly.  Very strange.  I didn't change any other files.

                        • 9. Re: Problem deploying war file on JBoss AS6.0.0 M4
                          Mick H Newbie

                          It deploys without a problem on tomcat 6.  This is annoying - I want the flexibility and extensibility of a full J2EE stack, but Glassfish brings my server to its knees and JBoss chokes on a seemingly innocuous artifact that tomcat and Glassfish swallow without a murmur.  I guess I'll just have to wait and see if this is ironed out in a couple of versions.

                          • 10. Re: Problem deploying war file on JBoss AS6.0.0 M4
                            jaikiran pai Master

                            Can you attach the modified war which fails to deploy on M4?

                            • 11. Re: Problem deploying war file on JBoss AS6.0.0 M4
                              Rob Breault Newbie

                              Has anyone found a solution or fix for this as we are running into the same issue. Our application deploy's fine in glassfish but doesn't deploy in Jboss 6 ( ie same issues as stated above )

                              • 12. Re: Problem deploying war file on JBoss AS6.0.0 M4
                                Mick H Newbie

                                jaikiran pai wrote:

                                 

                                Can you attach the modified war which fails to deploy on M4?

                                It was just over 15MB so I had to split it.