[wildfly-dev] Managed exploded deployments

[David M. Lloyd]

On 06/10/2016 10:16 AM, Brian Stansberry wrote:
> 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.

Sure, but I think that creates a false equivalency between unmanaged 
deployments and exploded deployments.  Managed deployments have many 
advantages.  Exploded deployments on the other hand have key functional 
differences at run time (consider the case we used to discuss all the 
time: servlets which call ServletContext.getRealPath() and expect to get 
a non-null answer).  If the answer to a given problem is "use an 
unmanaged deployment" then I think we have a deficiency with managed 
deployments, which were IMO always meant to be the primary deployment 
function for most apps; unmanaged deployments were meant to be a 
combination of convenience feature and continuation of capabilities from 
previous JBoss AS generations.

That said, I think the IDE case (of dynamic content updates) is 
completely legitimate, and honestly one I did not think of.  So maybe 
the right thing is to support both an operation set as Emmanuel 
proposes, *and* a deployment flag that can be set an a per-archive 
basis, which would meet all the use cases.

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

Not necessarily - it could be a simple as adding a DUP step which 
examines the descriptor and pokes the VFS mount so that at run time, the 
deployment is exploded.  That would satisfy the run-time requirements 
without impacting the implementation of the proposed management 
operation(s).

>> 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 don't think you need to actively prevent a recursive explode 
situation, but I think it's just not always necessary and using the DUP 
approach it's easier to just explode individual pieces.  But using the 
management operation approach, the opposite is true, as addressing 
interior components is more complex than just recursively exploding the 
whole thing.

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

Sure.

-- 
- DML