[jboss-as7-dev] Intended deployemnt behavior?

[Brian Stansberry]

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.

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


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat