[wildfly-dev] Managed exploded deployments

[David M. Lloyd]

Just had an offline discussion with Emmanuel and he cleared up some 
things for me.  Turns out my recollection of how managed deployments 
work was faulty (surprise!)... IOW carry on, nothing to see here :-)

On 06/13/2016 08:16 AM, David M. Lloyd wrote:
> 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