Re: the remotable API to upload individual files w/in a deployment, let's discuss next week and then I'll open a JIRA.
Re: Windows jar locking with exploded deployments -- from various discussions I have a vague feeling it may be possible to avoid that without copying. I'm doubtful. Bottom line is if when this is implemented we have to copy to avoid file locking problems, we'll copy.
Ok!
Max Andersen wrote:
If we're going to leave the original file around, for zipped files IMO we should do away with the marker files, and use them solely for exploded deployments, where they have a clear purpose. If the zipped files are left around, the only thing the
Or is there other/better ways to get this info now ?
When anything is deployed, an entry for it is written in the standalone/configuration/standalone.xml file.
ah - so deployment actually changes the original .xml file? Nice.
I hope it will retain comments that are in that file ? :p
Why have markers both at toplevel /foo.war.deployed and foo.war/META-INF/jboss-deploy - why not just have them as foo.war.deploy (request deployment of foo.war) and foo.war.deployed (marker for foo.war have been deployed) ? More consistent IMO.
Fine with me.
At submodule deployments it might make sense to have other markers at a different "Depth" but when its the "same" thing you trigger a redeploy of the marker should be the same.
There's no plan to support independent redeployment of submodules.
The downside to that is multiple changes can't be made as an atomic unit, with no requests seeing only some of the changes. But I don't think that's a critical use case. Devs doing testing will deploy content, make some requests, update some files in the deployment, make some requests, etc. They're not making requests in the middle of copying in changed files.
This is actually a critical use case. Today we use jmx calls to tell AS to *not* scan folders while we are copying files over and then continue when we are done. If we didn't do that you would see *alot* more failure deployments.
i.e. users updating a jar or set of jars - that copy operation will actually take some ms's or even seconds for large jars and without disabling the scanner we see alot more partial deployments.
This can happen both on the initial creation of the foo.war or during editing/changes.
I think it would be great have a marker file to prevent deployment - i.e. foo.war.nodeploy would make the scanner skip checking foo.war. Then the tool or user can remove it when he wants it in play again.
Doesn't the .deploy file mechanism deal with this? With an exploded deployment, the user has to add that file to trigger redeploy. Once the thing is deployed, changing the contents changes what's visible as a resource to the deployment's classloader, but the scanner doesn't do a full redeploy just because it detects some of the content changed.
I guess - so if user change a file manually they will have to touch the .deploy file.
I suspect this is leading into the subject of hot replacement of classes, which sounds like a good topic for over a beer next week.
Luckily I think this problem is actually simpler to handle once we get the basic 'filesystem API' in place.
At least from a tooling user/dev perspective - the actual runtime implications is harder ;)