[wildfly-dev] Managed exploded deployments
James Perkins
jperkins at redhat.com
Fri Jun 10 17:46:59 EDT 2016
On Fri, Jun 10, 2016 at 2:41 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:
> On 6/10/16 4:27 PM, James Perkins wrote:
> >
> >
> > On Fri, Jun 10, 2016 at 8:18 AM, Emmanuel Hugonnet <ehugonne at redhat.com
> > <mailto: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 think David's original point was objecting to the "explode" op which
> takes an existing managed archive deployment and turns it into a managed
> exploded deployment. He questions whether that's a valid use case to
> support. It wasn't about whether managed exploded deployments are a good
> idea at all, just whether an internal conversion operation should be
> supported.
>
> Managed exploded deployments have a number of benefits over unmanaged:
>
> 1) Remote content administration, no local FS access required
> 2) Automatic content replication in a managed domain.
> 3) The content is stored in the internal repo, less likely to get messed
> up somehow by other user activity on the filesystem.
>
>
Got it. I think I misread something in there :)
> >
> >
> >
> >
> > >
> > > 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 <mailto:wildfly-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> >
> >
> > --
> > James R. Perkins
> > JBoss by Red Hat
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
>
> --
> 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
>
--
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/3eb91b05/attachment-0001.html
More information about the wildfly-dev
mailing list