I have no desire to waste more time on this as well, but hear me out for just a moment :-)
My objection was to removing getConduit(). As soon as we introduce a ConduitSelectionStrategy class having getConduit() doesn't imply that a Conduit is always created up front. Inside ClientImpl we'd just do: message.getExchange().set(ConduitSelector.class, new DefaultConduitSelector(conduit)); This conduitselector would allow a null Conduit in the constructor. If the Conduit has been inited (by calling getConduit), it could then use that for selecting a Conduit in selectConduit(). Otherwise the conduit selector would have to create a Conduit per the logic in AbstractConduitSelector.getSelectedConduit(). That should simplify things a bit. - Dan On 4/18/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 17 April 2007 17:37 > To: [email protected] > Subject: Re: svn commit: r529632 - > /incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/sys > test/coloc/cxf.xml > > Hiya, > > My understanding was that the ConduitSelector was going to > make it so we didn't have to do this type of thing. i.e. > something like this: > 1. If user has called Client.getConduit(), then we create a > conduit inside the Conduit and that gets set on the message ^^^^^^^^^^^^^^^^^^ Do you mean that we create a conduit inside the Client? The ConduitSelector logic is exactly as we discussed (at extreme length) on this list, modulo some interface/method renaming suggested by yourself. The selector encapsulates whether the Conduit is retrieved upfront in the ClientImpl.invoke() or deferred to when its actually required, specifically when/if: 1. there's an application-level call to Client.getConduit() 2. an interceptor needs access to the Conduit to do something with it, typically the MessageSenderInterceptor.handleMessage() needing to call Conduit.prepare(). Whether the ConduitSelector.selectConduit() is called because #1 or #2 occurs first is not relevant to the ConduitSelector. All it knows is a Conduit is required now, so it goes and gets one according to whatever strategy it implements (e.g. either the Conduit it retrieved earlier upfront, or one retrieved on-demand). Having to explicitly configure the deferred case is required because an upfront strategy is the default, as you were very staunchly opposed to changing the current behavior by default. After having burned a lot of time in the original discussion, I'd really like to move on with other stuff ... :) Cheers, Eoghan > 2. Otherwise we set a default ConduitSelector which can go > back to the Client and call getConduit() when its needed > > I think I must be missing something though... > > - Dan > > On 4/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Author: eglynn > > Date: Tue Apr 17 07:57:44 2007 > > New Revision: 529632 > > > > URL: http://svn.apache.org/viewvc?view=rev&rev=529632 > > Log: > > Configuring DeferredConduitSelector for coloc system tests so as to > > avoid upfront creation of unused Conduit > > > > > > Modified: > > > > > > > incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/colo > > c/cxf.xml > > > > Modified: > > > incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/colo > > c/cxf.xml > > URL: > > > http://svn.apache.org/viewvc/incubator/cxf/trunk/systests/src/test/jav > > > a/org/apache/cxf/systest/coloc/cxf.xml?view=diff&rev=529632&r1=529631& > > r2=529632 > > > > > ====================================================================== > > ======== > > --- > > > incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/colo > > c/cxf.xml > > (original) > > +++ > > > incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/colo > > c/cxf.xml > > Tue Apr 17 07:57:44 2007 > > @@ -21,6 +21,7 @@ > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > > xmlns:http="http://cxf.apache.org/transports/http/configuration"; > > xmlns:jms="http://cxf.apache.org/transports/jms"; > > + xmlns:jaxws="http://cxf.apache.org/jaxws"; > > xsi:schemaLocation=" > > http://cxf.apache.org/transports/http/configuration > > http://cxf.apache.org/schema/transports/http.xsd > > http://www.springframework.org/schema/beans > > http://www.springframework.org/schema/beans/spring-beans.xsd";> > > @@ -97,5 +98,19 @@ > > </property> > > </bean> > > > > + <!-- Avoid upfront Conduit creation, as client-side transport > > resources > > + are not required in the coloc case --> > > + <jaxws:client id="{http://apache.org/headers/rpc_lit}SoapPort"; > > + abstract="true"> > > + <jaxws:conduitSelector> > > + <bean > > + class="org.apache.cxf.endpoint.DeferredConduitSelector > > "/> > > + </jaxws:conduitSelector> > > + </jaxws:client> > > + <jaxws:client > id="{http://apache.org/headers/doc_lit}SoapPort9000"; > > + abstract="true"> > > + <jaxws:conduitSelector> > > + <bean > > + class="org.apache.cxf.endpoint.DeferredConduitSelector > > "/> > > + </jaxws:conduitSelector> > > + </jaxws:client> > > > > </beans> > > > > > > > > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog >
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
