[wildfly-dev] Managed exploded deployments

[Brian Stansberry]

On 6/10/16 4:20 PM, James Perkins wrote:
>
>
> On Fri, Jun 10, 2016 at 7:24 AM, Emmanuel Hugonnet <ehugonne at redhat.com
> <mailto:ehugonne at redhat.com>> wrote:
>
>     Some details on the current implementation :
>     * the add-content will overwrite existing content so there is no
>     update-content
>     updating instead of just adding means having the state on the client
>     as well as on the server which would require more checks to keep those
>     in sync for no real value from my point of view.
>
>
> I think there should be a force attribute, or something along those
> lines, that can be changed to indicate an add shouldn't override. It can
> default to false, but there are probably scenarios where you would want
> an add to fail of the content already exists.

In that case, we should have an op called "update-content". :)

Oh, I think you meant the default should be 'force=true', so by default 
add can update but the user can turn that off.

>
>
>     * the add-content/remove-content work with a list of contents thus
>     for an IDE we don't have to create a bunch of ops to upload or delete
>     each change.
>     * you can start from an 'empty' deployment and add contents to it
>     step by step
>
>     Emmanuel
>
>
>     On 10/06/2016 15:38, Brian Stansberry 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."
>     >
>
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat