Maybe I'm just not supposed to do it this way but: 1) I deployed a bad war, bot a deployment error 2) I fixed the problem, re-copied the war to the deployments directory 3) The war deployment was skipped on restart (I'm guessing because there is a mywar.war.failed file in the deploy directory. Is this intended behavior? Seems like it could cause a lot of problems. In the minimum, AS7 should check to see if the date of the .failed or .deployed file is older than the actual deployment file. I'll log a JIRA if u agree. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

IMO, many users would still prefer file system based deployments since it doesn't require the server to be started and is also pretty simple to "deploy".

Although, we should encourage users to use CLI or web interface, IMO, many users would still prefer file system based deployments since it doesn't require the server to be started and is also pretty simple to "deploy". -Jaikiran On Friday 08 July 2011 07:14 PM, Heiko Braun wrote: > > > As a side note: > > Users are not advised to use the file system deployment mechanism. > This is intended to be used by deployment tools that properly deal with all the > marker files (eclipse, maven). Users should either rely on the CLI or the web interface to deploy applications: > > https://docs.jboss.org/author/display/AS7/Admin+Guide > > > Ike > > > > On Jul 8, 2011, at 3:38 PM, Bill Burke wrote: > >> Maybe I'm just not supposed to do it this way but: >> >> 1) I deployed a bad war, bot a deployment error >> 2) I fixed the problem, re-copied the war to the deployments directory >> 3) The war deployment was skipped on restart (I'm guessing because there >> is a mywar.war.failed file in the deploy directory. >> >> Is this intended behavior? Seems like it could cause a lot of problems. >> In the minimum, AS7 should check to see if the date of the .failed or >> .deployed file is older than the actual deployment file. >> >> I'll log a JIRA if u agree. >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Although, we should encourage users to use CLI or web interface, IMO, many users would still prefer file system based deployments since it doesn't require the server to be started and is also pretty simple to "deploy". -Jaikiran On Friday 08 July 2011 07:14 PM, Heiko Braun wrote: > > > As a side note: > > Users are not advised to use the file system deployment mechanism. > This is intended to be used by deployment tools that properly deal with all the > marker files (eclipse, maven). Users should either rely on the CLI or the web interface to deploy applications: > > https://docs.jboss.org/author/display/AS7/Admin+Guide > > > Ike > > > > On Jul 8, 2011, at 3:38 PM, Bill Burke wrote: > >> Maybe I'm just not supposed to do it this way but: >> >> 1) I deployed a bad war, bot a deployment error >> 2) I fixed the problem, re-copied the war to the deployments directory >> 3) The war deployment was skipped on restart (I'm guessing because there >> is a mywar.war.failed file in the deploy directory. >> >> Is this intended behavior? Seems like it could cause a lot of problems. >> In the minimum, AS7 should check to see if the date of the .failed or >> .deployed file is older than the actual deployment file. >> >> I'll log a JIRA if u agree. >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I may be too old school as well, but I miss the old file-system deployment. The new marker system is error-prone and confusing. The README in the deployments dir, while helpful, shouldn't be necessary. Apparently, there were some edge conditions that made hot deployment hard -- I remember having to disable the scanner before copying lots of files and then reenable after -- so rather than spend the effort to address those issues, instead we expose the complexity to the user?

Copying an archive to a directory to deploy it and removing it to undeploy it is simple and beautiful. That mechanism distinguishes JBoss among the other point-and-drool app server alternatives. Personally, I think it's worth making that work.

Maintaining your deployment state on the filesystem is awesome, allowing clever sysadmins to do some amazing things with rsync, git, and other filesystem-based tools. Expecting users to sacrifice those tools in order to use a shiny web interface or fancy CLI is a mistake, imho. I think the marker stuff will piss them off, tbh.

I say let the deployment tools (eclipse, maven, etc) use the CLI/API and bring back the old deployments dir.

Jason, I appreciate all the history, discussion and thought that went into it. I'm too lazy to read back through all that. If you'd like to summarize, great. Otherwise, I trust you. Just to be clear, though: unless I totally misunderstand things, it does not still "essentially work" the way I (and I'm sure many others) would prefer. I want to copy an archive to a dir to deploy it, touch it to redeploy it, and remove it to undeploy it. Period.

I do not wish to rename marker files -- I simply won't remember those suffixes and the implied state machine described in that README. To repeat, I don't mind the marker files being around. It's a handy way to know whether a deployment failed intead of looking at the log. I just don't want to have to mess with the markers, only my archives. Granted, I find the synchronous deployment and immediate success/failure offered through the CLI to be keen and swell because I, like you, am an old UNIX guy. But sometimes I just want to shuffle archives around. :) Thanks, Jim "Jason T. Greene"<jason.greene(a)redhat.com> writes: > On 7/8/11 9:21 AM, Jim Crossley wrote: >> I may be too old school as well, but I miss the old file-system >> deployment. The new marker system is error-prone and confusing. The >> README in the deployments dir, while helpful, shouldn't be necessary. >> Apparently, there were some edge conditions that made hot deployment >> hard -- I remember having to disable the scanner before copying lots of >> files and then reenable after -- so rather than spend the effort to >> address those issues, instead we expose the complexity to the user? > > We did spend the effort to fix the issues, that's why the markers even > exist. The big issue is just that the file system is a very poor > interface for executing deployment. If you back read the forum > discussion and emails we spent an enormous amount of time debating the > fine points, so please review them before proposing any alternative design. > > One of these days I'll probably throw together something that summarizes > all of that into something quicker to read. >> >> Copying an archive to a directory to deploy it and removing it to >> undeploy it is simple and beautiful. That mechanism distinguishes JBoss >> among the other point-and-drool app server alternatives. Personally, I >> think it's worth making that work. > > That's essentially how it works. Exploded directories require an > additional step due to an unsolvable issue in Java, but there is a flag > you can set to resurrect the Russian roulette approach. > >> >> Maintaining your deployment state on the filesystem is awesome, allowing >> clever sysadmins to do some amazing things with rsync, git, and other >> filesystem-based tools. Expecting users to sacrifice those tools in >> order to use a shiny web interface or fancy CLI is a mistake, imho. I >> think the marker stuff will piss them off, tbh. > > All of those things you named use markers too. Not to mention they are > command oriented (like the CLI). Imagine if you had to do cp file.java > commit-dir/ vs the rich tool interface. > >> >> I say let the deployment tools (eclipse, maven, etc) use the CLI/API and >> bring back the old deployments dir. > > That's what we have. The difference is that we fixed some really hairy > problems that plagued the server before, and now we tell you if it was > successful or not and why it failed. > > There are certainly improvements that could be made. Bill's suggestion > is right on. I noticed the same thing happens when we have an undeployed > application. > > Honestly I think the CLI is much better to work with because it's > synchronous, it tells you what is going on, it lets you tab complete, > etc. Although I am a UNIX guy so I like my command line. _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 7/8/11 2:07 PM, Brian Stansberry wrote: > On 7/8/11 1:52 PM, Jim Crossley wrote: >> Jason, >> >> I appreciate all the history, discussion and thought that went into it. >> I'm too lazy to read back through all that. If you'd like to summarize, >> great. Otherwise, I trust you. >> >> Just to be clear, though: unless I totally misunderstand things, it does >> not still "essentially work" the way I (and I'm sure many others) would >> prefer. I want to copy an archive to a dir to deploy it, touch it to >> redeploy it, and remove it to undeploy it. Period. >> > > If you are talking about an actual zipped archive and not an exploded > deployment, and the things you described do not work, please file a > JIRA. They should all work by default. They should actually work better > than AS 6, since we work hard to deal with the sitation where a zip is > only partially copied when the scanner runs. I misspoke; to undeploy you have to delete the .deployed marker. I'll think about whether that requirement can be eliminated.

> > The behavior difference between AS 7 and AS 6 lies in how we treat > exploded deployments. We don't try and detect changes to deployment > descriptors as a trigger for deployment, since an EE 6 app may not even > have a deployment descriptor. So you have to use the marker files to > tell the scanner what your intent is. > >> I do not wish to rename marker files -- I simply won't remember those >> suffixes and the implied state machine described in that README. >> >> To repeat, I don't mind the marker files being around. It's a handy way >> to know whether a deployment failed intead of looking at the log. I >> just don't want to have to mess with the markers, only my archives. >> >> Granted, I find the synchronous deployment and immediate success/failure >> offered through the CLI to be keen and swell because I, like you, am an >> old UNIX guy. >> >> But sometimes I just want to shuffle archives around. :) >> >> Thanks, >> Jim >> >> >> "Jason T. Greene"<jason.greene(a)redhat.com> writes: >> >>> On 7/8/11 9:21 AM, Jim Crossley wrote: >>>> I may be too old school as well, but I miss the old file-system >>>> deployment. The new marker system is error-prone and confusing. The >>>> README in the deployments dir, while helpful, shouldn't be necessary. >>>> Apparently, there were some edge conditions that made hot deployment >>>> hard -- I remember having to disable the scanner before copying lots of >>>> files and then reenable after -- so rather than spend the effort to >>>> address those issues, instead we expose the complexity to the user? >>> >>> We did spend the effort to fix the issues, that's why the markers even >>> exist. The big issue is just that the file system is a very poor >>> interface for executing deployment. If you back read the forum >>> discussion and emails we spent an enormous amount of time debating the >>> fine points, so please review them before proposing any alternative design. >>> >>> One of these days I'll probably throw together something that summarizes >>> all of that into something quicker to read. >>>> >>>> Copying an archive to a directory to deploy it and removing it to >>>> undeploy it is simple and beautiful. That mechanism distinguishes JBoss >>>> among the other point-and-drool app server alternatives. Personally, I >>>> think it's worth making that work. >>> >>> That's essentially how it works. Exploded directories require an >>> additional step due to an unsolvable issue in Java, but there is a flag >>> you can set to resurrect the Russian roulette approach. >>> >>>> >>>> Maintaining your deployment state on the filesystem is awesome, allowing >>>> clever sysadmins to do some amazing things with rsync, git, and other >>>> filesystem-based tools. Expecting users to sacrifice those tools in >>>> order to use a shiny web interface or fancy CLI is a mistake, imho. I >>>> think the marker stuff will piss them off, tbh. >>> >>> All of those things you named use markers too. Not to mention they are >>> command oriented (like the CLI). Imagine if you had to do cp file.java >>> commit-dir/ vs the rich tool interface. >>> >>>> >>>> I say let the deployment tools (eclipse, maven, etc) use the CLI/API and >>>> bring back the old deployments dir. >>> >>> That's what we have. The difference is that we fixed some really hairy >>> problems that plagued the server before, and now we tell you if it was >>> successful or not and why it failed. >>> >>> There are certainly improvements that could be made. Bill's suggestion >>> is right on. I noticed the same thing happens when we have an undeployed >>> application. >>> >>> Honestly I think the CLI is much better to work with because it's >>> synchronous, it tells you what is going on, it lets you tab complete, >>> etc. Although I am a UNIX guy so I like my command line. >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > >

Thanks Brian/Jason, I'm tickled pink to hear you guys say it should work exactly like I expect. Unfortunately, it doesn't yet, so per your request: https://issues.jboss.org/browse/AS7-1237 Let me know if the steps to reproduce are unclear. I used a bone-stupid war file to test. I'll attach it if need be. Thanks again, Jim Brian Stansberry<brian.stansberry(a)redhat.com> writes: > On 7/8/11 2:12 PM, Brian Stansberry wrote: >> On 7/8/11 2:07 PM, Brian Stansberry wrote: >>> On 7/8/11 1:52 PM, Jim Crossley wrote: >>>> Jason, >>>> >>>> I appreciate all the history, discussion and thought that went into it. >>>> I'm too lazy to read back through all that. If you'd like to summarize, >>>> great. Otherwise, I trust you. >>>> >>>> Just to be clear, though: unless I totally misunderstand things, it does >>>> not still "essentially work" the way I (and I'm sure many others) would >>>> prefer. I want to copy an archive to a dir to deploy it, touch it to >>>> redeploy it, and remove it to undeploy it. Period. >>>> >>> >>> If you are talking about an actual zipped archive and not an exploded >>> deployment, and the things you described do not work, please file a >>> JIRA. They should all work by default. They should actually work better >>> than AS 6, since we work hard to deal with the sitation where a zip is >>> only partially copied when the scanner runs. >> >> I misspoke; to undeploy you have to delete the .deployed marker. I'll >> think about whether that requirement can be eliminated. >> > > Looks like it can be. > > The rationale for requiring deleting the .deployed marker to trigger > undeploy was because of the exploded deployment case. > > Zipped deployments, we copy off to a tmp directory and serve the app > from that copy. So you can delete the original version in deployments/ > and cause no harm. But, we server exploded deployments directly from the > deployments/ dir. This allows things to work like swapping in a new > version of a .html file and having it be picked up without redeploying > the whole app. > > Deleting an exploded deployment to undeploy it is the wrong thing to do, > because the deployment content has disappeared out from under the > appserver before it has any chance to do a proper undeploy. So we said > "don't do that, and to encourage you to do it right, the rule is you > have to delete the .deployed marker to undeploy." > > Well, now that rule effects zipped archives as well, for no good reason. > And for exploded content there's no reason we can't try and undeploy if > you delete the content. Deleting the .deployed marker first *is the > right thing to do*. But if people mess up and delete the content first, > as soon as they do that they've broken their app so we might as well go > ahead and undeploy. > >>> >>> The behavior difference between AS 7 and AS 6 lies in how we treat >>> exploded deployments. We don't try and detect changes to deployment >>> descriptors as a trigger for deployment, since an EE 6 app may not even >>> have a deployment descriptor. So you have to use the marker files to >>> tell the scanner what your intent is. >>> >>>> I do not wish to rename marker files -- I simply won't remember those >>>> suffixes and the implied state machine described in that README. >>>> >>>> To repeat, I don't mind the marker files being around. It's a handy way >>>> to know whether a deployment failed intead of looking at the log. I >>>> just don't want to have to mess with the markers, only my archives. >>>> >>>> Granted, I find the synchronous deployment and immediate success/failure >>>> offered through the CLI to be keen and swell because I, like you, am an >>>> old UNIX guy. >>>> >>>> But sometimes I just want to shuffle archives around. :) >>>> >>>> Thanks, >>>> Jim >>>> >>>> >>>> "Jason T. Greene"<jason.greene(a)redhat.com> writes: >>>> >>>>> On 7/8/11 9:21 AM, Jim Crossley wrote: >>>>>> I may be too old school as well, but I miss the old file-system >>>>>> deployment. The new marker system is error-prone and confusing. The >>>>>> README in the deployments dir, while helpful, shouldn't be necessary. >>>>>> Apparently, there were some edge conditions that made hot deployment >>>>>> hard -- I remember having to disable the scanner before copying lots of >>>>>> files and then reenable after -- so rather than spend the effort to >>>>>> address those issues, instead we expose the complexity to the user? >>>>> >>>>> We did spend the effort to fix the issues, that's why the markers even >>>>> exist. The big issue is just that the file system is a very poor >>>>> interface for executing deployment. If you back read the forum >>>>> discussion and emails we spent an enormous amount of time debating the >>>>> fine points, so please review them before proposing any alternative design. >>>>> >>>>> One of these days I'll probably throw together something that summarizes >>>>> all of that into something quicker to read. >>>>>> >>>>>> Copying an archive to a directory to deploy it and removing it to >>>>>> undeploy it is simple and beautiful. That mechanism distinguishes JBoss >>>>>> among the other point-and-drool app server alternatives. Personally, I >>>>>> think it's worth making that work. >>>>> >>>>> That's essentially how it works. Exploded directories require an >>>>> additional step due to an unsolvable issue in Java, but there is a flag >>>>> you can set to resurrect the Russian roulette approach. >>>>> >>>>>> >>>>>> Maintaining your deployment state on the filesystem is awesome, allowing >>>>>> clever sysadmins to do some amazing things with rsync, git, and other >>>>>> filesystem-based tools. Expecting users to sacrifice those tools in >>>>>> order to use a shiny web interface or fancy CLI is a mistake, imho. I >>>>>> think the marker stuff will piss them off, tbh. >>>>> >>>>> All of those things you named use markers too. Not to mention they are >>>>> command oriented (like the CLI). Imagine if you had to do cp file.java >>>>> commit-dir/ vs the rich tool interface. >>>>> >>>>>> >>>>>> I say let the deployment tools (eclipse, maven, etc) use the CLI/API and >>>>>> bring back the old deployments dir. >>>>> >>>>> That's what we have. The difference is that we fixed some really hairy >>>>> problems that plagued the server before, and now we tell you if it was >>>>> successful or not and why it failed. >>>>> >>>>> There are certainly improvements that could be made. Bill's suggestion >>>>> is right on. I noticed the same thing happens when we have an undeployed >>>>> application. >>>>> >>>>> Honestly I think the CLI is much better to work with because it's >>>>> synchronous, it tells you what is going on, it lets you tab complete, >>>>> etc. Although I am a UNIX guy so I like my command line. >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> >> >> _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Why not put the .deployed file within an exploded archive and a zipped archive just do what we used to do? Or maybe that's what you've been discussing. On 7/8/11 4:12 PM, Jason T. Greene wrote: > Yes this is the issue that Bill referred to that we are going to fix. > > On 7/8/11 3:10 PM, Jim Crossley wrote: >> Thanks Brian/Jason, >> >> I'm tickled pink to hear you guys say it should work exactly like I >> expect. >> >> Unfortunately, it doesn't yet, so per your request: >> https://issues.jboss.org/browse/AS7-1237 >> >> Let me know if the steps to reproduce are unclear. I used a bone-stupid >> war file to test. I'll attach it if need be. >> >> Thanks again, >> Jim >> >> >> Brian Stansberry<brian.stansberry(a)redhat.com> writes: >> >>> On 7/8/11 2:12 PM, Brian Stansberry wrote: >>>> On 7/8/11 2:07 PM, Brian Stansberry wrote: >>>>> On 7/8/11 1:52 PM, Jim Crossley wrote: >>>>>> Jason, >>>>>> >>>>>> I appreciate all the history, discussion and thought that went into it. >>>>>> I'm too lazy to read back through all that. If you'd like to summarize, >>>>>> great. Otherwise, I trust you. >>>>>> >>>>>> Just to be clear, though: unless I totally misunderstand things, it does >>>>>> not still "essentially work" the way I (and I'm sure many others) would >>>>>> prefer. I want to copy an archive to a dir to deploy it, touch it to >>>>>> redeploy it, and remove it to undeploy it. Period. >>>>>> >>>>> >>>>> If you are talking about an actual zipped archive and not an exploded >>>>> deployment, and the things you described do not work, please file a >>>>> JIRA. They should all work by default. They should actually work better >>>>> than AS 6, since we work hard to deal with the sitation where a zip is >>>>> only partially copied when the scanner runs. >>>> >>>> I misspoke; to undeploy you have to delete the .deployed marker. I'll >>>> think about whether that requirement can be eliminated. >>>> >>> >>> Looks like it can be. >>> >>> The rationale for requiring deleting the .deployed marker to trigger >>> undeploy was because of the exploded deployment case. >>> >>> Zipped deployments, we copy off to a tmp directory and serve the app >>> from that copy. So you can delete the original version in deployments/ >>> and cause no harm. But, we server exploded deployments directly from the >>> deployments/ dir. This allows things to work like swapping in a new >>> version of a .html file and having it be picked up without redeploying >>> the whole app. >>> >>> Deleting an exploded deployment to undeploy it is the wrong thing to do, >>> because the deployment content has disappeared out from under the >>> appserver before it has any chance to do a proper undeploy. So we said >>> "don't do that, and to encourage you to do it right, the rule is you >>> have to delete the .deployed marker to undeploy." >>> >>> Well, now that rule effects zipped archives as well, for no good reason. >>> And for exploded content there's no reason we can't try and undeploy if >>> you delete the content. Deleting the .deployed marker first *is the >>> right thing to do*. But if people mess up and delete the content first, >>> as soon as they do that they've broken their app so we might as well go >>> ahead and undeploy. >>> >>>>> >>>>> The behavior difference between AS 7 and AS 6 lies in how we treat >>>>> exploded deployments. We don't try and detect changes to deployment >>>>> descriptors as a trigger for deployment, since an EE 6 app may not even >>>>> have a deployment descriptor. So you have to use the marker files to >>>>> tell the scanner what your intent is. >>>>> >>>>>> I do not wish to rename marker files -- I simply won't remember those >>>>>> suffixes and the implied state machine described in that README. >>>>>> >>>>>> To repeat, I don't mind the marker files being around. It's a handy way >>>>>> to know whether a deployment failed intead of looking at the log. I >>>>>> just don't want to have to mess with the markers, only my archives. >>>>>> >>>>>> Granted, I find the synchronous deployment and immediate success/failure >>>>>> offered through the CLI to be keen and swell because I, like you, am an >>>>>> old UNIX guy. >>>>>> >>>>>> But sometimes I just want to shuffle archives around. :) >>>>>> >>>>>> Thanks, >>>>>> Jim >>>>>> >>>>>> >>>>>> "Jason T. Greene"<jason.greene(a)redhat.com> writes: >>>>>> >>>>>>> On 7/8/11 9:21 AM, Jim Crossley wrote: >>>>>>>> I may be too old school as well, but I miss the old file-system >>>>>>>> deployment. The new marker system is error-prone and confusing. The >>>>>>>> README in the deployments dir, while helpful, shouldn't be necessary. >>>>>>>> Apparently, there were some edge conditions that made hot deployment >>>>>>>> hard -- I remember having to disable the scanner before copying lots of >>>>>>>> files and then reenable after -- so rather than spend the effort to >>>>>>>> address those issues, instead we expose the complexity to the user? >>>>>>> >>>>>>> We did spend the effort to fix the issues, that's why the markers even >>>>>>> exist. The big issue is just that the file system is a very poor >>>>>>> interface for executing deployment. If you back read the forum >>>>>>> discussion and emails we spent an enormous amount of time debating the >>>>>>> fine points, so please review them before proposing any alternative design. >>>>>>> >>>>>>> One of these days I'll probably throw together something that summarizes >>>>>>> all of that into something quicker to read. >>>>>>>> >>>>>>>> Copying an archive to a directory to deploy it and removing it to >>>>>>>> undeploy it is simple and beautiful. That mechanism distinguishes JBoss >>>>>>>> among the other point-and-drool app server alternatives. Personally, I >>>>>>>> think it's worth making that work. >>>>>>> >>>>>>> That's essentially how it works. Exploded directories require an >>>>>>> additional step due to an unsolvable issue in Java, but there is a flag >>>>>>> you can set to resurrect the Russian roulette approach. >>>>>>> >>>>>>>> >>>>>>>> Maintaining your deployment state on the filesystem is awesome, allowing >>>>>>>> clever sysadmins to do some amazing things with rsync, git, and other >>>>>>>> filesystem-based tools. Expecting users to sacrifice those tools in >>>>>>>> order to use a shiny web interface or fancy CLI is a mistake, imho. I >>>>>>>> think the marker stuff will piss them off, tbh. >>>>>>> >>>>>>> All of those things you named use markers too. Not to mention they are >>>>>>> command oriented (like the CLI). Imagine if you had to do cp file.java >>>>>>> commit-dir/ vs the rich tool interface. >>>>>>> >>>>>>>> >>>>>>>> I say let the deployment tools (eclipse, maven, etc) use the CLI/API and >>>>>>>> bring back the old deployments dir. >>>>>>> >>>>>>> That's what we have. The difference is that we fixed some really hairy >>>>>>> problems that plagued the server before, and now we tell you if it was >>>>>>> successful or not and why it failed. >>>>>>> >>>>>>> There are certainly improvements that could be made. Bill's suggestion >>>>>>> is right on. I noticed the same thing happens when we have an undeployed >>>>>>> application. >>>>>>> >>>>>>> Honestly I think the CLI is much better to work with because it's >>>>>>> synchronous, it tells you what is going on, it lets you tab complete, >>>>>>> etc. Although I am a UNIX guy so I like my command line. >>>>>> _______________________________________________ >>>>>> jboss-as7-dev mailing list >>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>> >>>>> >>>> >>>> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I may be too old school as well, but I miss the old file-system deployment. The new marker system is error-prone and confusing. The README in the deployments dir, while helpful, shouldn't be necessary. Apparently, there were some edge conditions that made hot deployment hard -- I remember having to disable the scanner before copying lots of files and then reenable after -- so rather than spend the effort to address those issues, instead we expose the complexity to the user? Copying an archive to a directory to deploy it and removing it to undeploy it is simple and beautiful. That mechanism distinguishes JBoss among the other point-and-drool app server alternatives. Personally, I think it's worth making that work. Maintaining your deployment state on the filesystem is awesome, allowing clever sysadmins to do some amazing things with rsync, git, and other filesystem-based tools. Expecting users to sacrifice those tools in order to use a shiny web interface or fancy CLI is a mistake, imho. I think the marker stuff will piss them off, tbh. I say let the deployment tools (eclipse, maven, etc) use the CLI/API and bring back the old deployments dir. And keep those kids off my lawn! ;) $.02 Jim Jaikiran Pai<jpai(a)redhat.com> writes: > Although, we should encourage users to use CLI or web interface, IMO, > many users would still prefer file system based deployments since it > doesn't require the server to be started and is also pretty simple to > "deploy". > > -Jaikiran > On Friday 08 July 2011 07:14 PM, Heiko Braun wrote: >> >> As a side note: >> >> Users are not advised to use the file system deployment mechanism. >> This is intended to be used by deployment tools that properly deal with all the >> marker files (eclipse, maven). Users should either rely on the CLI or the web interface to deploy applications: >> >> https://docs.jboss.org/author/display/AS7/Admin+Guide >> >> >> Ike >> >> >> >> On Jul 8, 2011, at 3:38 PM, Bill Burke wrote: >> >>> Maybe I'm just not supposed to do it this way but: >>> >>> 1) I deployed a bad war, bot a deployment error >>> 2) I fixed the problem, re-copied the war to the deployments directory >>> 3) The war deployment was skipped on restart (I'm guessing because there >>> is a mywar.war.failed file in the deploy directory. >>> >>> Is this intended behavior? Seems like it could cause a lot of problems. >>> In the minimum, AS7 should check to see if the date of the .failed or >>> .deployed file is older than the actual deployment file. >>> >>> I'll log a JIRA if u agree. >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

As a side note: Users are not advised to use the file system deployment mechanism. This is intended to be used by deployment tools that properly deal with all the marker files (eclipse, maven). Users should either rely on the CLI or the web interface to deploy applications: https://docs.jboss.org/author/display/AS7/Admin+Guide Ike On Jul 8, 2011, at 3:38 PM, Bill Burke wrote: > Maybe I'm just not supposed to do it this way but: > > 1) I deployed a bad war, bot a deployment error > 2) I fixed the problem, re-copied the war to the deployments directory > 3) The war deployment was skipped on restart (I'm guessing because there > is a mywar.war.failed file in the deploy directory. > > Is this intended behavior? Seems like it could cause a lot of problems. > In the minimum, AS7 should check to see if the date of the .failed or > .deployed file is older than the actual deployment file. > > I'll log a JIRA if u agree. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

As a side note: Users are not advised to use the file system deployment mechanism. This is intended to be used by deployment tools that properly deal with all the marker files (eclipse, maven). Users should either rely on the CLI or the web interface to deploy applications: https://docs.jboss.org/author/display/AS7/Admin+Guide

Ike On Jul 8, 2011, at 3:38 PM, Bill Burke wrote: > Maybe I'm just not supposed to do it this way but: > > 1) I deployed a bad war, bot a deployment error > 2) I fixed the problem, re-copied the war to the deployments directory > 3) The war deployment was skipped on restart (I'm guessing because there > is a mywar.war.failed file in the deploy directory. > > Is this intended behavior? Seems like it could cause a lot of problems. > In the minimum, AS7 should check to see if the date of the .failed or > .deployed file is older than the actual deployment file. > > I'll log a JIRA if u agree. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Maybe I'm just not supposed to do it this way but: 1) I deployed a bad war, bot a deployment error 2) I fixed the problem, re-copied the war to the deployments directory 3) The war deployment was skipped on restart (I'm guessing because there is a mywar.war.failed file in the deploy directory. Is this intended behavior? Seems like it could cause a lot of problems. In the minimum, AS7 should check to see if the date of the .failed or .deployed file is older than the actual deployment file. I'll log a JIRA if u agree. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Yep I demod standalone in my webinar it's ridiculously fast Sent from my iPhone On Jul 9, 2011, at 12:32 PM, ssilvert(a)redhat.com wrote: > On a side note, has ANYBODY besides me tried web console deployment. > It's really easy and convenient. Just point, click, and grunt. > > Stan > > Quoting Bill Burke<bburke(a)redhat.com>: > >> Maybe I'm just not supposed to do it this way but: >> >> 1) I deployed a bad war, bot a deployment error >> 2) I fixed the problem, re-copied the war to the deployments directory >> 3) The war deployment was skipped on restart (I'm guessing because there >> is a mywar.war.failed file in the deploy directory. >> >> Is this intended behavior? Seems like it could cause a lot of problems. >> In the minimum, AS7 should check to see if the date of the .failed or >> .deployed file is older than the actual deployment file. >> >> I'll log a JIRA if u agree. >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > > > > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I have fixed this issue https://issues.jboss.org/browse/AS7-1237 here https://github.com/jaikiran/jboss-as/commits/AS7-1237 and sent a pull request. Brian, could you please review it and push it to upstream, if it looks OK? Manual and unit tests with that fix worked fine for me. -Jaikiran On Friday 08 July 2011 07:08 PM, Bill Burke wrote: > Maybe I'm just not supposed to do it this way but: > > 1) I deployed a bad war, bot a deployment error > 2) I fixed the problem, re-copied the war to the deployments directory > 3) The war deployment was skipped on restart (I'm guessing because there > is a mywar.war.failed file in the deploy directory. > > Is this intended behavior? Seems like it could cause a lot of problems. > In the minimum, AS7 should check to see if the date of the .failed or > .deployed file is older than the actual deployment file. > > I'll log a JIRA if u agree. > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Brian, > This is merged (thanks!) along with a fix such that deleting the > deployment content triggers undeploy[1]. > > [1] https://issues.jboss.org/browse/AS7-1240 For clarification - does this "undeploy on deleted content" only apply to zipped archives or will it also happen for exploded ? And I assume deleting the .deploy will work in any case?

Jim and I were discussing exploded deployments in #torquebox, and realized... TorqueBox pretty much only uses exploded deployments, but we do it slightly differently, and avoid copying tons of files around and dealing with partial-copies and non-atomic things. Our exploded apps live wherever the user wants them to live. Anywhere on disk. Into the deployments/ directory, we scribble a simple text file, which is basically a poor-man's symlink, plus other information used by TorqueBox. But generally, it contains a path-to-the-exploded-app. A deployer picks it up, and adjusts the DEPLOYMENT_ROOT (or whatnot) to point to the actual exploded application elsewhere on disk. From the AS perspective, we're deploy 1 small text file, at least initially. But then it magically becomes an exploded directory full of loose files. Dunno if it'd help, but generally supporting a deployments/myapp.link deployment, where the myapp.link file is just a text file containing only and exactly the path to an exploded application, might be useful. -Bob On Jul 11, 2011, at 11:00 AM, Jason T. Greene wrote: > On 7/11/11 9:41 AM, Max Rydahl Andersen wrote: >> Brian, >> >>> This is merged (thanks!) along with a fix such that deleting the >>> deployment content triggers undeploy[1]. >>> >>> [1] https://issues.jboss.org/browse/AS7-1240 >> >> For clarification - does this "undeploy on deleted content" only apply to zipped archives >> or will it also happen for exploded ? >> >> And I assume deleting the .deploy will work in any case? >> > > It only applies to things which have auto-deploy turned on. So not by > default for exploded. Although you could turn it on and get russian > roulette deployment. The biggest problem being that frameworks are > surprised when their content disappears before being shutdown. This isnt > an issue for archives because we make a copy. > > -- > Jason T. Greene > JBoss, a division of Red Hat > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

It would be really cool if we could just follow OS symlinks for that. IIRC Java 7 has support for that. On 7/11/11 10:11 AM, Bob McWhirter wrote: > Jim and I were discussing exploded deployments in #torquebox, and realized... > > TorqueBox pretty much only uses exploded deployments, but we do it slightly differently, and avoid copying tons of files around and dealing with partial-copies and non-atomic things. > > Our exploded apps live wherever the user wants them to live. Anywhere on disk. > > Into the deployments/ directory, we scribble a simple text file, which is basically a poor-man's symlink, plus other information used by TorqueBox. > > But generally, it contains a path-to-the-exploded-app. > > A deployer picks it up, and adjusts the DEPLOYMENT_ROOT (or whatnot) to point to the actual exploded application elsewhere on disk. > > From the AS perspective, we're deploy 1 small text file, at least initially. But then it magically becomes an exploded directory full of loose files. > > Dunno if it'd help, but generally supporting a deployments/myapp.link deployment, where the myapp.link file is just a text file containing only and exactly the path to an exploded application, might be useful. > > -Bob > > > > On Jul 11, 2011, at 11:00 AM, Jason T. Greene wrote: > >> On 7/11/11 9:41 AM, Max Rydahl Andersen wrote: >>> Brian, >>> >>>> This is merged (thanks!) along with a fix such that deleting the >>>> deployment content triggers undeploy[1]. >>>> >>>> [1] https://issues.jboss.org/browse/AS7-1240 >>> >>> For clarification - does this "undeploy on deleted content" only apply to zipped archives >>> or will it also happen for exploded ? >>> >>> And I assume deleting the .deploy will work in any case? >>> >> >> It only applies to things which have auto-deploy turned on. So not by >> default for exploded. Although you could turn it on and get russian >> roulette deployment. The biggest problem being that frameworks are >> surprised when their content disappears before being shutdown. This isnt >> an issue for archives because we make a copy. >> >> -- >> Jason T. Greene >> JBoss, a division of Red Hat >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >

> Dunno if it'd help, but generally supporting a deployments/myapp.link > deployment, where the myapp.link file is just a text file containing > only and exactly the path to an exploded application, might be useful. Other benefits include: 1) no complicated marker file extension state machine required.

2) it opens the door for us to deploy things that don't necessarily match "^.*\\.[SsWwJjEeRr][Aa][Rr]$", e.g. our torquebox .knob files.

Jim > > -Bob > > > > On Jul 11, 2011, at 11:00 AM, Jason T. Greene wrote: > >> On 7/11/11 9:41 AM, Max Rydahl Andersen wrote: >>> Brian, >>> >>>> This is merged (thanks!) along with a fix such that deleting the >>>> deployment content triggers undeploy[1]. >>>> >>>> [1] https://issues.jboss.org/browse/AS7-1240 >>> >>> For clarification - does this "undeploy on deleted content" only apply to zipped archives >>> or will it also happen for exploded ? >>> >>> And I assume deleting the .deploy will work in any case? >>> >> >> It only applies to things which have auto-deploy turned on. So not by >> default for exploded. Although you could turn it on and get russian >> roulette deployment. The biggest problem being that frameworks are >> surprised when their content disappears before being shutdown. This isnt >> an issue for archives because we make a copy. >> >> -- >> Jason T. Greene >> JBoss, a division of Red Hat >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

> btw. not all platforms have symlinks, nor do they work cross devices > portably so a .war|sar|ear|blah.link with the path inside would be > the best IMO. Do you mean hard links? Every modern OS I know of today has them.

>> 1) no complicated marker file extension state machine required. > > I don't see how this solution goes solve that - the underlying problem > of resources not being fully there is still present. Well, the idea is that you wouldn't copy the "symlink" until the resources were fully there, wherever that may be.

