[wildfly-dev] Managed exploded deployments

[James Perkins]

On Fri, Jun 10, 2016 at 8:18 AM, Emmanuel Hugonnet <ehugonne at redhat.com>
wrote:

>
>
> On 10/06/2016 17:06, Brian Stansberry wrote:
> > On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote:
> >>
> >>
> >> On 10/06/2016 16:22, David M. Lloyd wrote:
> >>> On 06/10/2016 08:38 AM, Brian Stansberry 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)
> >>>
> >>> Hmmm.
> >>>
> >>> Is deployment explosion really an deployer concern, or is it a
> >>> deployment provider concern?  Consider:
> >>>
> >>> * The deployment provider is the one who will know whether or not
> >>> his/her deployment will function correctly with or without exploding.
> >>> * The deployment will have been tested in the desired configuration
> >>> (exploded or unexploded).
> >>> * Making this a deployer/administrator concern means that he/she must
> >>> ensure that the extra step(s) taken in development and testing are also
> >>> replicated in production.
> >>>
> >>> Wouldn't it make more sense to have some deployment control metadata
> >>> (maybe even just a MANIFEST header) that says whether the particular
> >>> archive should be exploded?
> >>>
> >>> Also, I don't think it's clear that you always want to explode the
> outer
> >>> archive if an inner archive is to be exploded (I'm not sure that's
> >>> necessarily implied by the proposed design, but it certainly would be
> in
> >>> the recursive case).  In particular it's definitely useful to explode
> >>> WARs inside of EARs that need not be exploded.
> >>>
> >>> Explode!!
> >>>
> >>> (eom)
> >>
> >> I think the main target for explosion scenarios are tools (IDE, build
> tools, etc.) in a development environment. so this mecanism is
> >> transparent from the developer point of vuiew.
> >> You have the same functionalities as with the scanner with hopefully a
> better control over the deployment management.
> >> Also this means you can develop on a remote server or even on a domain
> without having to rebuild the whole archive everytime.
> >>
> >
> > So would you use the 'explode' operation in your netbeans plugin, i.e.
> > start archived and explode? I'm curious if the JBDS guys will.
>
> Well it depends. On NetBeans you have a "Deploy on Save" checkbox so that
> the 'build' (since the build process it externalized in Netbeans)
> will no longer produce an archive but a list of changes.
> So I might need to explode the deployment somewhere in time.
>

I could see this being useful in a scenario where a user launches WildFly
in something like Docker but they want to see changes on static content
without a full redeploy.

If it's all local then it's already possible to do this using an unmanaged
deployment.


>
>
> >
> > I suspect it would be used as a convenience; i.e. instead of the tool
> > initially uploading 100 files, it uploads a zip and explodes it. And
> > then either way it begins to manipulate the few files that the tool
> > regards as eligible for update without redeploy (.html, .css, etc.)
>
> That's also a use case (depending on producing an archive in the first
> place).
>
> Emmanuel
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/e0fa0aa5/attachment-0001.html