1 Reply Latest reply on Sep 25, 2019 7:41 AM by 4036528

    REST update deployment by uploading client-side file

    4036528

      Hello,

       

      I'm looking at the option to update deployments via REST API, uploading the file in the request.

      I already found a way to do a deploy using Content-Type multipart/form-data at /management/weblogic/{version}/edit/appDeployments, I'm looking for something similar to update existing deployments.

      A simple delete/deploy does no good as we want to do a graceful retirement, leaving chance for any current sessions to finish their job.

       

      Is there such an option? Is there actually an update option that does more than update the deployment plan?

      In the domain runtime reference I can only see update options that update the configuration (that is, the deployment plan).

      https://docs.oracle.com/middleware/1221/wls/WLROM/resources.htm

       

      WLS version 12.2.1.3

        • 1. Re: REST update deployment by uploading client-side file
          4036528

          With some trial and error, I think I've found the answer.

          To deploy a new version of an existing application, the application has to actually be versioned. One can define a version in the REST URL like this for example:

          POST http://{adminHost}:{adminPort}/management/weblogic/latest/edit/appDeployments/{appName}#{appVersion}

          Weblogic automatically parses the version number and handles it, which means:

          • the application will have an archive version (on the admin console), or versionIdentifier (via REST API)
          • if there is an application of that name, the new version will be deployed while the old version will be retired (same as updating via console)
          • if there already are two versions, the REST call will return with an error
          • from what I could tell, the old version is retired gracefully (as this is the default in Weblogic), though I didn't do any specific tests on this
          • I have no idea currently if there is a built-in retire control via REST (it might be that it must be implemented manually, eg. wait for {timeout} seconds then force-stop / undeploy via another REST call)