| Item |
Type |
File |
Comment |
Response |
| 1 |
Correction |
Deployment |
In section 4.1 of Deploymentv3PreludeOnePager (version 2) : provide link to the relevant doc. |
one-pager updated - the doc link is added |
| 2 |
Compatibility Issue |
|
changing the default value of the force flag from true to false will cause problems for existing user scripts. How will existing V2 users benefit from this change? |
one-pager updated - safer operation, prevent user from overwriting original application accidentally |
| 3 |
Compatibility Issue |
|
changing the deployment location of web modules to a new location. How will existing V2 users benefit from this change? |
one-pager updated - simplify implementation, while v2 user may not benefit much, the new v3 user will have a uniform place to look for all types of applications |
| 4 |
Clarification |
|
Is JSR-88 supported? It isn't clear. |
one-pager updated - JSR88 not available in this release, but will be in next v3 release |
| 5 |
Correction |
|
The semantics of redeploy are poorly described. Please provide a more complete explanation of the functionality |
Please clarify what type of information you would like to see. The detailed syntax of the redeploy command will be documented in the man page. |
| 6 |
RFE |
|
Please make it possible to use the redeploy command without the 'path' option in situations where the user has deployed an archive. Forcing the user to reenter data (sometimes) seems like a bad idea. |
This decision was made by intention. In case of archive redeployment, how do we know where to get/upload the latest archive? |
| 7 |
Correction |
|
there is no mention of the HTTP based deployment capabilities. This is a new, complex feature/interface that requires mention in the one-pager and a complete functional specification. Both the requests (commands) and responses need to be specified clearly. |
Agreed, we should have more information in this area. And this information probably belong in the v3 overview one-pager or a separate one-pager as the information will be common to all the supported administration commands through HTTP interface. I have added some information specific to deployment in the deployment one-pager. |
| 8 |
Correction |
|
Section 4.12 does not mention that any user script that depends on the default behavior of the V2 deploy subcommand will probably need to be corrected. It probably should |
one-pager updated - added this in section 4.12 |
| 9 |
Correction |
|
Section 4.12 does not mention that user scripts that currently leverage the dynamic reload functionality will need to be corrected. It probably should. |
one-pager updated - added this in section 4.12 |
| 10 |
Clarification |
App management |
Will customizations survive an undeploy/deploy sequence? Many users will use that sequence of commands, especially if asadmin deploy has its force flag default to false.... |
One-pager updated - custom config will not survive undeployment followed by deployment |
| 11 |
Clarification |
|
No cli and/or http admin parallel... this is strictly in the Admin console/GUI? |
one-pager updated - CLI get and set commands (dotted notation) will provide access to the custom config data |
