[jboss-as7-dev] Intended deployemnt behavior?

Fri Jul 8 18:38:48 EDT 2011

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