1 2 3 4 5 6 Previous Next 132 Replies Latest reply: Apr 18, 2011 3:13 PM by Brian Stansberry Go to original post RSS
  • 45. Re: Thoughts on filesystem action driven hot deployment
    Jason Greene Master

    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 be

    enabled 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
    Max Rydahl Andersen Master

    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 be

    enabled 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
    David Lloyd Master

    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
    David Lloyd Master

    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
    Martin Vecera Novice

    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
    Max Rydahl Andersen Master

    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 Master

    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
    Max Rydahl Andersen Master

    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 Master

    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 Master

    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
    Max Rydahl Andersen Master

    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
    Max Rydahl Andersen Master

    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 Master

    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
    Max Rydahl Andersen Master

    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
    Emanuel Muckenhuber Master

    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.

1 2 3 4 5 6 Previous Next