<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 10, 2016 at 7:24 AM, Emmanuel Hugonnet <span dir="ltr">&lt;<a href="mailto:ehugonne@redhat.com" target="_blank">ehugonne@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Some details on the current implementation :<br>
* the add-content will overwrite existing content so there is no update-content<br>
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<br>
in sync for no real value from my point of view.<br></blockquote><div><br></div><div>I think there should be a force attribute, or something along those lines, that can be changed to indicate an add shouldn&#39;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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* the add-content/remove-content work with a list of contents thus for an IDE we don&#39;t have to create a bunch of ops to upload or delete<br>
each change.<br>
* you can start from an &#39;empty&#39; deployment and add contents to it step by step<br>
<span class="HOEnZb"><font color="#888888"><br>
Emmanuel<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 10/06/2016 15:38, Brian Stansberry wrote:<br>
&gt; Emmanuel Hugonnet has been working on a long requested feature to have<br>
&gt; WildFly support &quot;managed exploded deployments.&quot; We have a requirements<br>
&gt; 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<br>
&gt; I just wanted to point that out to the list so anyone interested can<br>
&gt; have a look, and comment on this thread or on the document.<br>
&gt;<br>
&gt; A managed deployment is one where the user provided content is copied by<br>
&gt; the server/host controller into its internal content repo and then<br>
&gt; thereafter that copy is what is used. I estimate that 99%+ of all zipped<br>
&gt; deployments in WildFly are managed. With an unmanaged deployment the<br>
&gt; user provides the server with the local FS path to the content and then<br>
&gt; the server directly uses that content. All exploded deployments are<br>
&gt; unmanaged, as we don&#39;t support managed yet.<br>
&gt;<br>
&gt; We propose to add 5 new operations to the deployment resource:<br>
&gt;<br>
&gt; explode (to convert and archive deployment to exploded)<br>
&gt; add-content<br>
&gt; update-content<br>
&gt; remove-content<br>
&gt; read-content<br>
&gt;<br>
&gt; There is one &quot;nice-to-have&quot; requirement listed on the doc where I&#39;m<br>
&gt; increasingly thinking it needs to be a hard requirement, so thought on<br>
&gt; this are appreciated:<br>
&gt;<br>
&gt;<br>
&gt; &quot;The explode operation can take an optional path parameter, the value of<br>
&gt; which is a path within the deployment that should be exploded.<br>
&gt;      * The use case for this is scenarios like an exploded ear that<br>
&gt; contains an unexploded war, and then the user later wishes the war to be<br>
&gt; exploded.<br>
&gt;      * This is much closer to a hard requirement if the nice-to-have<br>
&gt; requirement for recursively exploding is not supported.<br>
&gt;      * This operation will fail if the content referred to by the path<br>
&gt; parameter is already exploded or is not a zip file.<br>
&gt;      * This operation will fail if any content between the root of the<br>
&gt; deployment and the content referred to by the path parameter is an<br>
&gt; unexploded archive.<br>
&gt;          * So,<br>
&gt; /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)<br>
&gt; would fail if thewar.war hadn&#39;t previously been exploded.&quot;<br>
&gt;<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><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>James R. Perkins</div><div>JBoss by Red Hat</div></div></div></div></div>
</div></div>