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