cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: Questions about CodeFirst in client side
Date Thu, 12 Oct 2006 21:32:20 GMT
Jiang Ning wrote:

> Hi Dan,
>
> Dan Diephouse wrote:
>
>> Jiang Ning wrote:
>>
>>> Hi Dan
>>>
>>> I am working on the CXF-18 to implement the addport() API,  so I 
>>> need to build service model from code(there is no wsdl url), and 
>>> create Endpoint for Dispatch.
>>
>>
>>
>> So this service model is created from a class which extends the 
>> Jax-ws service class? In reflectionservicefactory there is a 
>> stopClasses list. We should tell the ServiceFactory to introspect all 
>> the methods, but stop at the JAX-WS Service class using that mechanism.
>>
> [Willem] IMO ServiceFactory's code for intorspecting all the methods 
> can be taken out as util method, and that could be easy for the JAX-WS 
> Service class to reuse.

The whole point of the servicefactory is to encapsulate all the 
introspection. Why would we want this in the service class? We should 
have the Service using the ServiceFactory it seems to me.

>
>>> So I just do a quick reading about you CodeFirstTest in the 
>>> frontend-jaxws and find out that the (code first) client side don't 
>>> actual invoke the method.
>>
>>
>>
>> Which method doesn't it invoke?
>
>
> [Willem]  I mean the client side is not actually create an client 
> proxy from SEI class to invoke the server's method in the CodeFirstTest.
> When I finish this task, I may have a unit test of that :).
>
Yeah, this needs to be done yet... It'd be nice to have a 
ClientFactoryBean like we have a ServerFactoryBean at some point. I keep 
on meaning to do this...

>>
>>> I just want to ask if you have any plan to implements this or I will 
>>> try to get this work.
>>
>>
>>
>> I wasn't planning on working on it, but I think you could use the 
>> BindingInfoFactories to get the addPort to work and then create a 
>> dummy EndpointInfo in the service model. You shouldn't have to create 
>> a whole new service model because there is already one there in Service
>
>
> [Willem]  Here is the  user  side code for addPort.
>
> service = Service.create(qname);
> service.addPort(qname, HTTPBinding.HTTP_BINDING, url);
> Dispatch<Source> dispatcher = service.createDispatch(new QName("", ""),
>                                       Source.class, 
> service.Mode.PAYLOAD);
>
> The sevice model would not be created in Service because there is no 
> wsdl for Service.
> IMO the service model will be created in createDispatch where we can 
> get the SEI.

I would think we would still construct a fake service model. Have you 
looked at the ProviderServiceFactoryBean? We just instantiate a dummy 
model with an invoke operation. Right now we still use the 
Dispatch*Interceptors, but we should be able to just use the existing 
interceptors and write a databinding implementation which recognizes 
Source objects instead.

- Dan

-- 
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


Mime
View raw message