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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat