[wildfly-dev] Managed exploded deployments

[Brian Stansberry]

On 6/10/16 9:22 AM, 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.
>

The admin already has this capability; they can just convert a zip to 
unmanaged exploded and redeploy.  Granted, this op makes it easier to do 
and bypasses limitations that currently exist like the need for said 
admin to write to the local FS.

> 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?
>

This one gives me a not so nice feeling, as now we are taking things 
typically done by DUPs (analyzing deployment structure, extracting 
files, parsing) and doing it in a different area.

> 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.
>

There's a lot of complexity that comes from allowing the parent to be an 
archive and the child exploded. And I don't see a huge benefit. How much 
unzipped child content do ears have? Mostly a few deployments 
descriptors and a manifest.

I certainly see a benefit though in having the parent and 1 child 
exploded while all other children remain as zips.


> Explode!!
>
> (eom)
>
>> add-content
>> update-content
>> remove-content
>> read-content
>>
>> 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 on
>> this are appreciated:
>>
>>
>> "The explode operation can take an optional path parameter, the value of
>> which is a path within the deployment that should be exploded.
>>       * 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 be
>> exploded.
>>       * This is much closer to a hard requirement if the nice-to-have
>> requirement for recursively exploding is not supported.
>>       * This operation will fail if the content referred to by the path
>> parameter is already exploded or is not a zip file.
>>       * This operation will fail if any content between the root of the
>> deployment and the content referred to by the path parameter is an
>> unexploded archive.
>>           * So,
>> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
>> would fail if thewar.war hadn't previously been exploded."
>>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat