I'm quite aware of how to get around the problem. If I wasn't, I wouldn't
have been able to write code to fix the problem generically :)
We use 'scp' not 'cp'.
David Green
On Thu, 28 Jun 2001, Jim Brownfield wrote:
> 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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
