-
45. Re: Thoughts on filesystem action driven hot deployment
jason.greene Nov 20, 2010 4:27 PM (in response to maxandersen)Max Andersen wrote:
There will be flag in server configuration (TBD where exactly) to
enable old style scanning for/reaction on descriptors, but will not beenabled by default. This will allow existing tooling for pre-AS7 to work sensibly.
This makes absolutely no sense to me. Existing tools will have to be updated anyway to deal with a different directory structure, different configuration files, and likely different jboss deployment descriptors. Assuming this wasn't an issue it's still off by default, so what's the point
foo.war.donotdeploy - Marker for server to ignore foo.war (used to ensure partial deployments does not happen while copying)
If we need this, we are better off just requiring a .deploy marker. It's the same number of steps, and is slightly more intuitive. Note that we can actually detect partially copied zips.
-
46. Re: Thoughts on filesystem action driven hot deployment
maxandersen Nov 20, 2010 4:57 PM (in response to jason.greene)Jason Greene wrote:
Max Andersen wrote:
There will be flag in server configuration (TBD where exactly) to
enable old style scanning for/reaction on descriptors, but will not beenabled by default. This will allow existing tooling for pre-AS7 to work sensibly.
This makes absolutely no sense to me. Existing tools will have to be updated anyway to deal with a different directory structure, different configuration files, and likely different jboss deployment descriptors.
Tools does not need to know about different structure, configuration nor deployment descriptors to deploy.
They just need to know about the destination directory - nothing else.
Assuming this wasn't an issue it's still off by default, so what's the point
The option were off by default to provide the safer "API" by default and option existed to let existing tools work with AS7...(those that works/worked with AS 3,4,5 & 6.
foo.war.donotdeploy - Marker for server to ignore foo.war (used to ensure partial deployments does not happen while copying)
If we need this, we are better off just requiring a .deploy marker. It's the same number of steps, and is slightly more intuitive. Note that we can actually detect partially copied zips.
you mean if the file is not properly zipped ? will you keep doing that on every rescan until it becomes complete ?
can you detect these partial copied zips without locking the file ?
the flag were there to have good balance between implicit and explicit control.
-
47. Re: Thoughts on filesystem action driven hot deployment
dmlloyd Nov 22, 2010 9:44 AM (in response to jason.greene)Jason Greene wrote:
jaikiran pai wrote:
I have no serious objection to telling people where deployments are stored. This is OSS after all. As we go along there should be a wiki page describing exactly how this works for a given release. I'm just doubtful about persisting it in this file. People come to count on reading the file and you can't lightly stop writing it even if it becomes a problem.
I was reading a mail about configuring Java2 security for a web application on AS5 and realized that it might have to play a role here too. Users might have to know the (consistent) location where the deployments will be extracted so that they can setup appropriate permissions.
A very good point. This should become a separate forum thread, as it affects all deployments (domain deployments) as well. We may need to somehow add this info to the domain.
I think that as long as we use a predictable code source URL for deployments it doesn't have to be a specific filesystem location (especially if it varies between expanded and non-expanded deployments). Maybe in this case, the resource loader should use a VFS URL or even a special deployment URL type (e.g. "deployment:///foo.war").
-
48. Re: Thoughts on filesystem action driven hot deployment
dmlloyd Nov 22, 2010 9:47 AM (in response to dmlloyd)David Lloyd wrote:
Jason Greene wrote:
jaikiran pai wrote:
I have no serious objection to telling people where deployments are stored. This is OSS after all. As we go along there should be a wiki page describing exactly how this works for a given release. I'm just doubtful about persisting it in this file. People come to count on reading the file and you can't lightly stop writing it even if it becomes a problem.
I was reading a mail about configuring Java2 security for a web application on AS5 and realized that it might have to play a role here too. Users might have to know the (consistent) location where the deployments will be extracted so that they can setup appropriate permissions.
A very good point. This should become a separate forum thread, as it affects all deployments (domain deployments) as well. We may need to somehow add this info to the domain.
I think that as long as we use a predictable code source URL for deployments it doesn't have to be a specific filesystem location (especially if it varies between expanded and non-expanded deployments). Maybe in this case, the resource loader should use a VFS URL or even a special deployment URL type (e.g. "deployment:///foo.war").
In other words, our internal content repository structure and location should not be a matter of public API.
-
49. Thoughts on filesystem action driven hot deployment
mvecera Feb 28, 2011 10:25 AM (in response to brian.stansberry)Hello,
I wonder if it is somehow possible to update a deployment in place. With AS6 I placed a foo.war in the deploy directory and I was still able to change it using mc for instance. I don't see such a possibility with AS7 since the original file is replaced with foo.war.deployed...
Thanks,
Martin
-
50. Thoughts on filesystem action driven hot deployment
maxandersen Feb 28, 2011 10:29 AM (in response to mvecera)That is what this suggestion is about changing
See my post from Nov 20, 2010 about the suggested layout/functionallity.
-
51. Thoughts on filesystem action driven hot deployment
brian.stansberry Mar 3, 2011 11:08 AM (in response to maxandersen)Work on this is being carried out on a branch:
https://github.com/bstansberry/jboss-as/tree/deployment-scanner
John Bailey has gotten a big chunk of the core of it done, if folks want to experiment. We need to add in exploded deployment handling (which is largely a difference in how the content is registered with the deployment repository.)
At this point we're only going to go with the marker file approach; the "legacy" approach is not robust and resources are limited so the core AS dev team will only pursue it if resources become available or its clear there is major community demand for it. (Proof of community demand would be a solid, well tested patch. )
-
52. Thoughts on filesystem action driven hot deployment
maxandersen Mar 3, 2011 11:36 AM (in response to brian.stansberry)Cool - any hudson builds or similar we can take this from or does it require getting an AS 7 build setup locally ?
btw. what counts as a community demand ?
Does the fact that about every appserver I know supports this counts ?
That every tool I know about when it comes from ant, maven, gradle, netbeans, eclipse, myeclipse, you name it won't be able to easily deploy to AS 7 ?
Of course that means everyone have to use JBoss Tools or Developer Studio (or learn the file marker api and implement that in thei ant/maven scripts until their other tooling is updated)
...of course someone could actually implement this autohotdeploy externally now by writing a filemonitor and add the touch file
-
53. Thoughts on filesystem action driven hot deployment
brian.stansberry Mar 3, 2011 11:50 AM (in response to maxandersen)At the moment people need to build the branch.
If people want the legacy mode, it's OSS; patches are welcome. There's no point arguing the merits with me; it's a resourcing issue.
-
54. Thoughts on filesystem action driven hot deployment
jason.greene Mar 3, 2011 12:18 PM (in response to brian.stansberry)A maven and ant plugin that uses the deployment API is less work, more correct, and more informative to the user. As to IDEs, the will need to be updated anyway.
-
55. Thoughts on filesystem action driven hot deployment
maxandersen Mar 3, 2011 6:33 PM (in response to jason.greene)Brian - is my posting about the file markers what got/will be implemented ? looking at the patch on github it seems not all markers and names are the same ?
Reading the code I see this:
foo.war.dodeploy - trigger deploy of archive or exploded directory.
foo.war.faileddeploy - ACK from server that deploy failed (content should contain info about reason for failure)
foo.war.deployed - ACK from server that foo.war.isdeployed.
Is thats correct/intent ?
-
56. Thoughts on filesystem action driven hot deployment
maxandersen Mar 3, 2011 6:34 PM (in response to jason.greene)Jason - if AS 7 had hotdeploy by just copying the war/ear/folder there then IDE's would not need to be updated for basic usage.
And ant doesn't really need a plugin to utilize this - users just add a <touch name="${deploy.name}.dodeploy"/> to their deployment.
Maven is tricky - I guess extending Cargo would be the option to support ? Anyone targeting/working on that ?
-
57. Thoughts on filesystem action driven hot deployment
brian.stansberry Mar 11, 2011 10:45 PM (in response to maxandersen)The foo.war.deployed was a mistake; it's now .isdeployed as we discussed in Antwerp. I told Rob I was going to do that.
The deployment-scanner branch has been pushed upstream. So any further work on this will happen from master.
The standalone/deployments dir now includes a README.txt with the following content:
The standalone/deployments directory in the JBoss Application Server
distribution is the location end users can place their deployment content
(e.g. war, ear, jar, sar files) to have it automically deployed into the server
runtime.
Users, particularly those running production systems, are encouraged to use the
JBoss AS management APIs to upload and deploy deployment content instead of
relying on the deployment scanner subsystem that periodically scans this
directory. See the JBoss AS documentation for details.
The filesystem deployment scanner in AS 7 and later works differently from
previous JBoss AS releases. The scanner will no longer attempt to directly
monitor the deployment content and decide if or when the end user wishes
the content to be deployed. Instead, the scanner relies on a system of marker
files, with the user's addition or removal of a marker file serving as a sort
of command telling the scanner to deploy, undeploy or redeploy content.
The marker files always have the same name as the deployment content to which
they relate, but with an additional file suffix appended. For example, the
marker file to indicate the example.war should be deployed is named
example.war.dodeploy. Different marker file suffixes have different meanings.
The relevant marker file types are:
.dodeploy -- Placed by the user to indicate that the given content should
be deployed into the runtime (or redeployed if already
deployed in the runtime.)
.deploying -- Placed by the deployment scanner service to indicate that it
has noticed a .dodeploy file and is in the process of
deploying the content. This marker file will be deleted when
the deployment process completes.
.isdeployed -- Placed by the deployment scanner service to indicate that the
given content has been deployed into the runtime. If an end
user deletes this file, the content will be undeployed.
.faileddeploy -- Placed by the deployment scanner service to indicate that the
given content failed to deploy into the runtime. The content
of the file will include some information about the cause of
the failure.
.undeploying -- Placed by the deployment scanner service to indicate that it
has noticed a .isdeployed file has been deleted and the
content is being undeployed. This marker file will be deleted
when the undeployment process completes.
.undeployed -- Placed by the deployment scanner service to indicate that the
given content has been undeployed from the runtime. If an end
user deletes this file, it has no impact.
Basic workflows:
All examples assume variable $AS points to the root of the JBoss AS distribution.
A) Add new zipped content and deploy it:
1. cp target/example.war/ $AS/standalone/deployment
2. touch $AS/standalone/deployment/example.war.dodeploy
B) Add new unzipped content and deploy it:
1. cp -r target/example.war/ $AS/standalone/deployment
2. touch $AS/standalone/deployment/example.war.dodeploy
C) Undeploy currently deployed content:
1. rm $AS/standalone/deployment/example.war.isdeployed
D) Replace currently deployed zipped content with a new version and deploy it:
1. cp target/example.war/ $AS/standalone/deployment
2. touch $AS/standalone/deployment/example.war.dodeploy
E) Replace currently deployed unzipped content with a new version and deploy
it:
1. rm $AS/standalone/deployment/example.war.isdeployed
2. wait for $AS/standalone/deployment/example.war.undeployed file to appear
3. cp -r target/example.war/ $AS/standalone/deployment
4. touch $AS/standalone/deployment/example.war.dodeploy
F) Redeploy currently deployed content (i.e. bounce it with no content
change):
1. touch $AS/standalone/deployment/example.war.dodeploy
-
58. Thoughts on filesystem action driven hot deployment
maxandersen Mar 14, 2011 6:14 AM (in response to brian.stansberry)Thanks for the writeup Brian, which git repo contains these fixes ?
A few questions come up with me trying these things out a bit (based on the previous as7 builds on hudson)
I've had AS7 go bad on me because of some bugs in the deployer, so bad that I couldn't startup thus I removed both the .war.deployed and .war files to trigger the undeployment....but it seem to not have an effect - it still deployed what was in the standalone.xml - I guess because it doesn't retain enough state to decide how to undeploy based on filemarkers?
This might be expected behavior, but its a bit confusing
Would you expect that putting .war.undeploy before AS7 starts up would work ?
-
59. Thoughts on filesystem action driven hot deployment
emuckenhuber Mar 14, 2011 7:01 AM (in response to maxandersen)Max Rydahl Andersen wrote:
Thanks for the writeup Brian, which git repo contains these fixes ?
It's all in upstream here: https://github.com/jbossas/jboss-as
Max Rydahl Andersen wrote:
A few questions come up with me trying these things out a bit (based on the previous as7 builds on hudson)
I've had AS7 go bad on me because of some bugs in the deployer, so bad that I couldn't startup thus I removed both the .war.deployed and .war files to trigger the undeployment....but it seem to not have an effect - it still deployed what was in the standalone.xml - I guess because it doesn't retain enough state to decide how to undeploy based on filemarkers?
This might be expected behavior, but its a bit confusing
Would you expect that putting .war.undeploy before AS7 starts up would work ?
That's the expected behavior currently. When starting up AS we first try to restore the persisted state and then check for deployment modifications. However failed deployments should get rolled back and not be persisted in standalone.xml.