[jboss-as7-dev] Intended deployemnt behavior?

[Jason T. Greene]

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