[jboss-as7-dev] Intended deployemnt behavior?

[Jason T. Greene]

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


-- 
Jason T. Greene
JBoss, a division of Red Hat