> Brian Stansberry wrote: > > Thanks for the input. I was off yesterday; hence the slow reply. > > > Max Andersen wrote: > > > > Local and remote deployment are different things, but both have usecases for hotdeployment functionallity - i.e. me updating a html page shouldn't require a full restart of an app, even if running remotely on an EC2 server for my testing. > > > I'm interpreting this as a request for a remotable API to allow users to 1) upload exploded deployments and 2) upload individual files to change the contents of those deployments. If that's correct, can you file a JIRA, as that isn't on any roadmap. > > http://community.jboss.org/thread/154922 http://community.jboss.org/thread/154922 list the discussions done at JBoss World and previous about this topic. If you want me to create a jira for it I will - which component in JBAS should it be ? > > I don't understand why you have to *remove* the deployed files - if they aren't locked by appserver then please keep them there otherwise tooling have to constantly copy all content to the location (this is not a problem in toy samples, but take a Seam EAR, that is over 20MB of data....that takes time, CPU and disk IO on even the fastests systems - if I touch a html file - tools should not need to copy all again) > For exploded content the intent is to leave the original file there. The assumption is the reason people use an exploded deployment is they want to be able to manipulate its contents, so deleting it would be non-sensical. :) Yup - btw. I assume you copy the content to avoid locks or will the content actually be locked as it was the case for <7 ? (i.e. jar's were getting locked on windows 7) > > For Zipped archives we still have to copy all so that is less of an issue - but why not keep the file there so users can actually see what got deployed and they can adjust content as they need ? (I really find this "delete what got deployed"-approach weird..I don't understand the reasoning) > > > What do you mean "they can adjust content as they need?" Only thing I can think of is to replace the zip with another version. In some cases you as a user don't actually have the "original". I.e. when using tools that incrementally keeps the jar uptodate the user just have the "source" files not the actual jar. Meaning if he spots an error somewhere and want to reduce the possible error causes he stops the tooling and go look at the actual deployed thing. Pre AS 7 (or any other server I've worked with) you can simply go and unzip -l the content and from there see what actually got deployed and redeploy again with changes if you need to (without having to involve extra layers of tooling or maintanence). > I'm OK with leaving the original deployment around. Jaikiran commented way back that removing it forces the user to keep a copy of it around somewhere else. > > > > Exactly. > The logic for removing it is once the scanner has picked up foo.war and deployed it, the foo.war.deployed file is what matters. Deleting that file is what triggers undeploy. Deleting foo.war itself does nothing., and leaving the file there leads people to believe that deleting it means something. > > I know that's a bit inconsistent though, since copying in a new version of foo.war does trigger a deployment action. > > 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 ? > > 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 ? :) > > 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. > > Another issue is though how is all of this going to work for updates that should not trigger a full restart of a module ? i.e. updating html/xhtml pages does not force a restart of a module which causes current sessions to be destroyed ? > Good question. We'd been talking in terms of having the exploded content in deployments/ directly mounted, i.e. being directly used as the deployment content. The marker files would serve to trigger deploy/undeploy/redeploy. Once the content was deployed, changes in the content, e.g. a new deployments/foo.war/index.jsp, would be immediately visible. Ok - sounds good; but I guess for .jar's you will copy-on-read to avoid classloader filesystem locking or will we still have the same old problem ? > 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.

Brian Stansberry wrote: 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. > 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 ;)

Brian Stansberry wrote: > 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.

Jason Greene wrote: > jaikiran pai wrote: > > > 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. > > > > I was reading a mail about configuring Java2 security for a web application on AS5 and realized that it might have to play a role here too. Users might have to know the (consistent) location where the deployments will be extracted so that they can setup appropriate permissions. A very good point. This should become a separate forum thread, as it affects all deployments (domain deployments) as well. We may need to somehow add this info to the domain.