<div dir="ltr"><div>I was primarily concerned with update / remove, so I'm glad to hear those two are targeted to be supported. <br><br>At this time, I don't think I have a need for read-content of multiple items, so I think we're ok there if no one else requires it. In terms of explode, I'm hard-pressed to design the API, but I'd imagine if order is critical, that it would take an array or list of paths, and explode them in the order provided, collecting the errors in some fashion to be returned at the end. Alternatively, if the server is prepared to discover all sub-deployments in an efficient manner, perhaps an integer representing max-depth, with a depth_infinite flag, would work? <br><br><br></div>Again, these are just ideas, so I defer to your judgement.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 13, 2016 at 1:16 PM, Emmanuel Hugonnet <span dir="ltr"><<a href="mailto:ehugonne@redhat.com" target="_blank">ehugonne@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well I only made the add-content (which does the update to) and remove-content support list of content.<br>
Exploding has only one file support as the order might have an impact. Maybe adding recusrive is sufficient ?<br>
read-content is also one file only has I didn't have a proper use-case for multiple targets.<br>
What do you have in mind for read-content or explode ?<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888">Emmanuel<br>
</font></span><span class="im HOEnZb"><br>
<br>
On 13/06/2016 19:07, Robert Stryker wrote:<br>
> Quick question here:<br>
><br>
> Will the various add / update / remove methods have syntax for working on multiple files at once? Or will one management call be required<br>
> for each request? Requiring a separate management call for each changed file might be pretty slow if the server being acted against is remote.<br>
><br>
</span><div class="HOEnZb"><div class="h5">> On Fri, Jun 10, 2016 at 9:38 AM, Brian Stansberry <<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a> <mailto:<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a>>> wrote:<br>
><br>
> Emmanuel Hugonnet has been working on a long requested feature to have WildFly support "managed exploded deployments." We have a<br>
> requirements analysis doc for this at <a href="https://developer.jboss.org/docs/DOC-55497" rel="noreferrer" target="_blank">https://developer.jboss.org/docs/DOC-55497</a> and I just wanted to point that out to the list so<br>
> anyone interested can have a look, and comment on this thread or on the document.<br>
><br>
> A managed deployment is one where the user provided content is copied by the server/host controller into its internal content repo and<br>
> then thereafter that copy is what is used. I estimate that 99%+ of all zipped deployments in WildFly are managed. With an unmanaged<br>
> deployment the user provides the server with the local FS path to the content and then the server directly uses that content. All<br>
> exploded deployments are unmanaged, as we don't support managed yet.<br>
><br>
> We propose to add 5 new operations to the deployment resource:<br>
><br>
> explode (to convert and archive deployment to exploded)<br>
> add-content<br>
> update-content<br>
> remove-content<br>
> read-content<br>
><br>
> 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<br>
> on this are appreciated:<br>
><br>
><br>
> "The explode operation can take an optional path parameter, the value of which is a path within the deployment that should be exploded.<br>
> * 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<br>
> be exploded.<br>
> * This is much closer to a hard requirement if the nice-to-have requirement for recursively exploding is not supported.<br>
> * This operation will fail if the content referred to by the path parameter is already exploded or is not a zip file.<br>
> * This operation will fail if any content between the root of the deployment and the content referred to by the path parameter is an<br>
> unexploded archive.<br>
> * So, /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) would fail if thewar.war hadn't previously been<br>
> exploded."<br>
><br>
> --<br>
> Brian Stansberry<br>
> Senior Principal Software Engineer<br>
> JBoss by Red Hat<br>
><br>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
><br>
<br>
</div></div><br>_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br></blockquote></div><br></div>