The solution to this problem is to make the ear/war "creation" as atomic
and quick as possible. One method would be to change your ant <jar> task
to produce the file under a temporary name, and have a subsequent <move>
task in the same target to rename it to the actual ear/war file. This is
atomic on most OSs and should solve the problem.
Cheers,
Dan.
At 15:32 09/03/2001 -0500, you wrote:
>[Randahl Fink Isaksen]
> > I am wondering if I am the the only one getting an error when deploying a
> > new .ear (this happens often but not always):
> >
> > Auto-unpacking C:\(...)\project.ear... Error unpacking: IO Error: error in
> > opening
> > zip file
> >
> > Does anybody know why this happens, and is there a work-around apart from
> > restarting Orion?
>
>I've seen this mainly when Orion doesn't wait long enough and tries
>to open an .ear file before it's fully copied-over from another
>location. The quick fix is to re-try the transfer. It's not an
>"easy" problem per-se, but polling on file size when the time/date stamp
>changes and extracing when the filesize is the same (and is non-zero)
>for 2 consecutive checks is a method I used to use that worked well.
>
>Yes, it's a heuristic.
>
>But, yes, it's better than what's there now :)
>
>For "most" people, the transfer is fast enough once you're overwriting
>the .ear to where it's not a big deal. You can workaround by transferring
>into a tmp file and doing a rename (or 2 renames, at most)
>
>How to treat this can lead to a religious war, which is why I've kept
>from bringing it up in the past.
>
>James
>--
>James Manning <[EMAIL PROTECTED]>
>GPG Key fingerprint = B913 2FBD 14A9 CE18 B2B7 9C8E A0BF B026 EEBB F6E4
--
Dan North
VP Development - Cadrion Software Ltd - +44 (0)20 7440 9550
CONFIDENTIALITY
This e-mail and any attachments are confidential
and may also be privileged. If you are not the named recipient,
please notify the sender immediately and do not disclose the
contents to another person, use it for any purpose, or store
or copy the information in any medium
