Return-Path: Delivered-To: apmail-incubator-cxf-dev-archive@locus.apache.org Received: (qmail 37712 invoked from network); 4 Oct 2006 13:25:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Oct 2006 13:25:22 -0000 Received: (qmail 20077 invoked by uid 500); 4 Oct 2006 13:25:22 -0000 Delivered-To: apmail-incubator-cxf-dev-archive@incubator.apache.org Received: (qmail 19946 invoked by uid 500); 4 Oct 2006 13:25:21 -0000 Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cxf-dev@incubator.apache.org Delivered-To: mailing list cxf-dev@incubator.apache.org Received: (qmail 19937 invoked by uid 99); 4 Oct 2006 13:25:21 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Oct 2006 06:25:21 -0700 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= Received: from [62.221.12.33] ([62.221.12.33:55431] helo=emea-smg1.iona.com) by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP id 6C/E5-00170-806B3254 for ; Wed, 04 Oct 2006 06:24:27 -0700 Received: from emea-ems1.ionaglobal.com (dutec.ie [10.2.1.125]) by emea-smg1.iona.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k94EMjgE006715 for ; Wed, 4 Oct 2006 14:22:48 GMT Received: from [10.5.2.11] ([10.5.2.11]) by emea-ems1.ionaglobal.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Oct 2006 14:23:10 +0100 Message-ID: <4523B594.9020700@iona.com> Date: Wed, 04 Oct 2006 14:22:28 +0100 From: Andrea Smyth User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: cxf-dev@incubator.apache.org Subject: Re: EndpointInfo in transports References: <4522B96F.4010207@envoisolutions.com> <4522BA28.4060400@envoisolutions.com> In-Reply-To: <4522BA28.4060400@envoisolutions.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 13:23:10.0050 (UTC) FILETIME=[3C6E5420:01C6E7B8] X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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); > } > >