This forum interface drives me nuts. As I write this I'm chatting about what public mailing list we should use for AS 7 dev discussions.
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.
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 marker files provide is an indication that the content was actually deployed. There are other ways to see that; and by itself that's not justification for the confusion of having two files around.
I agree - if the file stays around the marker file has no real importance.
Well, maybe for consistency and actually knowing the file got deployed without having to scan logs ?
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.
How are users to know where the actual deployment is happening from ? Suggestion: put a deploy.location=/var/tmp/blahbla/foo.war into the marker file - simply for ease of debugging/transparency.I've been tempted to do that. Haven't because 1) it forms a semi-contract that I'm not sure we should commit ourselves to. 2) It also encourages poking around in places users aren't meant to go poking. 3) It also forces the deployment content repository to expose internal implementation details to the deployment scanner service, which isn't the end of the world but isn't nice either.
There is INFO level logging of where the deployment content is stored (which shoots my #2 above). :-)
I keep hearing this "by exposing the actual deployment location there is a semi-contract"-excuse and I just don't buy it.
The deployment is going to be *somewhere* wether that is on the filesystem or in-memory then telling the user where it is being 'read' from is never a bad information to have.
And as you said - it gets logged anyway (for a reason I assume ? :)
I have no serious objection to telling people where deployments are stored. This is OSS after all. As we go along there should be a wiki page describing exactly how this works for a given release. I'm just doubtful about persisting it in this file. People come to count on reading the file and you can't lightly stop writing it even if it becomes a problem.
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 suspect this is leading into the subject of hot replacement of classes, which sounds like a good topic for over a beer next week.