| Item |
Section |
Comment |
Response |
| Versioning |
Versioning |
Is it possible to have different version of the application to be active in different instances ? eg: app-v-1 in ins-1 and app-v-2 in ins-2. |
Yes |
| Versioning |
Versioning |
The one-pager states that while deploying a newer version of the application older version of the application that is active will be disabled first and then newer version will be deployed. By the statement 'disabling' old application, do we mean setting "enabled=false" in <application> element or <application-ref> element ? The reason behind this query is that, AFAIK, <application> element in the domain.xml is shared across all instances ? and it is the <application-ref>'s enabled/disabled state that determines whether an application will be active in the instance or not. |
Yes, disabling means disable the application-ref and unload the application from that server instance. |
| Versioning |
Versioning |
If the above statement is valid, then : * the "expression-aware-operation" create-application-ref -target instance_1 app:BETA* will try to enable all BETA-* versions of the application in instance_1 ? |
Yes, good question. As the default --enabled attribute of create-application-ref is true, the create-application-ref should probably be like deploy command and take a version identifier instead. Romain et al: We also need to accomplish Bill's requirement of creating references of all versions of an application on a given target by one command. Maybe when the --enable is true, only version identifier is allowed, and when the --enabled is false, the version expression is allowed. |
| Versioning |
Versioning |
Considering a resource-adapter application and resources made available : When a new version of RAR is deployed, older version is disabled and then newer version is enabled. It is possible that the newer version will not support the already deployed resources' interfaces/contracts. UPDATE : Resources are created with reference to the resource-adapter's (application's) name. Since we embed version within the application's name, the older version's resources will not refer to newer version of the application. Administrator/Developer need to explicitly create resources for the newer version of the application. Probably a note about this can be provided in the one-pager |
Yes, Serli to update the document |
| Versioning |
Versioning |
Section 5.5 "Indeed the undeployment process deletes matched version bits in repository and disables the currently enabled version if the expression matches it". Should it be "Indeed the undeployment process deletes matched version bits in repository which might also result in undeploying the currently enabled version if the expression matches it" ? |
Serli to update document with it |
| Versioning |
Versioning |
Section 5.5, last undeploy sample : "A user wants to undeploy all the version with an identifier beginning with RC" can be "A user wants to undeploy all of the version(s) of an application where the identifier begins with RC" |
Serli to update document with it |