And just so we're crystal clear, Bob wasn't proposing a *real* symlink, so OS compatibilities aren't in play here. He proposed a "conceptual" or "poor man's" symlink: a simple text file, containing the path to the location of the fully-there resources.

>> 2) it opens the door for us to deploy things that don't necessarily >> match "^.*\\.[SsWwJjEeRr][Aa][Rr]$", e.g. our torquebox .knob files. > > Wouldn't this still require deploy/scanner specific code for you? Maybe, but I hope not. In AS6, we had a way (structure deployer?) to describe a valid-but-non-standard deployment artifact.

>

Max Rydahl Andersen<max.andersen(a)redhat.com> writes: [...] >>>> 2) it opens the door for us to deploy things that don't necessarily >>>> match "^.*\\.[SsWwJjEeRr][Aa][Rr]$", e.g. our torquebox .knob files. >>> >>> Wouldn't this still require deploy/scanner specific code for you? >> >> Maybe, but I hope not. In AS6, we had a way (structure deployer?) to >> describe a valid-but-non-standard deployment artifact. > > Yes, you had to add custom code hadn't you? or you mean there was a > config you could change to extend the patterns it would "scan" ? Correct: custom code, but with AS7's FileSystemDeploymentService, we can no longer do that. :(

Max Rydahl Andersen<max.andersen(a)redhat.com> writes: [...] >> 1) no complicated marker file extension state machine required. > > I don't see how this solution goes solve that - the underlying problem > of resources not being fully there is still present. Well, the idea is that you wouldn't copy the "symlink" until the resources were fully there, wherever that may be. And just so we're crystal clear, Bob wasn't proposing a *real* symlink, so OS compatibilities aren't in play here. He proposed a "conceptual" or "poor man's" symlink: a simple text file, containing the path to the location of the fully-there resources. >> 2) it opens the door for us to deploy things that don't necessarily >> match "^.*\\.[SsWwJjEeRr][Aa][Rr]$", e.g. our torquebox .knob files. > > Wouldn't this still require deploy/scanner specific code for you? Maybe, but I hope not. In AS6, we had a way (structure deployer?) to describe a valid-but-non-standard deployment artifact.

