If you're on Linux, you shouldn't be using "cp" to create the deployment
jar, you should use the "mv" command. If you're using ftp to upload the
file, upload it to a non-jar resource, and then use the "rename" command to
move it to its final location. This is typical under any Unix for almost
any file creation of a file that could be in use (or have an attempted use)
at the time you're creating the file. First, you copy the file onto the
same device ("same device" is important!), then you execute an "mv" command,
which is pretty much an atomic operation if the source and destination are
on the same device.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David
> Green
> Sent: Thursday, June 28, 2001 8:08 AM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] Auto-Deploy
>
>
>
> The auto-deploy feature is awesome. However, it starts unzipping my files
> before I even finish copying them...
>
> Fortunately, Linux keeps updating the timestamp on the file during the
> process of being copied, so it usually tries again and again. Sometimes,
> it tries right before the file is finished, and doesn't try again... so i
> have to go 'touch' the file.
>
> I have a suggestion for fixing this problem. Unfortuneately, I don't
> think there's any way to know if a file is done being written to. So
> I think a timer in the appropriate place would provide for the most
> foolproof operation.
>
> I haven't tested this code, but it should work fine... There might be
> a typo or two.
>
> I included a couple of other changes, like checking to see if a file's
> modification time has changed rather than increased. This is because,
> at least under unix, if you untar a .tar file, it might preserve
> modification times, resulting in the .jar changing in the deploy area,
> but not being redeployed. Other commands show this behaviour too.
>
> // Check watched URLs
> for (int i = 0; i < watchedURLs.size(); i++)
> {
> Deployment deployment = (Deployment)watchedURLs.get(i);
> long lm;
> File file = null;
> if (deployment.watch.getProtocol().startsWith("file")) {
> file = new File(deployment.watch.getFile());
> lm = file.lastModified();
> } else {
> // Use URL connection to get timestamp
> lm = deployment.watch.openConnection().getLastModified();
> }
> if (file != null && deployment.lastModified != lm) {
> // wait for file to stop growing...
> long size = 0;
> while (true) {
> size = file.length();
> Thread.sleep(DEPLOYMENT_DELAY);
> long newSize = file.length();
> long newLM = file.lastModified();
> if (size == newSize && lm == newLM) break;
> lm = file.lastModified();
> log.log("Waiting for file to stop changing: " + deployment.url);
> }
> }
>
> // Check old timestamp -- always deploy if first check
> if (deployment.lastModified == 0 || deployment.lastModified != lm)
> {
> log.log("Auto deploy of "+deployment.url);
> // continue normally
>
> BTW, Why the check for deployment.lastModified == 0? The only time that
> would be true but (deployment.lastModified != lm) would be false
> would be if
> (lm == 0). And if (lm == 0) then we're going to start an infinite
> auto-deploy loop anyway because of the (deployment.lastModified == 0)
> check.
>
> Also, the wait loop could be implemented as a separate thread that is
> launched so that other stuff can deploy while we're waiting on this one
> file to stop growing... probably not necessary though.
>
> DEPLOYMENT_DELAY could be configured by the user in one of the conf
> files... I'd personally set it to something like 5 seconds or more,
> although a default of 1 second might be appropriate.
>
> David Green
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
