5 Replies Latest reply on Feb 27, 2018 1:07 AM by Sainath Machupalli

    Deployment throwing exception on upgrade to JBOSS EAP 7.1

    Sainath Machupalli Newbie

      Our deployment worked on EAP 7 and we started seeing the below exception when we upgraded to EAP 7.1.

       

      2018-02-07 09:19:46,234 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment inner.war

      2018-02-07 09:19:46,239 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."myEAR.ear"."inner.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "inner.war" of deployment "myEAR.ear"

      at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)

      at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)

      at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)

      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

      at java.lang.Thread.run(Thread.java:748)

      Caused by: java.lang.IllegalArgumentException: VFS000025: Given parent ("/content/myEAR.ear/inner.war") is not an ancestor of this virtual file

      at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:119)

      at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)

      at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)

      at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)

      at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)

      at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:125)

      at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:112)

      at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.createBeanArchiveId(BeanArchiveProcessor.java:348)

      at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.processResourceRoot(BeanArchiveProcessor.java:296)

      at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.handleResourceRoot(BeanArchiveProcessor.java:237)

      at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.access$100(BeanArchiveProcessor.java:206)

      at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor.deploy(BeanArchiveProcessor.java:113)

      at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)

      ... 5 more

       

      Our jboss-deployment-structure.xml is as below.

       

      <?xml version="1.0" encoding="UTF-8"?>

      <jboss-deployment-structure>

        <ear-subdeployments-isolated>false</ear-subdeployments-isolated>

         <sub-deployment name="inner.war">

             <dependencies>

            <module name="org.jboss.remote-naming"/>

             </dependencies>

         <resources>

        <resource-root path="APP-INF/lib/dep1.jar" />

        <resource-root path="APP-INF/lib/dep2.jar" />

      </resources>

        </sub-deployment>

      </jboss-deployment-structure>

       

      Our EAR structure is below,

      >myEAR.ear

           >inner.war

           >APP-INF

                >lib

                     >dep1.jar

                     >dep2.jar

           >META-INF

                >jboss-deployment-structure.xml

       

      The same structure and jboss-deployment-structure.xml worked for us on JBOSS EAP 7.

       

      Is there any change in deployment structure? or is it a BUG?

        • 1. Re: Deployment throwing exception on upgrade to JBOSS EAP 7.1
          Marcin Lewandowski Newbie

          Hi,

          have you identified the problem?

          I have a very similar exception, but i'm migrating from EAP6.4 -> EAP7.1:

          MSC000001: Failed to start service jboss.deployment.subunit."myEAR.ear"."inner.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."myEAR.ear"."inner.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "inner.jar" of deployment "myEAR.ear"

              at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) [wildfly-server-3.0.10.Final-redhat-1.jar:3.0.10.Final-redhat-1]

              at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]

              at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]

              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_152]

              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_152]

              at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_152]

          Caused by: java.lang.IllegalArgumentException: VFS000023: Given parent ("/content/myEAR.ear/inner.jar") is not an ancestor of this virtual file

              at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:118) [jboss-vfs-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]

              at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:124) [jboss-vfs-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]

              at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:124) [jboss-vfs-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]

              at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:124) [jboss-vfs-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]

              at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:112) [jboss-vfs-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]

              at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.createBeanArchiveId(BeanArchiveProcessor.java:348)

              at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.processResourceRoot(BeanArchiveProcessor.java:296)

              at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.handleResourceRoot(BeanArchiveProcessor.java:237)

              at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.access$100(BeanArchiveProcessor.java:206)

              at org.jboss.as.weld.deployment.processors.BeanArchiveProcessor.deploy(BeanArchiveProcessor.java:113)

              at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) [wildfly-server-3.0.10.Final-redhat-1.jar:3.0.10.Final-redhat-1]

              ... 5 more

          • 2. Re: Deployment throwing exception on upgrade to JBOSS EAP 7.1
            Frank Langelage Master

            Some remarks from my side to try:

            - in case of an ear file as deployment unit, jboss-deployment-structure.xml should be in META-INF not in WEB-INF

            - you could add an application.xml file to META-INF folder, containing

                 - <module><web><web-uri>inner.war</web-uri><context-root>...</context-root></web></module>

                 - <library-directory>lib</library-directory> for naming your lib directory. Put your jar files there. Remove <resource-root path="APP-INF/lib/dep[12].jar" /> from jboss-deployment-structure.xml

            • 3. Re: Deployment throwing exception on upgrade to JBOSS EAP 7.1
              Marcin Lewandowski Newbie

              I was able to make it work.

              my jboss-deployment-structure.xml looked like this:

              <?xml version="1.0" encoding="UTF-8"?>

              <jboss-deployment-structure>

                  <ear-subdeployments-isolated>false</ear-subdeployments-isolated>

                  <deployment>

                      <dependencies>

                          <module />

                          ...

                      </dependencies>

                      <exclusions>

                          <module  />

                         ...

                      </exclusions>

                  </deployment>

                  <sub-deployment name="1.jar">

                      <exclusions>

                          <module />

                          ...

                      </exclusions>

                      <resources>

                          <resource-root path="1.jar" />

                          <resource-root path="2.jar" />

                          <resource-root path="3.jar" />

                          <resource-root path="4.jar" />

                      </resources>

                  </sub-deployment>

                  <sub-deployment name="2.war">

                      <exclusions>

                          <module />

                          ...

                      </exclusions>

                  </sub-deployment>

                  <sub-deployment name="3.war">

                      <exclusions>

                          <module />

                          ...

                      </exclusions>

                  </sub-deployment>

              </jboss-deployment-structure>

               

              I made a module from the 4 jars and added it as an dependency:

              <?xml version="1.0" encoding="UTF-8"?>

              <jboss-deployment-structure>

                  <ear-subdeployments-isolated>false</ear-subdeployments-isolated>

                  <deployment>

                      <dependencies>

                          <module />

                          ...

                      </dependencies>

                      <exclusions>

                          <module  />

                         ...

                      </exclusions>

                  </deployment>

                  <sub-deployment name="1.jar">

                      <exclusions>

                          <module />

                          ...

                      </exclusions>

                        <dependencies>

                          <module name="deployment.server" />

                      </dependencies>

                  </sub-deployment>

                  <sub-deployment name="2.war">

                      <exclusions>

                          <module />

                          ...

                      </exclusions>

                  </sub-deployment>

                  <sub-deployment name="3.war">

                      <exclusions>

                          <module />

                          ...

                      </exclusions>

                  </sub-deployment>

              <module name="deployment.server" >

                  <resources>

                      <resource-root path="1.jar" />

                      <resource-root path="2.jar" />

                      <resource-root path="3.jar" />

                      <resource-root path="4.jar" />

                  </resources>

              </module>

              </jboss-deployment-structure>

               

              I hope it helps someone.

              1 of 1 people found this helpful
              • 4. Re: Deployment throwing exception on upgrade to JBOSS EAP 7.1
                jaikiran pai Master

                Given that this used to work previously and also from what I see in the example jboss-deployment-structure.xml files posted so far, this might be a bug in WildFly. Could either of you please open a JIRA here - JBoss Issue Tracker  and attach a sample application to reproduce this? Please also link to this thread as reference. Someone might be able to confirm whether this is an expected change in behaviour between these versions (in which case a better exception would have to be thrown instead).