[wildfly-dev] Managed exploded deployments

[Brian Stansberry]

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.

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

> Emmanuel
>
>>
>>> 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."
>>>
>>
>
>
>
> _______________________________________________
> 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