Re: [wildfly-dev] Managed exploded deployments

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." >> > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev