Problem handling absolute directory specs in classpath
adinn Jul 21, 2008 4:47 AMHi 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)