<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 10, 2016 at 2:41 PM, Brian Stansberry <span dir="ltr"><<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 6/10/16 4:27 PM, James Perkins wrote:<br>
><br>
><br>
> On Fri, Jun 10, 2016 at 8:18 AM, Emmanuel Hugonnet <<a href="mailto:ehugonne@redhat.com">ehugonne@redhat.com</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:ehugonne@redhat.com">ehugonne@redhat.com</a>>> wrote:<br>
><br>
><br>
><br>
> On 10/06/2016 17:06, Brian Stansberry wrote:<br>
> > On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote:<br>
> >><br>
> >><br>
> >> On 10/06/2016 16:22, David M. Lloyd wrote:<br>
> >>> On 06/10/2016 08:38 AM, Brian Stansberry wrote:<br>
> >>>> Emmanuel Hugonnet has been working on a long requested feature<br>
> to have<br>
> >>>> WildFly support "managed exploded deployments." We have a<br>
> requirements<br>
> >>>> analysis doc for this at<br>
> <a href="https://developer.jboss.org/docs/DOC-55497" rel="noreferrer" target="_blank">https://developer.jboss.org/docs/DOC-55497</a> and<br>
> >>>> I just wanted to point that out to the list so anyone<br>
> interested can<br>
> >>>> 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<br>
> copied by<br>
> >>>> the server/host controller into its internal content repo and then<br>
> >>>> thereafter that copy is what is used. I estimate that 99%+ of<br>
> all zipped<br>
> >>>> deployments in WildFly are managed. With an unmanaged<br>
> deployment the<br>
> >>>> user provides the server with the local FS path to the content<br>
> and then<br>
> >>>> the server directly uses that content. All exploded deployments are<br>
> >>>> 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>
> >>><br>
> >>> Hmmm.<br>
> >>><br>
> >>> Is deployment explosion really an deployer concern, or is it a<br>
> >>> deployment provider concern? Consider:<br>
> >>><br>
> >>> * The deployment provider is the one who will know whether or not<br>
> >>> his/her deployment will function correctly with or without<br>
> exploding.<br>
> >>> * The deployment will have been tested in the desired configuration<br>
> >>> (exploded or unexploded).<br>
> >>> * Making this a deployer/administrator concern means that he/she<br>
> must<br>
> >>> ensure that the extra step(s) taken in development and testing<br>
> are also<br>
> >>> replicated in production.<br>
> >>><br>
> >>> Wouldn't it make more sense to have some deployment control metadata<br>
> >>> (maybe even just a MANIFEST header) that says whether the particular<br>
> >>> archive should be exploded?<br>
> >>><br>
> >>> Also, I don't think it's clear that you always want to explode<br>
> the outer<br>
> >>> archive if an inner archive is to be exploded (I'm not sure that's<br>
> >>> necessarily implied by the proposed design, but it certainly<br>
> would be in<br>
> >>> the recursive case). In particular it's definitely useful to<br>
> explode<br>
> >>> WARs inside of EARs that need not be exploded.<br>
> >>><br>
> >>> Explode!!<br>
> >>><br>
> >>> (eom)<br>
> >><br>
> >> I think the main target for explosion scenarios are tools (IDE,<br>
> build tools, etc.) in a development environment. so this mecanism is<br>
> >> transparent from the developer point of vuiew.<br>
> >> You have the same functionalities as with the scanner with<br>
> hopefully a better control over the deployment management.<br>
> >> Also this means you can develop on a remote server or even on a<br>
> domain without having to rebuild the whole archive everytime.<br>
> >><br>
> ><br>
> > So would you use the 'explode' operation in your netbeans plugin, i.e.<br>
> > start archived and explode? I'm curious if the JBDS guys will.<br>
><br>
> Well it depends. On NetBeans you have a "Deploy on Save" checkbox so<br>
> that the 'build' (since the build process it externalized in Netbeans)<br>
> will no longer produce an archive but a list of changes.<br>
> So I might need to explode the deployment somewhere in time.<br>
><br>
><br>
> I could see this being useful in a scenario where a user launches<br>
> WildFly in something like Docker but they want to see changes on static<br>
> content without a full redeploy.<br>
><br>
> If it's all local then it's already possible to do this using an<br>
> unmanaged deployment.<br>
<br>
</div></div>I think David's original point was objecting to the "explode" op which<br>
takes an existing managed archive deployment and turns it into a managed<br>
exploded deployment. He questions whether that's a valid use case to<br>
support. It wasn't about whether managed exploded deployments are a good<br>
idea at all, just whether an internal conversion operation should be<br>
supported.<br>
<br>
Managed exploded deployments have a number of benefits over unmanaged:<br>
<br>
1) Remote content administration, no local FS access required<br>
2) Automatic content replication in a managed domain.<br>
3) The content is stored in the internal repo, less likely to get messed<br>
up somehow by other user activity on the filesystem.<br>
<span class=""><br></span></blockquote><div><br></div><div>Got it. I think I misread something in there :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
><br>
><br>
><br>
> ><br>
> > I suspect it would be used as a convenience; i.e. instead of the tool<br>
> > initially uploading 100 files, it uploads a zip and explodes it. And<br>
> > then either way it begins to manipulate the few files that the tool<br>
> > regards as eligible for update without redeploy (.html, .css, etc.)<br>
><br>
> That's also a use case (depending on producing an archive in the<br>
> first place).<br>
><br>
> Emmanuel<br>
><br>
><br>
> _______________________________________________<br>
> wildfly-dev mailing list<br>
</span>> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>><br>
<span class="im HOEnZb">> <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>
><br>
><br>
> --<br>
> James R. Perkins<br>
> JBoss by Red Hat<br>
><br>
><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>
><br>
<br>
<br>
--<br>
</span><span class="im HOEnZb">Brian Stansberry<br>
Senior Principal Software Engineer<br>
JBoss by Red Hat<br>
</span><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>
</div></div></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>