cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mao <james....@iona.com>
Subject Re: svn commit: r442162 - in /incubator/cxf/trunk: api/src/main/java/org/apache/cxf/databinding/ api/src/main/java/org/apache/cxf/endpoint/ rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/ rt/core/src/main/java/org/apache/cxf/endpoi
Date Tue, 12 Sep 2006 02:23:57 GMT
Hi two Dans,

Yes, I think what Tom looking for is what i was looking for days, We 
still need those type class info for marshalling/unmarshalling, i dont' 
know if you guys have resolve this problem, and i definitely need to 
find a place for those, not just the RPC, i think if it's doc-lit-bare 
style, and if it's use the type, it will also need the type info.

Thanks,
James.

Li, Tao (Tom) 写道:
> Hi Dan.K & Dan.D,
>
> My purpose of adding getImplementor() is to find the java class information matched with
the message part in the input/output message. 
> In the case of RPC style, the messagepart using type="...", to unmarshall this using
JAXB, we need to provide the QName and java class of this message part, and the java class
can't be found only with service model.
>
> e.g. <wsdl:part type="x1:myComplexStruct" name="in">
>
> I'm looking for some other way to solve this problem, but still have no good solution,
any help are most welcomed!
> Thanks Tom
>
>
>
>
> -----Original Message-----
> From: Kulp, John Daniel 
> Sent: Monday, September 11, 2006 1:11 PM
> To: cxf-dev@incubator.apache.org
> Cc: Dan Diephouse; cxf-commits@incubator.apache.org
> Subject: Re: svn commit: r442162 - in /incubator/cxf/trunk:
> api/src/main/java/org/apache/cxf/databinding/
> api/src/main/java/org/apache/cxf/endpoint/
> rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/
> rt/core/src/main/java/org/apache/cxf/endpoi
>
>
>
>
>
> On Monday September 11 2006 10:15 am, Dan Diephouse wrote:
>   
>>> incubator/cxf/trunk/api/src/main/java/org/apache/cxf/endpoint/Endpoint.ja
>>> va (original) +++
>>> incubator/cxf/trunk/api/src/main/java/org/apache/cxf/endpoint/Endpoint.ja
>>> va Mon Sep 11 03:11:15 2006 @@ -44,4 +44,6 @@
>>>      Executor getExecutor();
>>>
>>>      Interceptor getFaultInterceptor();
>>> +
>>> +    Object getImplementor();
>>>  }
>>>       
>> I'm -1 on this change. Why is this on the Endpoint? It looks like you're
>> looking up the method from the implementor methods and the class names,
>> which isn't a real good way to do it. The BindingOperationInfo name
>> should correspond to the rpc element name and the JaxWsServiceFactory
>> should have already instantiated the operation with a Method. The
>> invoker can then invoke the service by looking up the operation from the
>> exchange. Also, there shouldn't be a need to look up the class as the
>> Databinding is handling (see all the wrapped/bare interceptors for
>> examples).
>>     
>
> Dan beat me to this one.    Also a very strong -1 to this change. 
>
> The SOAP binding should have no knowledge of the method or target objects or 
> anything like that.    The whole point of the service model is to abstract 
> out all of that information .   The RPCInInterceptor should use the message 
> to find the OperationInfo (specifically, the BindingOperationInfo) from the 
> service model and only use the information that is available from there.
>
> The frontend could be something like a javascript engine or Ruby engine or 
> similar where there either isn't a target object or the target object doesn't 
> have any java methods on it that have any relation to the data in the 
> methods.
>
>
>   


Mime
View raw message