5 Replies Latest reply on Jul 23, 2008 7:27 AM by alesj

    Problem handling absolute directory specs in classpath

    adinn

      Hi guys. I've found another small deployer issue to do with class paths in war files. The XTS demo program included a manifest whose classpath referred,inter alia, to /WEB-INF/classes. When this gets deployed it generates the following error display:

       at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
       at org.jboss.deployers.structure.spi.helpers.AbstractStructureBuilder.populateContext(AbstractStructureBuilder.java:144)
       at org.jboss.deployers.structure.spi.helpers.AbstractStructureBuilder.populateContext(AbstractStructureBuilder.java:83)
       at org.jboss.deployers.structure.spi.helpers.AbstractStructuralDeployers.determineStructure(AbstractStructuralDeployers.java:89)
       at org.jboss.deployers.plugins.main.MainDeployerImpl.determineStructure(MainDeployerImpl.java:845)
       at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:303)
       at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:260)
       at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:267)
       at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221)
       at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
       at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
       at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
       at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65)
       at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142)
       at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166)
       at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
       at java.lang.Thread.run(Thread.java:595)
      Caused by: java.lang.IllegalArgumentException: A path element is empty: xts-demo.ear//WEB-INF/classes
       at org.jboss.virtual.plugins.vfs.helpers.PathTokenizer.getTokens(PathTokenizer.java:106)
       at org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:475)
       at org.jboss.virtual.plugins.context.file.FileHandler.getChild(FileHandler.java:233)
       at org.jboss.virtual.plugins.context.AbstractVFSContext.getChild(AbstractVFSContext.java:164)
       at org.jboss.virtual.VFS.getChild(VFS.java:228)
       at org.jboss.virtual.VFSUtils.addManifestLocations(VFSUtils.java:200)
       at org.jboss.deployers.vfs.plugins.structure.VFSStructureBuilder.applyContextInfo(VFSStructureBuilder.java:217)
       at org.jboss.deployers.structure.spi.helpers.AbstractStructureBuilder.populateContext(AbstractStructureBuilder.java:130)
       ... 16 more
      


      After debugging the problem it appears that PathTokenizer.getTokens is being passed a VFS file name of the form
       .../xts-demo.ear//WEB-INF/classes
      


      When it conjures up the vfs file name the classpath generator code carefully adds a trailing slash after the .ear file name and then checks for a trailing slash on the manifest class path element. However, it does not check to see if the manifest class path element has a leading slash -- hence the double slash and the claim that a 'path element is empty'.

      The problem goes away if either i) the manifest entry is changed to WEB-INF.classes or ii) the manifest entry is removed (I know it's redundant but presumably this problem will affect anyone who employs a different absolute path)


        • 1. Re: Problem handling absolute directory specs in classpath
          dmlloyd

          In UNIX-land at least, multiple / are always considered to be equivalent to a single /. In my opinion, the path tokenizer ought to do the same.

          • 2. Re: Problem handling absolute directory specs in classpath
            adinn

             


            In UNIX-land at least, multiple / are always considered to be equivalent to a single /. In my opinion, the path tokenizer ought to do the same.


            I'm almost agnostic on the issue in this particular case because it's purely an internal matter. The 'problem' as it manifests here is one of our own construction. We generate the vfs handles from known components and one of those is a prefix encoding the war/ear name which ends in something of the form ...xxx.ear/ and the other is a manifest Class-Path entry which is either of the form /yyy/zzz or of the form yyy/zzz. The priority here is to honour the fact that either format used to work with the previous loader by making the current one compatible.

            We could achieve this either by constructing something the current tokenizer will eat (i.e. removing any repeated slash) or by making it less picky. However, I would assume that we are not at liberty to define the format of the trailing component. If we let the tokenizer elide all repeated slashes this would make it accept manifest Class-Path entries which had previously been rejected. I don't think we should break any existing standard (whether de jure or de facto) unless we really need to.

            • 3. Re: Problem handling absolute directory specs in classpath
              starksm64

               

              "adinn" wrote:
              However, I would assume that we are not at liberty to define the format of the trailing component. If we let the tokenizer elide all repeated slashes this would make it accept manifest Class-Path entries which had previously been rejected. I don't think we should break any existing standard (whether de jure or de facto) unless we really need to.

              Right, a uri with a trailing '/' indicates a directory and needs to be reflected in the vfs names. There is no such thing as an empty, nameless directory in the vfs so repeated '/' should be collapsed into a single '/' by the tokenizer. Create a JBVFS issue if you can, currently I can't get in.

              • 4. Re: Problem handling absolute directory specs in classpath
                alesj

                 

                "scott.stark@jboss.org" wrote:

                Create a JBVFS issue if you can, currently I can't get in.

                https://jira.jboss.org/jira/browse/JBVFS-47

                • 5. Re: Problem handling absolute directory specs in classpath
                  alesj

                   

                  "scott.stark@jboss.org" wrote:

                  Right, a uri with a trailing '/' indicates a directory and needs to be reflected in the vfs names.

                  How to handle this then:
                  - https://jira.jboss.org/jira/browse/JBAS-5796

                  Who sets the string roots in that case?
                  If it's user, then I would consider this being his problem.
                  If it's us, then we need to do something about it. :-)

                  But since it's URI issue, how come sothing similar didn't pop-up before?

                  "alesj" wrote:

                  https://jira.jboss.org/jira/browse/JBVFS-47

                  This is now fixed.