Hi,
I also had the same problem while updating our .ear files. It seems that
the server shouldn't be that "fast" in detecting a new version, then
trying to upgrade. IMO, it would be nice if the server waited some
interval and then checked again to see if the file is "stable" before
trying to upgrade it. I don't think waiting for a couple of seconds
would be that bad, and then hot deployment would be more robust. Right
now, you have to play dirty tricks as using touch or copying the file
with another name and then remove the old/change the name in a single
command line.
Just my 2c,
Dan
Simon Knott wrote:
>
> A quicker fix for the deployment problem you are having (as in the error
> with the zip file), is to put a 'touch' task into your ant script.
>
> As far as I can assertain, the error is caused when the ear file gets fairly
> large. When you copy a new ear file over the old one, while the server is
> still running, it seems that the server detects the new version of the ear
> file before the file has fully copied. It tries to deploy the semi-copied
> ear file, and therefore thinks that the zip file is corrupt. If you then
> touch the ear file (as in update it's timestamp), then orion will then try
> unpacking it again, and since the ear file has now fully copied, will work
> correctly. Ant comes with an in-built touch task, and it's solved our
> deployment problems here.
>
> Cheers,
> Simon Knott
>
....
