> -----Original Message----- > From: Andrea Smyth [mailto:[EMAIL PROTECTED] > Sent: 05 April 2007 08:01 > To: [email protected] > Subject: Re: http-(conduit|destination) cfg > > Andrea Smyth wrote: > > > Glynn, Eoghan wrote: > > > >> Back in the day, I'm pretty sure that the port-specific config had > >> *both* the service and the port names encoded in the bean ID. > >> The syntax was something like > >> {http://foo.bar/context}SomeService/SomePort.whatever > >> > >> I'm not sure though if its still possible to specify the > service name > >> in this way, and if not what the motivation was for changing this. > >> > >> > > Can't remember either, one reason may have been the readability of > > bean file (the long bean names are far from ideal) trading the > > flexibility of being able to configure conduits on a per endpoint > > basis for shorter names and only being able to configure > conduits on a > > per port name basis. > > It's easy enough to change though: in HTTPConduit.getBeanName(), > > prefix the current bean name with > > endpointInfo.getServiceInfo().getName().toString() + "." + ... > > Same in AbstractHTTPDestination. > > Existing bean files (samples, tests ...) need to be updated. > > > > Andrea. > > Having said that the we can alleviate the pain of these long > bean names by re-introducing some form of wildcarding > (Objectweb Celtix supported it), in which the bean definition > with the name that best matches that of the object you want > to configure is used for injection. > I'll see if I get a change to do this.
Yeah, some form of wildcarding would rock. Especially if a "*" for the service name could be inferred if the bean ID was in the "port-only" form, i.e. no "MyService/" preceding the port name. That way all existing configs out in the wild would continue to work. Cheers, Eoghan > Andrea. > > > > >> /Eoghan > >> > >> > >> > >>> -----Original Message----- > >>> From: Fred Dushin [mailto:[EMAIL PROTECTED] Sent: 05 April > 2007 01:30 > >>> To: [email protected] > >>> Subject: http-(conduit|destination) cfg > >>> > >>> > >>> The CXF https sample has bean configurations of the form: > >>> > >>> <bean name="{http://foo.bar/context}SomePort.http-conduit"; ...> > >>> <bean > name="{http://foo.bar/context}SomePort.http-destination"; ...> > >>> > >>> I'm trying to get a grip on the name parameter here, and > its semantics. > >>> > >>> I understand and fully appreciate the idea that this lets you do > >>> configuration on a per-endpoint basis, but I think I might be > >>> missing something about what an endpoint is, in WSDL. I > was always > >>> under the impression that an endpoint is more or less a pair of > >>> QNames -- a service qname and a port (q)name. Isn't that right? > >>> > >>> The config above seems to either ignore the service, or > it chooses a > >>> default, somehow. > >>> > >>> E.g., what would happen if your services section was > something like: > >>> > >>> <wsdl:service name="ServiceA"> > >>> <wsdl:port binding="tns:SomeBinding" name="PortA"> > >>> <soap:address location="..."/> > >>> </wsdl:port> > >>> </wsdl:service> > >>> > >>> <wsdl:service name="ServiceB"> > >>> <wsdl:port binding="tns:SomeBinding" > name="PortA"> <!-- not > >>> a typo --> > >>> <soap:address location="..."/> > >>> </wsdl:port> > >>> </wsdl:service> > >>> > >>> I.e., 2 distinct services have the same port name. Is this > >>> prohibited in WSDL? If not, is there an alternate syntax for > >>> conduits and destinations that allows you to specify the > service in > >>> which a port is defined? > >>> > >>> Again, apologies for the naive questions. If you'd > prefer, you can > >>> tell me to go RTFS. > >>> > >>> -Fred > >>> > >>> > >> > > > >
