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."