[wildfly-dev] Managed exploded deployments
Emmanuel Hugonnet
ehugonne at redhat.com
Fri Jun 10 10:39:38 EDT 2016
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.
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."
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/e9d59a8a/attachment.bin
More information about the wildfly-dev
mailing list