Did this kind of deployment dir sharing work on previous AS releases? I suppose it might have for .war files since IIRC wars were copied into tmp/. For other deployment types I believe doing this would have led to file lock problems on Windows. Anyway, I've opened https://issues.jboss.org/browse/AS7-4383 to look into not writing marker files or optionally writing them in data/. Part of the purpose of those marker files was a request that we provide in the dir itself input to users as to what was happening with the deployment. Even if AS7-4383 were done I don't think *exploded* deployments would work reliably at all if scanners on multiple servers were scanning the same dir. There would likely be file lock problems and deleting the .deployed file is the intended trigger for undeploy. Deleting the deployment itself also triggers undeploy, but it is very dangerous to do it that way for an exploded deployment. More in-line... On 3/30/12 7:34 AM, Bela Ban wrote: It knows it's not deployed, because it can check the server-side state. Recommended is to use the CLI to do the deployments. This can be scripted easily enough if you know the addresses/ports the servers are listening on. (I realize that may be a problem in some situations.) You can also configure the AS to use a deployment at a specific location: <deployments> <deployment name="demo.war" runtime-name="demo.war"> <fs-archive path="demo.war" relative-to="user.home"/> </deployment> </deployments> The value for fs-archive "path" can be absolute if the relative-to attribute is not used. I just filed a JIRA to make it easier to set this up via the CLI: https://issues.jboss.org/browse/AS7-4385 See above; the request was to provide input to the user as to what went on. The user is not meant to look in the data/ dir; it's the AS' private playground. Also, the recommended trigger for undeploy is deleting the .deployed file. -- Brian Stansberry Principal Software Engineer JBoss by Red Hat