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

    Problem handling absolute directory specs in classpath

    Andrew Dinn Master

      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)