Brian Stansberry wrote:
Is it easier just to copy the exploded deployment and have the scanner keep the copy in sync. I've done that for farming; it's not such a big deal. I'm starting to feel like not doing that is leading to a lot of internal complication (e.g. needing to keep track of multiple locations where content is stored.)
That doesn't solve the atomic move problem, but maybe if people can't do atomic moves they should use the filesystem as their deployment API. :)
If the cost of deep copying and keeping in synch the exploded archive is not that high, that would solve the undeploy problems. Although I would personally leave the option to the user whether to disable deep copy of deployments, either globally (system property) or per deployment (e.g. META-INF/jboss-no-deep-copy).
On the same topic, I'm not sure if you are aware or if this still holds true. In 4.x we essentially copyied over to tmp/deploy after prefixing some random name all archives from deploy on which we had to point a classloader, because the cl would lock the file and couldn't be deleted until the next restart. Same for any nested archive discovered through the expansion process (e.g. an ejb.jar found inside a zipped or an exploded .ear) So removing those archives from the copy location may not be possible.