[jboss-as7-dev] Intended deployemnt behavior?

[Jim Crossley]

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
>>>
>>>
>>
>>