| Item |
Section |
Comment |
Response |
comment again |
Response again |
|
| anissa-1 |
Section 4.1, #2 |
In v3, we plan to enhance the directory deployment to deploy to all of the supported targets provided that the application is stored in a shared file system that is mounted in the same place for DAS. Do you do any error checking during deployment ? ie, do you check that the directory is indeed accessiable from the host of the targeted instance ? Will deployment succeed if 1 of the target cannot access the directory ? Will warning be given ? |
We still need to figure out the details on this. But it will be hard for the deployment to do such checking (whether the bits are stored as expected). We might print out some info message to remind users that the bits need to be stored that way. And then try to give a good error message when things don't go as expected. Whether deployment will succeed or not if one of the targets failed to access the directory, it will be treated similar as other situations where the deployment has failed to load on one of the targets. |
So, deployment succeed, but with warning that says "failed to load" ? But if it is deployed as 'disabled', then you won't try to load and won't give warning, i guess. :::::: yes, fine with me. |
We may try to come up with a different warning message depending on how hard it is to do it. But there is nothing wrong that if the application is deployed with disable state, we don't print out any warning. |
| anissa-2 |
Section 4.1, about the list of CLI |
Is there any CLI command that will tell me if an application is enabled or disabled on a particular target ? If there is such command, does it return the 'real' status by considering both the enabled flag in application AND a_pplication-ref_ ? It such CLI exist, REST API can easily wrap it, and GUI can call this easily. |
In v3, we are only changing the application-ref enable attribute and don't touch the application enable attribute (it's a bit confusing when we tried to change both in previous releases. And only application-ref really matters). You could use show-component-status command, and the list-applications/list-components command will have a verbose option to show the enable state of the applications as well |
Yep, GUI won't touch the application flag, but still we should look at both since user may edit domain.xml or use CLI set to change that attribute. I just tried show-component-status, it says enabled when the application enabled is set to false. We should fix this. :::::: Thanks. I filed issue# 12100 for this. |
Yeah, I think you are right. We wil only set application-ref from the internal logic, but the checking status part will look at both places. |
| anissa-3 |
Section 4.1, about weblogic deployment |
The weblogic deployment descriptor will be ignored with a warning message when the corresponding glassfish or sun deployment descriptor is present in the same archive. Is the warning given out during deployment ? Will this be returned in the DFDeploymentStatus if GUI continue to use the DeploymentFacility API for deployment ? |
Currently it's just logged as a warning message in the server.log. |
sorry, not quite get this. Besides logged as warning, will this warning be returned in the DFDeploymentStatus ? :::::: I see. I thought CLI shows the warning, if so, GUI needs to do that same. Sounds like this is not the case. I am fine with this then. |
No, currently it is not part of the DFStatus. If you want it to be, we can look into it. |
| anissa-4 |
The sun deployment descriptor will be ignored with a warning message when the corresponding glassfish deployment descriptor is present in the same archive. |
Same question as above. |
Same as above. |
|
|
| anissa-5 |
General |
will be nice to explicitly state that for application versioning, the name or version # itself is really irrevalent. It can be called anything. |
Can you elaborate on this question? |
The name maybe hello:Beta-1 and hello:Beta-2, but it doesn't mean that Beta-2 is a later version. |
I see. Yes, the name of the versioning does not imply any order or sequencing of the version. This was brought up before. I will pass it to Serli people for them to update their doc. |
| anissa-6 |
|
Your response to anissa-2 suggests adding the verbose param to the list-components and list-applications CLI, but this is not mentioned in the one-pager. Maybe you want to add that. |
It's already there in the section 4.5.1: Interface: list-components, list-applications, list-application-refs. Comment: add a verbose option to indicate which version of the application is currently enabled |
Thanks. I was looking at the 'wrong' section. 4.7 Admin Impact/CLI section and didn't see that, hence this comment. |
|
