[wildfly-dev] Managed exploded deployments
Emmanuel Hugonnet
ehugonne at redhat.com
Mon Jun 13 13:16:30 EDT 2016
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
More information about the wildfly-dev
mailing list