Intended deployemnt behavior?

classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Intended deployemnt behavior?

Bill Burke
Maybe I'm just not supposed to do it this way but:

1) I deployed a bad war, bot a deployment error
2) I fixed the problem, re-copied the war to the deployments directory
3) The war deployment was skipped on restart (I'm guessing because there
is a mywar.war.failed file in the deploy directory.

Is this intended behavior?  Seems like it could cause a lot of problems.
  In the minimum, AS7 should check to see if the date of the .failed or
.deployed file is older than the actual deployment file.

I'll log a JIRA if u agree.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Rémy Maucherat
On Fri, 2011-07-08 at 09:38 -0400, Bill Burke wrote:

> Maybe I'm just not supposed to do it this way but:
>
> 1) I deployed a bad war, bot a deployment error
> 2) I fixed the problem, re-copied the war to the deployments directory
> 3) The war deployment was skipped on restart (I'm guessing because there
> is a mywar.war.failed file in the deploy directory.
>
> Is this intended behavior?  Seems like it could cause a lot of problems.
>   In the minimum, AS7 should check to see if the date of the .failed or
> .deployed file is older than the actual deployment file.
>
> I'll log a JIRA if u agree.

Delete the ".failed" marker and it should attempt deploying it.

--
Remy Maucherat <[hidden email]>
Red Hat Inc

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Heiko Braun
In reply to this post by Bill Burke


As a side note:

Users are not advised to use the file system deployment mechanism.
This is intended to be used by deployment tools that properly deal with all the
marker files (eclipse, maven). Users should either rely on the CLI or the web interface to deploy applications:

https://docs.jboss.org/author/display/AS7/Admin+Guide


Ike



On Jul 8, 2011, at 3:38 PM, Bill Burke wrote:

> Maybe I'm just not supposed to do it this way but:
>
> 1) I deployed a bad war, bot a deployment error
> 2) I fixed the problem, re-copied the war to the deployments directory
> 3) The war deployment was skipped on restart (I'm guessing because there
> is a mywar.war.failed file in the deploy directory.
>
> Is this intended behavior?  Seems like it could cause a lot of problems.
>  In the minimum, AS7 should check to see if the date of the .failed or
> .deployed file is older than the actual deployment file.
>
> I'll log a JIRA if u agree.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Jaikiran Pai
Although, we should encourage users to use CLI or web interface, IMO,
many users would still prefer file system based deployments since it
doesn't require the server to be started and is also pretty simple to
"deploy".

-Jaikiran
On Friday 08 July 2011 07:14 PM, Heiko Braun wrote:

>
>
> As a side note:
>
> Users are not advised to use the file system deployment mechanism.
> This is intended to be used by deployment tools that properly deal with all the
> marker files (eclipse, maven). Users should either rely on the CLI or the web interface to deploy applications:
>
> https://docs.jboss.org/author/display/AS7/Admin+Guide
>
>
> Ike
>
>
>
> On Jul 8, 2011, at 3:38 PM, Bill Burke wrote:
>
>> Maybe I'm just not supposed to do it this way but:
>>
>> 1) I deployed a bad war, bot a deployment error
>> 2) I fixed the problem, re-copied the war to the deployments directory
>> 3) The war deployment was skipped on restart (I'm guessing because there
>> is a mywar.war.failed file in the deploy directory.
>>
>> Is this intended behavior?  Seems like it could cause a lot of problems.
>>   In the minimum, AS7 should check to see if the date of the .failed or
>> .deployed file is older than the actual deployment file.
>>
>> I'll log a JIRA if u agree.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Bill Burke
In reply to this post by Heiko Braun
I don't care that much, but you've turned us into Websphere.  Maybe I'm
just too old school...

On 7/8/11 9:44 AM, Heiko Braun wrote:

>
>
> As a side note:
>
> Users are not advised to use the file system deployment mechanism.
> This is intended to be used by deployment tools that properly deal with all the
> marker files (eclipse, maven). Users should either rely on the CLI or the web interface to deploy applications:
>
> https://docs.jboss.org/author/display/AS7/Admin+Guide
>
>
> Ike
>
>
>
> On Jul 8, 2011, at 3:38 PM, Bill Burke wrote:
>
>> Maybe I'm just not supposed to do it this way but:
>>
>> 1) I deployed a bad war, bot a deployment error
>> 2) I fixed the problem, re-copied the war to the deployments directory
>> 3) The war deployment was skipped on restart (I'm guessing because there
>> is a mywar.war.failed file in the deploy directory.
>>
>> Is this intended behavior?  Seems like it could cause a lot of problems.
>>   In the minimum, AS7 should check to see if the date of the .failed or
>> .deployed file is older than the actual deployment file.
>>
>> I'll log a JIRA if u agree.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Heiko Braun
In reply to this post by Jaikiran Pai

Well, in fact it's not.
If it would be simple then people like Bill would not face the problems he describes.

Ike

On Jul 8, 2011, at 3:46 PM, Jaikiran Pai wrote:

> IMO,
> many users would still prefer file system based deployments since it
> doesn't require the server to be started and is also pretty simple to
> "deploy".


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Heiko Braun
In reply to this post by Bill Burke



don't know. do you still listen to "the police"?

On Jul 8, 2011, at 3:48 PM, Bill Burke wrote:

> Maybe I'm just too old school...

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Jaikiran Pai
In reply to this post by Heiko Braun
On Friday 08 July 2011 07:22 PM, Heiko Braun wrote:
>
> Well, in fact it's not.
> If it would be simple then people like Bill would not face the problems he describes.
>
And that's what we have to fix. And by fix I mean we should atleast be
able to have the same kind of stability that we had in previous versions
of AS. I know file system deployments had some specific issues in
previous versions when it came to hot deployment, but those were very
specific issues.

-Jaikiran
> Ike
>
> On Jul 8, 2011, at 3:46 PM, Jaikiran Pai wrote:
>
>> IMO,
>> many users would still prefer file system based deployments since it
>> doesn't require the server to be started and is also pretty simple to
>> "deploy".
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

David Lloyd-2
In reply to this post by Jaikiran Pai
I agree, the filesystem deployment mechanism should be something users
are free to use if they wish.

The real solution to the current issues is to make FS deployments be
"unmanaged" (inasmuch as they don't appear in the configuration model,
but can still be queried at runtime as much as any deployment can be).

This is something we've talked about fixing for 7.1 (or maybe 7.2, given
the current priorities for 7.1).

