[jboss-as7-dev] Intended deployemnt behavior?

Jason Greene jgreene at redhat.com
Fri Jul 8 20:22:13 EDT 2011 

Right, the archives need to behave as before. We already verify the integrity of the zip before deploying to catch the case of a partial copy. 

We originally had the marker inside the exploded dir but feedback from max and a few other users was that it was nicer having it outside next to the status markers so it was consistent. 

Sent from my iPhone

On Jul 8, 2011, at 5:39 PM, Bill Burke <bburke at redhat.com> wrote:

> 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 at 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 at 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 at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

More information about the jboss-as7-dev mailing list