[jboss-as7-dev] Intended deployemnt behavior?

[Brian Stansberry]

On 7/8/11 2:07 PM, Brian Stansberry wrote:
> 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.

I misspoke; to undeploy you have to delete the .deployed marker. I'll 
think about whether that requirement can be eliminated.

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