[jboss-as7-dev] Intended deployemnt behavior?

[Brian Stansberry]

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


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat