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 04:00:20 GMT
Hi Freeman,

I don't know much about WS-I, is it only for SOAP/HTTP, but I guess we 
still need it when we do marshall/unmarshall in XML binding.
I can't remember the place, maybe in demo/unit test/system test there 
are testcase which use 'type'.

Cheers,
James.

Freeman Fang 写道:
> Hi,
>
> May be we need resort  WS-I,  when we use doc-lit style, is type 
> supported?
>
> Thanks very much
>
> Freeman
>
> James Mao wrote:
>
>> 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