Barrie, Could you also try that with hotdeploy instead of using the jbi maven plugin to deploy these artifacts to see if that improves the situation?
Regards, Gert Vanthienen ------------------------ Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/10/7 Barrie Treloar <[email protected]>: > On Wed, Oct 7, 2009 at 6:09 AM, Gert Vanthienen > <[email protected]> wrote: >> Barrie, >> >> I was going to suggest looking at virus scanners for the same reason >> -- they tend to look into zip/jar files and keeping them locked, >> preventing deletion from disk. You'll probably notice that as well in >> unlocker though if that's the case... > > Could be that as well, will try it. > I dont have enough priveleges to tell the virus scanner not to check > SMX directories. > > However, failing to delete the old directory should not cause me to > fail to deploy a new version. > Isn't the new version placed into a new directory? > > As discussed in the first post a fresh SMX start fails to deploy my > app, but it works if I re-run the deploy command again. > Then if I want to deploy another time, I have to restart SMX, and go > through the above again (failed deploy, working deploy). > Not sure if files being locked would be the cause of this... >
