Hi Yoav,
Thanks for responding. Please see my replies below:
On Today at 11:26am, YS=>Yoav Shapira <[EMAIL PROTECTED]> wrote:
YS> Hi,
YS> The reason your patch hasn't been applied yet (or at least, the reason
YS> I haven't applied it yet, and I have looked at it once your twice) is
YS> that I'm sure the copy operation you remove is really redundant in all
YS> cases.
YS>
Please read on, and I'll prove to you that the code in question is in fact
a mistake.
YS>
YS> The copy operation seems to have been added as part of revision 303270
YS> committed on Thu Sep 23 07:03:27 2004 UTC by Remy. It's been nearly a
YS> year and half since then, with no complaints about this code except
YS> yours, so it seems to work for the majority of users. Accordingly,
YS> before we go and apply your patch, we'd need to be convinced that it
YS> doesn't introduce a regression failure.
YS>
Let the convincing begin...
[If you want, we can take this offline and you can reply inside bugzilla
36847.]
The code in question pre-revision 303270 used to look like this:
// Copy WAR and XML to the host base
if (tag != null) {
deployedPath = deployed;
File localWarCopy = new File(deployedPath, basename + ".war");
copy(localWar, localWarCopy);
localWar = localWarCopy;
}
The code after revision 303270 looks like this:
// Copy WAR and XML to the host app base if needed
if (tag != null) {
deployedPath = deployed;
File localWarCopy = new File(deployedPath,
basename + ".war");
copy(localWar, localWarCopy);
localWar = localWarCopy;
copy(localWar, new File(getAppBase(), basename +
".war"));
}
Can we agree on the fact that there are 2 copy() methods inside the
if (tag != null) {} code snippet?
If that is indeed the case, then can we also agree that this code only
runs when tag is not null and any modifications to this code will *NOT*
effect anything else as long as tag is null?
Now onto more. I can confirm for you that the following code snippet
inside an ant file does *NOT* work.
<deploy url="http://localhost:8080/manager";
username="username_here"
password="password_here"
path="/myapp"
update="true"
tag="some-tag-here"
war="file:/path/to/war/myapp.war"/>
Just because no one else has complained about it (for a year or however
long) does not mean that the bug does not exist. In my case, I always
get a:
SEVERE: Exception fixing docBase: {0}
java.util.zip.ZipException: error in opening zip file
followed by:
SEVERE: Error starting static Resources
java.lang.IllegalArgumentException: Invalid or unreadable WAR file
: error in opening zip file
in catalina.out. And for more proof the webapps directory contains a 0
length .war file.
1) Do you yourself use remote war deployment while using tags using ant?
2) Have you tried the above ant code snippet (after cleaning up some of
the attributes)?
3) How can we ship a tomcat with a broken feature that no one has really
bothered to test? Perhaps, (after fixing this) the next step is to
write an automated test for this. Remember this used to work in 5.5.9.
Now, I'll explain why it fails:
Here's the sequence of events (my context is called sws):
1) context is undeployed
2) local war is uploaded to:
/www/apache-tomcat-5.5.16/work/Catalina/localhost/manager/some-tag-here/sws.war
3) First copy() method copies:
/www/apache-tomcat-5.5.16/work/Catalina/localhost/manager/some-tag-here/sws.war
to new File():
/www/tomcat/webapps/sws.war
We have a good copy at this moment in time.
3) Second copy() method copies:
/www/tomcat/webapps/sws.war
to new File():
/www/tomcat/webapps/sws.war
essentially resulting in a 0-length file. Can you see my pain at this
point? The code has basically guaranteed a 0-length file.
Why is step 3) even necessary?
Furthermore, I can confirm for you that taking out the offending lines,
makes remote war deployment via tags 100% successful for me.
YS> [..snip..]
YS>
Thanks for listening,
--
Haroon Rafique
<[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