On 07/08/2011 08:46 AM, Jaikiran Pai wrote:

> Although, we should encourage users to use CLI or web interface, IMO,
> many users would still prefer file system based deployments since it
> doesn't require the server to be started and is also pretty simple to
> "deploy".
>
> -Jaikiran
> On Friday 08 July 2011 07:14 PM, Heiko Braun wrote:
>>
>>
>> As a side note:
>>
>> Users are not advised to use the file system deployment mechanism.
>> This is intended to be used by deployment tools that properly deal with all the
>> marker files (eclipse, maven). Users should either rely on the CLI or the web interface to deploy applications:
>>
>> https://docs.jboss.org/author/display/AS7/Admin+Guide
>>
>>
>> Ike
>>
>>
>>
>> On Jul 8, 2011, at 3:38 PM, Bill Burke wrote:
>>
>>> Maybe I'm just not supposed to do it this way but:
>>>
>>> 1) I deployed a bad war, bot a deployment error
>>> 2) I fixed the problem, re-copied the war to the deployments directory
>>> 3) The war deployment was skipped on restart (I'm guessing because there
>>> is a mywar.war.failed file in the deploy directory.
>>>
>>> Is this intended behavior?  Seems like it could cause a lot of problems.
>>>    In the minimum, AS7 should check to see if the date of the .failed or
>>> .deployed file is older than the actual deployment file.
>>>
>>> I'll log a JIRA if u agree.
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Jim Crossley
In reply to this post by Jaikiran Pai
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?

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.

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.

I say let the deployment tools (eclipse, maven, etc) use the CLI/API and
bring back the old deployments dir.

And keep those kids off my lawn!  ;)

$.02
Jim


Jaikiran Pai <[hidden email]> writes:

> Although, we should encourage users to use CLI or web interface, IMO,
> many users would still prefer file system based deployments since it
> doesn't require the server to be started and is also pretty simple to
> "deploy".
>
> -Jaikiran
> On Friday 08 July 2011 07:14 PM, Heiko Braun wrote:
>>
>>
>> As a side note:
>>
>> Users are not advised to use the file system deployment mechanism.
>> This is intended to be used by deployment tools that properly deal with all the
>> marker files (eclipse, maven). Users should either rely on the CLI or the web interface to deploy applications:
>>
>> https://docs.jboss.org/author/display/AS7/Admin+Guide
>>
>>
>> Ike
>>
>>
>>
>> On Jul 8, 2011, at 3:38 PM, Bill Burke wrote:
>>
>>> Maybe I'm just not supposed to do it this way but:
>>>
>>> 1) I deployed a bad war, bot a deployment error
>>> 2) I fixed the problem, re-copied the war to the deployments directory
>>> 3) The war deployment was skipped on restart (I'm guessing because there
>>> is a mywar.war.failed file in the deploy directory.
>>>
>>> Is this intended behavior?  Seems like it could cause a lot of problems.
>>>   In the minimum, AS7 should check to see if the date of the .failed or
>>> .deployed file is older than the actual deployment file.
>>>
>>> I'll log a JIRA if u agree.
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Scott Marlow


On 07/08/2011 10: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?
>
> 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.
>
> 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.

This sounds like a simple add-on that could be independent of AS7 (e.g.
create an external process that scans some file system location for
legacy deployment type actions and turns them into the new actions.)

>
> I say let the deployment tools (eclipse, maven, etc) use the CLI/API and
> bring back the old deployments dir.
>
> And keep those kids off my lawn!  ;)
>
> $.02
> Jim
>
>
> Jaikiran Pai<[hidden email]>  writes:
>
>> Although, we should encourage users to use CLI or web interface, IMO,
>> many users would still prefer file system based deployments since it
>> doesn't require the server to be started and is also pretty simple to
>> "deploy".
>>
>> -Jaikiran
>> On Friday 08 July 2011 07:14 PM, Heiko Braun wrote:
>>>
>>>
>>> As a side note:
>>>
>>> Users are not advised to use the file system deployment mechanism.
>>> This is intended to be used by deployment tools that properly deal with all the
>>> marker files (eclipse, maven). Users should either rely on the CLI or the web interface to deploy applications:
>>>
>>> https://docs.jboss.org/author/display/AS7/Admin+Guide
>>>
>>>
>>> Ike
>>>
>>>
>>>
>>> On Jul 8, 2011, at 3:38 PM, Bill Burke wrote:
>>>
>>>> Maybe I'm just not supposed to do it this way but:
>>>>
>>>> 1) I deployed a bad war, bot a deployment error
>>>> 2) I fixed the problem, re-copied the war to the deployments directory
>>>> 3) The war deployment was skipped on restart (I'm guessing because there
>>>> is a mywar.war.failed file in the deploy directory.
>>>>
>>>> Is this intended behavior?  Seems like it could cause a lot of problems.
>>>>    In the minimum, AS7 should check to see if the date of the .failed or
>>>> .deployed file is older than the actual deployment file.
>>>>
>>>> I'll log a JIRA if u agree.
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Brian Stansberry
In reply to this post by Bill Burke
Geez, a lot of discussion. Bill, can you please file a JIRA.

There's some commented out code related to retrying a deployment with a
.failed marker if the timestamp of the underlying file changed. TBH I
don't recall why it was commented out, but I agree it should work if at
all possible so it's worth another try.

On 7/8/11 8:38 AM, Bill Burke wrote:

> Maybe I'm just not supposed to do it this way but:
>
> 1) I deployed a bad war, bot a deployment error
> 2) I fixed the problem, re-copied the war to the deployments directory
> 3) The war deployment was skipped on restart (I'm guessing because there
> is a mywar.war.failed file in the deploy directory.
>
> Is this intended behavior?  Seems like it could cause a lot of problems.
>    In the minimum, AS7 should check to see if the date of the .failed or
> .deployed file is older than the actual deployment file.
>
> I'll log a JIRA if u agree.
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Brian Stansberry
In reply to this post by David Lloyd-2
On 7/8/11 9:13 AM, David M. Lloyd wrote:

> I agree, the filesystem deployment mechanism should be something users
> are free to use if they wish.
>
> The real solution to the current issues is to make FS deployments be
> "unmanaged" (inasmuch as they don't appear in the configuration model,
> but can still be queried at runtime as much as any deployment can be).
>
> This is something we've talked about fixing for 7.1 (or maybe 7.2, given
> the current priorities for 7.1).
>

John Bailey already implemented this for 7.0.0.CR1.

