[wildfly-dev] Managed exploded deployments

[Brian Stansberry]

Emmanuel,

Can you work with Alexey and Jeff to add some CLI requirements to this? 
I went on PTO and forget about our discussions in Neuchatel about being 
able to associate streams wit the add-content op. If we can't make it 
easy to do that with low level operations, we'd need a high level command.

The doc already mentions there needs to be some CLI "deploy" command 
support for starting an empty exploded deployment. Perhaps that's not 
strictly required though; a low level op could suffice. The deployment 
doesn't need to be mapped to server groups or enabled until it isn't 
empty any more.

On 6/10/16 9:24 AM, Emmanuel Hugonnet wrote:
> Some details on the current implementation :
> * the add-content will overwrite existing content so there is no update-content
> updating instead of just adding means having the state on the client as well as on the server which would require more checks to keep those
> in sync for no real value from my point of view.
> * the add-content/remove-content work with a list of contents thus for an IDE we don't have to create a bunch of ops to upload or delete
> each change.
> * you can start from an 'empty' deployment and add contents to it step by step
>
> Emmanuel
>
>
> On 10/06/2016 15:38, 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)
>> 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