On 7/11/11 10:22 AM, Jim Crossley wrote: > Bob McWhirter<bmcwhirt(a)redhat.com> writes: > > [...] > >> Dunno if it'd help, but generally supporting a deployments/myapp.link >> deployment, where the myapp.link file is just a text file containing >> only and exactly the path to an exploded application, might be useful. > > Other benefits include: > > 1) no complicated marker file extension state machine required. > > 2) it opens the door for us to deploy things that don't necessarily > match "^.*\\.[SsWwJjEeRr][Aa][Rr]$", e.g. our torquebox .knob files. > > Yes, I know the expression is a "standard" (or is it? are .sar's > standard?), but it seems arbitrarily restrictive to those of us desirous > of the JBoss awesomeness without all the JEE goo. :) > That pattern can certainly be made configurable; I'd accept a patch for that.

I don't see how the .link thing removes the need for having the scanner understand the .knob extension, unless .link is effectively a trojan that hides the actual content location from the management system.

>>> >>> [1] https://issues.jboss.org/browse/AS7-1240 >> >> For clarification - does this "undeploy on deleted content" only apply to zipped archives >> or will it also happen for exploded ? >> >> And I assume deleting the .deploy will work in any case? >> > > It only applies to things which have auto-deploy turned on. So not by default for exploded. Although you could turn it on and get russian roulette deployment. The biggest problem being that frameworks are surprised when their content disappears before being shutdown. This isnt an issue for archives because we make a copy. Sorry, for being pedantic here but I assume you just answered the first question about "undeploy on deleted content". And that deleting the .deployed will work in any case is not yet answered ? (but I assume Yes based on your answer here ;)

On 7/11/11 10:00 AM, Jason T. Greene wrote: > On 7/11/11 9:41 AM, Max Rydahl Andersen wrote: >> Brian, >> >>> This is merged (thanks!) along with a fix such that deleting the >>> deployment content triggers undeploy[1]. >>> >>> [1] https://issues.jboss.org/browse/AS7-1240 >> >> For clarification - does this "undeploy on deleted content" only apply >> to zipped archives >> or will it also happen for exploded ? >> >> And I assume deleting the .deploy will work in any case? >> > > It only applies to things which have auto-deploy turned on. So not by > default for exploded. Not true; it happens whether or not auto-deploy is on. I suppose that's not consistent, although it is less convoluted to explain. I'll look at how big of a pain it would be to make it only happen when auto-deploy is on. Note that the trigger for undeploy is not the deletion of any file inside the exploded deployment. You have to delete the entire directory. Although you could turn it on and get russian > roulette deployment. The biggest problem being that frameworks are > surprised when their content disappears before being shutdown. This isnt > an issue for archives because we make a copy. > Enabling deletion of exploded content as a trigger for undeploy doesn't make it russian roulette. Deleting the content without undeploying first is what's russian roulette, whether or not the AS decides to undeploy after you do that. Auto-undeploying is like playing with a gun with more cylinders; still a bad idea but maybe we undeploy before your app takes a user request that blows up in weird and wonderful ways.

On 7/11/11 10:00 AM, Jason T. Greene wrote: > On 7/11/11 9:41 AM, Max Rydahl Andersen wrote: >> Brian, >> >>> This is merged (thanks!) along with a fix such that deleting the >>> deployment content triggers undeploy[1]. >>> >>> [1] https://issues.jboss.org/browse/AS7-1240 >> >> For clarification - does this "undeploy on deleted content" only apply >> to zipped archives >> or will it also happen for exploded ? >> >> And I assume deleting the .deploy will work in any case? >> > > It only applies to things which have auto-deploy turned on. So not by > default for exploded. Not true; it happens whether or not auto-deploy is on. I suppose that's not consistent, although it is less convoluted to explain. I'll look at how big of a pain it would be to make it only happen when auto-deploy is on.