[wildfly-dev] Managed exploded deployments

[Brian Stansberry]

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

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat