Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [bpel-dev] FromParts and ToParts commited

Hi Michal,

 

Talking about Faults… As far as I understand the problem with fault-name combo box actually exists. From my point of view it is caused by incomplete FaultAdapter implementation. Right now it looks like:

 

public class FaultAdapter extends AbstractAdapter implements ILabeledElement {

 

To allow usage FaultAdapter in combo box we should change this class as following:

 

public class FaultAdapter extends AbstractStatefulAdapter implements ILabeledElement, IContentProposal {

 

Do you agree with this?

 

Thanks,

  Oleg.

 

Ps. I’m going to submit patch against this bug soon…                                                                                                         


From: bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Michal Chmielewski
Sent: Wednesday, November 28, 2007 3:11 AM
To: BPEL Designer project developer discussions.
Subject: Re: [bpel-dev] FromParts and ToParts commited

 

Michael Illiger2 wrote:


Hi,

We just commited some code for BPEL 2.0 part-mapping stuff for our PartnerActivities.

I had to change our model classes for FromPart, ToPart, FromParts, ToParts and all PartnerActivities. I also tried to implement the EMF-DOM reconciliation stuff. for these classes.
> Oleg: could you please review the changes I did in our model plugin and tell me if I missed anything?

In the property pages I tried to reuse the "combo-box widgets" Michal introduce for Partner, Operation and Variable in InvokeImplSection. This works quite well with some minor issues. E.g. there are not always all variables with matching types listed in the proposal box. And the "fault-name" combo box doesn't provide any proposals.

So fault names apply to reply activities only ... I looked at the code and I think the WSDL Operation must define faults in order for them to be present in the reply activity customizer.

Regarding the variables being shown and proposed ... there is a provider of variables from the context element (which just grabs what variables are visible) and a filter which dims that set to what is appropriate  (on MessageType, XSDType, or XSDElement) ...  org.eclipse.bpel.ui.details.providers.VariableFilter

The filter just checks "hard" type equivalence and checks the "Message Type Variable" with 1 type matching part strategy defined in the BPEL 2.0 spec.

In particular it just exactly this:

    /**
     * @see org.eclipse.jface.viewers.IFilter#select(java.lang.Object)
     */
   
    public boolean select (Object toTest) {

        if (toTest == null) {
            return false;
        }
       
               
        if ( Variable.class.isInstance(toTest) ) {
           
            Variable v = (Variable) toTest;
           
            if (fMessage == null && fElementDeclaration == null && fTypeDefinition == null) {
                return true;
            }
           
            if (fMessage != null) {
               
                if (fMessage.equals ( v.getMessageType() )) {
                    return true;
                }
               
                if (fMessage.getEParts().size() == 1) {               
                    Part part = (Part) fMessage.getEParts().get(0);
                    XSDElementDeclaration decl = part.getElementDeclaration();
                    if (decl != null && decl.equals( v.getXSDElement() )) {
                        return true;
                    }
                }
               
            }
           
            if (fElementDeclaration != null) {
                if (fElementDeclaration.equals( v.getXSDElement() )) {
                    return true;
                }
            }
           
           
            if (fTypeDefinition != null) {
                if (fTypeDefinition.equals( v.getType() )) {
                    return true;
                }               
            }
       
            return false;           
        }
       
        return true;
    }


Now I actually think this is a pretty good so far ....

The only question is whether sub-types can be considered "compatible" ....


> Michal: if you find some time could you please take a look at #updatePartMappingWidgets in InvokeVariablesSection and review if I used your widgets as they are intended to use? And could you also please take a look at the faultname stuff for Reply. If I look at the CVS history I wonder if this has ever worked...


Oh, and not to forget: We also commited Oleg's latest source-tab patch (sourcetab-20071116.patch)

Cheers Michael


 

Software Developer - BPEL Editor / WID

WSS Business Process Solutions Development 1

Dept. 4722, Bldg. 71032-01, Room 086

IBM Böblingen Laboratory

Schönaicherstr. 220, D-71032 Böblingen

 

Notes:

Michael Illiger2/Germany/IBM

Internet:

milliger@xxxxxxxxxx

Phone:

++49-(0)7031-16-1273

Fax:

++49-(0)7031-16-4890

 

IBM Deutschland Entwicklung GmbH

Chairman of the Supervisory Board: Martin Jetter

Board of Management: Herbert Kircher (Chairman)

Corporate Seat: Böblingen

Commercial Register: Amtsgericht Stuttgart, HRB 243294

 


 



 
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
  




-- 
Michal Chmielewski, CMTS, Oracle Corp, 
W:650-506-5952 / M:408-209-9321 
 
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know." 
--------------------------------------------------------------------
Closed Joint Stock Company Intel A/O
Registered legal address: 125252, Moscow, Russian Federation, 
Chapayevsky Per, 14.

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Back to the top