JBoss uses the last modified time on the file.
The OS typically sets this when you start copying
rather than when it finishes.
The move is an atomic process (provided the source
and destination are in the same file sytem)
so you will never have problems with that.
We ARE having problems with it. The source and destination file systems aren't necessarily within the same national boundaries. Our deployment process would ideally ftp the file directly into the deploy directory from the build system, and it sometimes takes a long time relative to the polling times. We aren't using an atomic move, in other words, and the transfer time can be very long if we're going through a VPN.
I have had the problems deploying from windows to linux. I would suggest using your build to upload it to another directory and then do a copy
That's what we do now, but our customers don't always give us access for a remote login session. The whole point of this thread is to find an alternative to this. If JBoss wouldn't be so enthusiastic about deploying something before it gets there, then we could ftp directly to the deploy directory.
The way it is now, we have to get the file to a staging directory on the remote host, then get a remote login session and move the file from the staging directory over to the deploy directory. For customers who won't give remote access, that means calling or emailing their IT department to ask somebody to do that for us. In one case, this means that we get on their schedule and, when they get around to it, they'll send somebody over. So far, there hasn't been a response time of less than a day.
It would seem to me that ours wouldn't be the only company having this issue. Automatic deployments would be much, much more automatic if JBoss could tell if the file weren't there yet. Maybe watch the file size and expect it to be constant for a certain number of seconds before deploying?
Add a custom deployer to Jboss that scans a directory that you create that contains your app (.ear I assume). Set the scan interval to some very high number like 2000000000. I did not look but maybe -1 says never scan. At any rate the very high scan interval will prevent the ear being deployed while it is being copied. After the file has arrived completely, use the JMX console to force a directory scan of your custom deployer and hence a re-deployment of your app.
Rename your ear to some .ear.tmp and ftp it to the deploy dir. Once its deployed, rename it to .ear which would take no more than a few milliseconds.