[jboss-as7-dev] Intended deployemnt behavior?

[Jim Crossley]

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.

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.