[wildfly-dev] Managed exploded deployments

[Robert Stryker]

Quick question here:

Will the various add / update / remove methods have syntax for working on
multiple files at once? Or will one management call be required for each
request? Requiring a separate management call for each changed file might
be pretty slow if the server being acted against is remote.

On Fri, Jun 10, 2016 at 9:38 AM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> Emmanuel Hugonnet has been working on a long requested feature to have
> WildFly support "managed exploded deployments." We have a requirements
> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and I
> just wanted to point that out to the list so anyone interested can have a
> look, and comment on this thread or on the document.
>
> A managed deployment is one where the user provided content is copied by
> the server/host controller into its internal content repo and then
> thereafter that copy is what is used. I estimate that 99%+ of all zipped
> deployments in WildFly are managed. With an unmanaged deployment the user
> provides the server with the local FS path to the content and then the
> server directly uses that content. All exploded deployments are unmanaged,
> as we don't support managed yet.
>
> We propose to add 5 new operations to the deployment resource:
>
> explode (to convert and archive deployment to exploded)
> add-content
> update-content
> remove-content
> read-content
>
> There is one "nice-to-have" requirement listed on the doc where I'm
> increasingly thinking it needs to be a hard requirement, so thought on this
> are appreciated:
>
>
> "The explode operation can take an optional path parameter, the value of
> which is a path within the deployment that should be exploded.
>     * The use case for this is scenarios like an exploded ear that
> contains an unexploded war, and then the user later wishes the war to be
> exploded.
>     * This is much closer to a hard requirement if the nice-to-have
> requirement for recursively exploding is not supported.
>     * This operation will fail if the content referred to by the path
> parameter is already exploded or is not a zip file.
>     * This operation will fail if any content between the root of the
> deployment and the content referred to by the path parameter is an
> unexploded archive.
>         * So,
> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) would
> fail if thewar.war hadn't previously been exploded."
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160613/aa8bb571/attachment.html