Bug 17871 - war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows
Summary: war task's webxml attrib no longer is able to use value with a starting backs...
Status: RESOLVED FIXED
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.5.2
Hardware: PC All
: P3 normal (vote)
Target Milestone: 1.5.3
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-03-11 12:53 UTC by Stoehr Sukachevin
Modified: 2005-03-20 17:06 UTC (History)
1 user (show)



Attachments
fixes the problem in War.java (945 bytes, patch)
2003-03-12 22:38 UTC, Antoine Levy-Lambert
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stoehr Sukachevin 2003-03-11 12:53:09 UTC
The "war" task's "webxml" attrib is no longer able to use a value with a 
starting backslash for the path in Windows.

For example, if the "webxml" attrib value is specified as "\test\web.xml", in 
previous releases (before v1.5.2 [like v1.5Beta]), the "war" task was able to 
interpret this as meaning that the "web.xml" file located in the "test" 
directory of the project's base drive should be used.

With the latest nightly build (and v1.5.2), the "war" task ignores the previous 
example "webxml" attrib.

(Note that other attribs of the "war" task like "destfile", "basedir", etc. are 
able to handle correctly values that start with "\".  Perhaps this is due to 
the fact that the "war" file subclasses the "zip" task.)
Comment 1 Stefan Bodewig 2003-03-12 16:26:35 UTC
Are you sure it gets ignored?  How do you check the resulting war archive?

WinZIP?  Does your web.xml show up if you run "jar tf" against the war file?

If you answer yes to the last two questions, please mark this bug as a duplicate
of bug 17648.
Comment 2 Stoehr Sukachevin 2003-03-12 16:45:27 UTC
I verified that it gets ignored.  I used both UnZip 5.41 and jar (JDK1.4.1_02) 
[both on Windows].

(Besides, when the "war" task runs, it just so happens that there is a "WEB-
INF/web.xml" file in the selected war files of the task, so the task 
displays "[war] Warning: selected war files include a WEB-INF/web.xml which 
will be ignored (please use webxml attribute to war task)" when the "webxml" 
attrib of the task has something like "\Xxx\Yyy\Zzz.xml" -- presumably because 
the task was not able to find "\Xxx\Yyy\Zzz.xml" to use as the "web.xml" file; 
but when the "webxml" attrib is "D:\Xxx\Yyy\Zzz.xml", then all is well.  Keep 
in mind that Ant is invoked on the Windows command line at the "D:" drive, the 
build file is also located on the "D:" drive, and all the files that the task 
uses are also on the "D:" drive.)

So I believe that this issue is NOT a duplicate of bug 17648.
Comment 3 Stefan Bodewig 2003-03-12 17:04:24 UTC
Hmm,

the main change is that the webxml attribute now uses <fileset>'s file
attribute internally.  I don't have Windows around, could you please try this
snippet and port the result?

<path id="foo">
  <fileset file="\Xxx\Yyy\Zzz.xml"/>
</path>
<property name="foo-as-prop" refid="foo"/>
<echo>${foo-as-prop}</echo>

and compare it to

<path id="foo">
  <fileset file="D:\Xxx\Yyy\Zzz.xml"/>
</path>
<property name="foo-as-prop" refid="foo"/>
<echo>${foo-as-prop}</echo>

they are supposed to echo the same file name.
Comment 4 Stoehr Sukachevin 2003-03-12 17:37:35 UTC
For the following "test" task:

--------

  <target name="test">
    <antcall target="test1" />
    <antcall target="test2" />
    <antcall target="test3" />
    <antcall target="test4" />
  </target>

  <target name="test1">
    <path id="foo">
      <fileset file="\Xxx\Yyy\Zzz.xml"/>
    </path>
    <property name="foo-as-prop" refid="foo"/>
    <echo>${foo-as-prop}</echo>
  </target>

  <target name="test2">
    <path id="foo">
      <fileset file="D:\Xxx\Yyy\Zzz.xml"/>
    </path>
    <property name="foo-as-prop" refid="foo"/>
    <echo>${foo-as-prop}</echo>
  </target>

  <target name="test3">
    <war destfile="\test3.war"
         webxml="\Xxx\Yyy\Zzz.xml">
    </war>
  </target>

  <target name="test4">
    <war destfile="\test4.war"
         webxml="D:\Xxx\Yyy\Zzz.xml">
    </war>
  </target>

--------


Here is the output:

--------

Buildfile: D:\Stoehr\cincro\src\build.xml

test:

test1:
     [echo] D:\Xxx\Yyy\Zzz.xml

test2:
     [echo] D:\Xxx\Yyy\Zzz.xml

test3:
      [war] Building war: D:\test3.war
      [war] Warning: selected war files include a WEB-INF/web.xml which will be 
ignored (please use webxml attribute to war task)

test4:
      [war] Building war: D:\test4.war

BUILD SUCCESSFUL
Total time: 1 second

--------
Comment 5 Stoehr Sukachevin 2003-03-12 17:48:26 UTC
One clarification about the "test3" and "test4" tasks are that there are no 
files to be included in the war file except for the "web.xml" file.  So it is 
weird to get the "war" warning for the "test3" task.

Also note that in both cases, the "destfile" attrib of the "war" task does not 
include the drive -- yet the "war" task was able to output both war files at 
the correct location.
Comment 6 Antoine Levy-Lambert 2003-03-12 22:28:42 UTC
I can confirm the existence of this bug.


I have done a test of this bug under Win2000 and  JDK 1.4.1_01-b01


I think I also have found the origin of this bug :


1)War.java#zipFile(File file, ZipOutputStream zOut, String vPath, 


                           int mode)


contains a line saying ... !deploymentDescriptor.equals(file) ...


in test3 deploymentDescriptor = \Xxx\Yyy\Zzz.xml


         file                 = D:\Xxx\Yyy\Zzz.xml


therefore War.java#zipFile refuses to include \Xxx\Yyy\Zzz.xml into the war file






2) AbstractFileSet.java does this


   public void setFile(File file) {


        ...


        setDir(fileUtils.getParentFile(file));


        ...


    }


getParentFile returns D:\Xxx\Yyy\ always, independently of whether file contains 
the drive specification or not




Comment 7 Antoine Levy-Lambert 2003-03-12 22:38:55 UTC
Created attachment 5298 [details]
fixes the problem in War.java
Comment 8 Stefan Bodewig 2003-03-13 08:54:40 UTC
Hmm,  I see.

I don't think using the canonical path is the correct solution (we'll technically
the solution is correct, but probably not in terms of how it should be
addressed in Ant).

deploymentDescriptor should probably get the drive letter added to it in the
first place - I'll look into it.
Comment 9 Stefan Bodewig 2003-03-13 16:25:08 UTC
Could you please either try the next nightly build (i.e. 2003-03-14) or replace
the 1.5.2 ant.jar with the one from <http://cvs.apache.org/~bodewig/ant.jar>
and see whether it fixes the problem?
Comment 10 Stoehr Sukachevin 2003-03-13 17:51:08 UTC
After deleting the "test?.war" files and re-running the "test" target with the 
http://cvs.apache.org/~bodewig/ant.jar JAR, it now appears that the "test3.war" 
file is generated with the appropriate "web.xml" file within it.

Thanks!
Comment 11 Stefan Bodewig 2003-03-14 15:15:59 UTC
Thanks.