[jboss-as7-dev] Intended deployemnt behavior?

[Jason T. Greene]

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.

Ok you get 2 of the 3. You do have to delete the deployed marker file to 
undeploy. I just do rm foo.war*

There was some historical reasons why we chose to require deleting the 
marker that had to do with the FS deployments state tracking and the 
management layer. Some of them may not be applicable anymore so that 
could potentially be revisited.

> I do not wish to rename marker files -- I simply won't remember those
> suffixes and the implied state machine described in that README.

You never have to rename them.

>
> 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.  :)

Totally understood, I want that to work nicely was well.

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


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