[wildfly-dev] Managed exploded deployments

[Emmanuel Hugonnet]

Well I only made the add-content (which does the update to) and remove-content support list of content.
Exploding has only one file support as the order might have an impact. Maybe adding recusrive is sufficient ?
read-content is also one file only has I didn't have a proper use-case for multiple targets.
What do you have in mind for read-content or explode ?
Cheers
Emmanuel


On 13/06/2016 19:07, Robert Stryker wrote:
> 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 <mailto: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
> 
> 
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160613/36c092dd/attachment.bin