cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Li, Tao \(Tom\)" <Tao...@iona.com>
Subject RE: [jira] Reopened: (CXF-109) Remove isInSoapHeader() from service model
Date Wed, 01 Nov 2006 08:37:41 GMT
Hi Dan.D,

I've the modification of BindingMessageInfo as you suggested.
But for SoapBindingMessageInfo, I feel it's purpose just the same as SoapHeaderInfo we added
into BindingMessageInfo extensors.
If we really want't seperate the logical part of service model and physical part of service
model (physical part delegate to Binding for creation), there's a big rework needs to do I
think.

Thanks.
Tom




> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Tuesday, October 31, 2006 12:44 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: [jira] Reopened: (CXF-109) Remove isInSoapHeader() from
> service model
> 
> 
> 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().getMe
> ssageParts().
> >
> > 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
> 
> 
Mime
View raw message