Jun, please evaluate.

First, let me say that I agree 100% that we need to present a clear and consistent interface to the user around
deployment.  My personal opinion is that partial success is an aberration.  I'm happy to talk through all the use cases
for partial success and develop a cleaner strategy, assuming one exists.

That said, I want to make a few corrections:

Andreas Egloff wrote:
> Honestly I would also not expect to have to go in and clean up after getting "Success" neither - I would expect
everything to be working and anything else I would see as undefined - unclear to the user what it means (unless you're a
spec guru). Actually the spec also does not require that one undeploys (cleans up) before deploying again but one can
re-deploy over the top.

You would expect this with just "SUCCESS".  Would you feel the same way with the following output from a partially
successful deployment using asadmin?

Deployment of service assembly test-sa-for-redeploy succeeded partially; some service units failed to deploy.
  Component: test-component2
    ERROR:(JBIWHOOPS)SU deploy failed

>
> I'm fine with displaying this failure in the GUI in a fashion that makes it clear the deployment failed, we can add
extra details to clarify that one or more SUs deployed successfully - but the "key phrases/words" a user looks for must
clearly show something failed. I have fallen for this myself many times.

Agreed.  I think Jun pointed out that there may be a better way to surface partial deployment in NB.  AFAIK, all of the
runtime clients (ant, cli, gui) clearly state that service units failed to deploy and print error details returned from
the component.

>
> As to the task success coming back success vs. failure - it's a mess either way. I understand the reasoning about
clean-up required, my gut feeling would be that the confusion is less with saying failure (and maybe adding text to
explain partial failure and remaining artifacts) than users seeing success and thinking everything is working.

Let's discuss some ways to tweak the status message that comes back.  I think that is probably the most important aspect
of usability here.

>
> Another alternative we haven't discussed yet is to deviate from the spec, for example making the spec compliant
behavior an option that we default to failing SA deployment when any SU fails.

We could do that.  As mentioned elsewhere in this thread, you would need a rollback mechanism to back out service units
that successfully deployed before failed SU.

regards,
keith

>
> Andi
>
>
>  From the command line
>
>
>
> Andi
>
>
> Honestly, although I understand the reasoning I did not associate any
>
>
> until you guys explained the implications of saying SUCCESS vs. FAILURE I did not think that one would imply that an
undeploy is needed
>
>>
>> Mark S White wrote:
>>> True, and when we report SUCCESS, it's pretty intuitive that if the SA is modified to correct the failing SU, the
original
>>> SA must be undeployed before the updated SA can be deployed. If we report FAILURE, it won't be as obvious.
>>>
>>> Keith Babo wrote:
>>>> The good news is that we can play around with the status and/or the message that users get back.  I would caution
that many folks expect that when a command reports failure that they don't have to go in and clean up afterwards, which
would be the case if we report FAILED when a service assembly deployment succeeded for some service units.
>>>>
>>>> ~ keith
>>>>
>>>> Jun Qian wrote:
>>>>> I couldn't find it in the JBI spec either. This might simply be an implementation issue?
>>>>>
>>>>> Here is an example:
>>>>>
>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>> <jbi-task version="1.0" xmlns="http://java.sun.com/xml/ns/jbi/management-message">
>>>>>     <jbi-task-result>
>>>>>         *<frmwk-task-result>*
>>>>>             <frmwk-task-result-details>
>>>>>                 <task-result-details>
>>>>>                     <task-id>startServiceAssembly</task-id>
>>>>>                     <task-result>*SUCCESS*</task-result>
>>>>>                     <message-type>WARNING</message-type>
>>>>>                     <task-status-msg>
>>>>>                         <msg-loc-info>
>>>>>                             <loc-token>JBIMA1224</loc-token>
>>>>>                             <loc-message>*Lifecycle command startServiceAssembly partially succeeded for
SynchronousSample1Application.*</loc-message>
>>>>>                         </msg-loc-info>
>>>>>                     </task-status-msg>
>>>>>                 </task-result-details>
>>>>>                 <locale></locale>
>>>>>             </frmwk-task-result-details>
>>>>>         </frmwk-task-result>
>>>>>         <component-task-result>
>>>>>             <component-name>com.sun.bpelse-1.0-2</component-name>
>>>>>             <component-task-result-details>
>>>>>                 <task-result-details>
>>>>>                     <task-id>init</task-id>
>>>>>                     <task-result>FAILED</task-result>
>>>>>                     <message-type>ERROR</message-type>
>>>>>                     <task-status-msg>
>>>>>                         <msg-loc-info>
>>>>>                             <loc-token>JBIFW2462</loc-token>
>>>>>                             <loc-message>Service Unit SynchronousSample1Application-SynchronousSample1 cannot be
initialized, the component is not started.</loc-message>
>>>>>                         </msg-loc-info>
>>>>>                     </task-status-msg>
>>>>>                 </task-result-details>
>>>>>             </component-task-result-details>
>>>>>         </component-task-result>
>>>>>         <component-task-result>
>>>>>             <component-name>com.sun.httpsoapbc-1.0-2</component-name>
>>>>>             <component-task-result-details>
>>>>>                 <task-result-details>
>>>>>                     <task-id>start</task-id>
>>>>>                     <task-result>SUCCESS</task-result>
>>>>>                     <message-type>INFO</message-type>
>>>>>                     <task-status-msg>
>>>>>                         <msg-loc-info>
>>>>>                             <loc-token>JBIMA0500</loc-token>
>>>>>                             <loc-message>Lifecycle operation start succeeded for Service Unit
SynchronousSample1Application-com.sun.httpsoapbc-1.0-2.</loc-message>
>>>>>                             <loc-param>start</loc-param>                            
<loc-param>SynchronousSample1Application-com.sun.httpsoapbc-1.0-2</loc-param>
>>>>>                         </msg-loc-info>
>>>>>                     </task-status-msg>
>>>>>                 </task-result-details>
>>>>>             </component-task-result-details>
>>>>>         </component-task-result>
>>>>>     </jbi-task-result>
>>>>> </jbi-task>
>>>>>
>>>>>
>>>>>
>>>>> Andreas Egloff wrote:
>>>>>> I tried to find again in the spec where it says that if at least one SU deployed successfully it should report
success for the deployment? I could only find that it has to throw a deployment exception if all of them failed and
report a status string if only some of them failed - but where does it say it has to report success?
>>>>>> Andi
>>>>>>
>>>>>> Agreed, in my opinion this is a lapse of judgment in the current spec. It is very rare that a user would consider
a deployment successful if every item but one failed to deploy.
>>>>>>
>>>>>> Jun Qian wrote:
>>>>>>> My understanding is that a partial deployment success is defined as a success in the JBI Spec. However, this has
caused a lot of confusions to the end users. I have seen this issue being brought up several times. Is there anything we
can do about this?  Should the UI redefine/re-interprete the deployment success/failure status from a user's point of
view, or will  this cause even more confusion?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jun