You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Li, Tao (Tom)" <Ta...@iona.com> on 2006/10/31 08:06:56 UTC
RE: [jira] Reopened: (CXF-109) Remove isInSoapHeader() from service model
Hi Dan.D,
The example you show below made me confused.
In BindingInfo, we could get BindingOperationInfo according to OperationInfo provided. And BindingOperationInfo has 2 BindingMessageInfo which mapped to Input Message and Output Message.
From the example below, we don't know which message should be used Input or Output. If we provide extra parameter to specify input/output, this api modification seemed unnecessary, it likes just combined BindingInfo.getOperation(oi).getInput().getMessageInfo().getMessageParts().
Thanks.
Tom
> -----Original Message-----
> From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
> Sent: Monday, October 30, 2006 7:53 PM
> To: cxf-issues@incubator.apache.org
> Subject: [jira] Reopened: (CXF-109) Remove isInSoapHeader()
> from service
> model
>
>
> [ http://issues.apache.org/jira/browse/CXF-109?page=all ]
>
> Dan Diephouse reopened CXF-109:
> -------------------------------
>
>
> OK, this is a good start. While it accomplishes the goal of
> removing isInSoapHeader, I think the semantics need tweaking.
> The bindinginfo itself should be in charge of providing the
> body message parts and the soap message parts.
>
> For example:
>
> public class BindingInfo ... {
>
> public List<MessagePartInfo> getMessageParts(OperationInfo o) { ... }
>
> public void setMessageParts(OperationInfo o,
> List<MessagePartInfo> parts) { ... }
>
> }
>
> The WSDLServiceBuilder and the BindingInfoFactorys would be
> responsible for setting this up. Similarly on the SoapBindingInfo:
>
> public class SoapBindingInfo ... {
>
> public List<MessagePartInfo>
> getHeaderMessageParts(OperationInfo o) { ... }
>
> public void settHeaderMessageParts(OperationInfo o,
> List<MessagePartInfo> parts) { ... }
>
> }
>
> These semantics align better with the WSDL model, are more
> intuitive to the user, and I believe create more
> straightforward code in our interceptors, so I'm reopening this issue.
>
> > Remove isInSoapHeader() from service model
> > ------------------------------------------
> >
> > Key: CXF-109
> > URL: http://issues.apache.org/jira/browse/CXF-109
> > Project: CXF
> > Issue Type: Improvement
> > Affects Versions: 2.0-M1
> > Reporter: Dan Diephouse
> > Assigned To: tli
> > Fix For: 2.0-M1
> >
> >
> > isInSoapHeader should NOT be part of the service model. We
> should pull down a list of body parts from the binding instead.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
> administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>
>
Re: [jira] Reopened: (CXF-109) Remove isInSoapHeader() from service
model
Posted by Dan Diephouse <da...@envoisolutions.com>.
I'm sorry, you're right. It would be better to have
BindingMessageInfo {
public List<MessagePartInfo> getMessageParts()
public void setMessageParts(List<MessagePartInfo> parts);
}
And then maybe SoapBindingMessageInfo:
SoapBindingMessageInfo extends BindingMessageInfo {
public List<MessagePartInfo> getHeaderMessageParts()
public void setHeaderMessageParts(List<MessagePartInfo> parts);
}
Regards,
- Dan
Li, Tao (Tom) wrote:
> Hi Dan.D,
>
> The example you show below made me confused.
>
> In BindingInfo, we could get BindingOperationInfo according to OperationInfo provided. And BindingOperationInfo has 2 BindingMessageInfo which mapped to Input Message and Output Message.
>
> From the example below, we don't know which message should be used Input or Output. If we provide extra parameter to specify input/output, this api modification seemed unnecessary, it likes just combined BindingInfo.getOperation(oi).getInput().getMessageInfo().getMessageParts().
>
> Thanks.
> Tom
>
>
>
>> -----Original Message-----
>> From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
>> Sent: Monday, October 30, 2006 7:53 PM
>> To: cxf-issues@incubator.apache.org
>> Subject: [jira] Reopened: (CXF-109) Remove isInSoapHeader()
>> from service
>> model
>>
>>
>> [ http://issues.apache.org/jira/browse/CXF-109?page=all ]
>>
>> Dan Diephouse reopened CXF-109:
>> -------------------------------
>>
>>
>> OK, this is a good start. While it accomplishes the goal of
>> removing isInSoapHeader, I think the semantics need tweaking.
>> The bindinginfo itself should be in charge of providing the
>> body message parts and the soap message parts.
>>
>> For example:
>>
>> public class BindingInfo ... {
>>
>> public List<MessagePartInfo> getMessageParts(OperationInfo o) { ... }
>>
>> public void setMessageParts(OperationInfo o,
>> List<MessagePartInfo> parts) { ... }
>>
>> }
>>
>> The WSDLServiceBuilder and the BindingInfoFactorys would be
>> responsible for setting this up. Similarly on the SoapBindingInfo:
>>
>> public class SoapBindingInfo ... {
>>
>> public List<MessagePartInfo>
>> getHeaderMessageParts(OperationInfo o) { ... }
>>
>> public void settHeaderMessageParts(OperationInfo o,
>> List<MessagePartInfo> parts) { ... }
>>
>> }
>>
>> These semantics align better with the WSDL model, are more
>> intuitive to the user, and I believe create more
>> straightforward code in our interceptors, so I'm reopening this issue.
>>
>>
>>> Remove isInSoapHeader() from service model
>>> ------------------------------------------
>>>
>>> Key: CXF-109
>>> URL: http://issues.apache.org/jira/browse/CXF-109
>>> Project: CXF
>>> Issue Type: Improvement
>>> Affects Versions: 2.0-M1
>>> Reporter: Dan Diephouse
>>> Assigned To: tli
>>> Fix For: 2.0-M1
>>>
>>>
>>> isInSoapHeader should NOT be part of the service model. We
>>>
>> should pull down a list of body parts from the binding instead.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the
>> administrators:
>> http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> For more information on JIRA, see:
>> http://www.atlassian.com/software/jira
>>
>>
>>
>>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog