cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <andrea.sm...@iona.com>
Subject Re: EndpointInfo in transports
Date Wed, 04 Oct 2006 13:22:28 GMT
Dan Diephouse wrote:

> Dan Diephouse wrote:
>
>> Hi all,
>>
>> Do we want to keep on using the EndpointInfo in the transport 
>> factories? It seems like the wrong thing to do as it has to do with 
>> the service model.
>
Hi Dan,

Transports need access to the service model in oder to check for 
extensors that are of interest to them. If the extensors could be made 
available via the EPR (otherAttributes) fine, but is that really better?
Why do you think it is wrong to use EndpointInfo in the transport factories?

Andrea.

>> I do prefer the approach in which we use an EndpointReferenceType. 
>> However, the thing I hate about that is that it takes about 5 lines 
>> of code to create a simple EPR with a URL. Is there a way we can 
>> modify the generated EPR class to have a default constructor which 
>> takes a URL?
>>
>> - Dan
>>
> Just wanted to elaborate on one thing. If we could get the EPR class 
> generated with a nice constructor, I was thinking that instead of the 
> get/setAddress on EndpointInfo having a string, we could make it an 
> EPR. When creating a service from WSDL, transports would be able to 
> help in creation of the EndpointInfo so the SoapDestinationFactory 
> could help turn a SOAPAddress into a proper EPR. This would be a two 
> way process and leave us with something like this:
>
> public interface WSDLEndpointFactory {
>    EndpointInfo createEndpointInfo(ServiceInfo serviceInfo, Port port);
>      void createPortExtensors(EndpointInfo ei, Service service);
> }
>
>


Mime
View raw message