> On 07/08/2011 08:46 AM, Jaikiran Pai wrote:
>> Although, we should encourage users to use CLI or web interface, IMO,
>> many users would still prefer file system based deployments since it
>> doesn't require the server to be started and is also pretty simple to
>> "deploy".
>>
>> -Jaikiran
>> On Friday 08 July 2011 07:14 PM, Heiko Braun wrote:
>>>
>>>
>>> As a side note:
>>>
>>> Users are not advised to use the file system deployment mechanism.
>>> This is intended to be used by deployment tools that properly deal with all the
>>> marker files (eclipse, maven). Users should either rely on the CLI or the web interface to deploy applications:
>>>
>>> https://docs.jboss.org/author/display/AS7/Admin+Guide
>>>
>>>
>>> Ike
>>>
>>>
>>>
>>> On Jul 8, 2011, at 3:38 PM, Bill Burke wrote:
>>>
>>>> Maybe I'm just not supposed to do it this way but:
>>>>
>>>> 1) I deployed a bad war, bot a deployment error
>>>> 2) I fixed the problem, re-copied the war to the deployments directory
>>>> 3) The war deployment was skipped on restart (I'm guessing because there
>>>> is a mywar.war.failed file in the deploy directory.
>>>>
>>>> Is this intended behavior?  Seems like it could cause a lot of problems.
>>>>     In the minimum, AS7 should check to see if the date of the .failed or
>>>> .deployed file is older than the actual deployment file.
>>>>
>>>> I'll log a JIRA if u agree.
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

jtgreene
Administrator
In reply to this post by Jim Crossley
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
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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" <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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"<[hidden email]>  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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

jtgreene
Administrator
In reply to this post by Jim Crossley
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.

Ok you get 2 of the 3. You do have to delete the deployed marker file to
undeploy. I just do rm foo.war*

There was some historical reasons why we chose to require deleting the
marker that had to do with the FS deployments state tracking and the
management layer. Some of them may not be applicable anymore so that
could potentially be revisited.

> I do not wish to rename marker files -- I simply won't remember those
> suffixes and the implied state machine described in that README.

You never have to rename them.

>
> 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.  :)

Totally understood, I want that to work nicely was well.

> Thanks,
> Jim
>
>
> "Jason T. Greene"<[hidden email]>  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.


--
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Brian Stansberry
In reply to this post by 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"<[hidden email]>   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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Brian Stansberry
On 7/8/11 2:12 PM, Brian Stansberry wrote:

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

Looks like it can be.

The rationale for requiring deleting the .deployed marker to trigger
undeploy was because of the exploded deployment case.

Zipped deployments, we copy off to a tmp directory and serve the app
from that copy. So you can delete the original version in deployments/
and cause no harm. But, we server exploded deployments directly from the
deployments/ dir. This allows things to work like swapping in a new
version of a .html file and having it be picked up without redeploying
the whole app.

Deleting an exploded deployment to undeploy it is the wrong thing to do,
because the deployment content has disappeared out from under the
appserver before it has any chance to do a proper undeploy. So we said
"don't do that, and to encourage you to do it right, the rule is you
have to delete the .deployed marker to undeploy."

Well, now that rule effects zipped archives as well, for no good reason.
And for exploded content there's no reason we can't try and undeploy if
you delete the content. Deleting the .deployed marker first *is the
right thing to do*. But if people mess up and delete the content first,
as soon as they do that they've broken their app so we might as well go
ahead and undeploy.

>>
>> 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"<[hidden email]>    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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intended deployemnt behavior?

Jim Crossley
Thanks Brian/Jason,

I'm tickled pink to hear you guys say it should work exactly like I
expect.

Unfortunately, it doesn't yet, so per your request:
https://issues.jboss.org/browse/AS7-1237

Let me know if the steps to reproduce are unclear.  I used a bone-stupid
war file to test.  I'll attach it if need be.

Thanks again,
Jim


Brian Stansberry <[hidden email]> writes:

> On 7/8/11 2:12 PM, Brian Stansberry wrote:
>> 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.
>>
>
> Looks like it can be.
>
> The rationale for requiring deleting the .deployed marker to trigger
> undeploy was because of the exploded deployment case.
>
> Zipped deployments, we copy off to a tmp directory and serve the app
> from that copy. So you can delete the original version in deployments/
> and cause no harm. But, we server exploded deployments directly from the
> deployments/ dir. This allows things to work like swapping in a new
> version of a .html file and having it be picked up without redeploying
> the whole app.
>
> Deleting an exploded deployment to undeploy it is the wrong thing to do,
> because the deployment content has disappeared out from under the
> appserver before it has any chance to do a proper undeploy. So we said
> "don't do that, and to encourage you to do it right, the rule is you
> have to delete the .deployed marker to undeploy."
>
> Well, now that rule effects zipped archives as well, for no good reason.
> And for exploded content there's no reason we can't try and undeploy if
> you delete the content. Deleting the .deployed marker first *is the
> right thing to do*. But if people mess up and delete the content first,
> as soon as they do that they've broken their app so we might as well go
> ahead and undeploy.
>
>>>
>>> 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"<[hidden email]>    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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>
>>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
123