]
Jason Greene commented on WFCORE-429:
-------------------------------------
We should definitely sort out the requirements. We have 3 types of deployments:
1) Exploded - picked up by the file scanner (which hot redeploys), development only, and
standalone mode only
2) Managed - deployed to standalone and domain mode, and stored in the content
repository, indexed by the SHA of the deployment content
3) External - A reference in the configuration to an external file system location. This
doesn't use the scanner, and it doesn't involve the content repository. It's
usable in standalone and domain mode, and in both cases its the user's responsibility
to copy the files over to all of the servers that reference it from the configuration.
One key requirement in EAP7-204, is that changes *must* survive a restart.
Incremental redeployment (single file update) over management API
-----------------------------------------------------------------
Key: WFCORE-429
URL:
https://issues.jboss.org/browse/WFCORE-429
Project: WildFly Core
Issue Type: Feature Request
Components: CLI, Domain Management
Reporter: Ondrej Zizka
Labels: deploy, deployment, incremental, redeployment
(Based on JBDS use case - see EAP6-1)
See also
https://mojo.redhat.com/docs/DOC-934058 for notes
By incremental redeployment, we mean the situation when something is deployed, and after
changes (in IDE e.g.), only that single file (.jsp, .xml, .class) would be re-deployed to
the server, *over management API* - which is, you'd give it a stream and a path where
it belongs in the deployment, and the operation would accept that file and put it to the
right place in VFS, clear caches etc.
Use cases:
Big .war's, mainly on remote
Cloud deployments
Also, you loose sessions etc.
"JSP recompile on file update" - mgmt API operation - added in WildFly 8?
Not expected to work in domain mode.
Stuart said that session persistence is implemented in WFly 8, but not the incremental
redeployment.