> -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 18 April 2007 16:36 > To: [email protected] > Subject: Re: svn commit: r529632 - > /incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/sys > test/coloc/cxf.xml > > I have no desire to waste more time on this as well, but hear > me out for just a moment :-)
Sure ... > My objection was to removing getConduit(). Keeping Client.getConduit() was fine with me (as a mechanism to allow the application access to the Conduit from the Client API, so as to override config policies programmatically). The major point of disagreement was whether ClientImpl.invoke() should *always* itself call this.getConduit() so as to cause the Conduit to be retrieved *prior* to the interceptor chain being traversed. I wanted the flexibility to defer the creation of the Conduit unless and until it was actually required. Hence the pluggable strategy, which implements upfront Conduit retrieval by default, but can be switched to deferred retrieval via configuration. > As soon as we introduce a ConduitSelectionStrategy class having > getConduit() doesn't imply that a Conduit is always created up front. Well my whole argument was that the upfront Conduit creation was unecessary in many cases, but as a compromise I conceded the point that it remain that way by default, as long as the ConduitSelector mechanism gave me the flexibility to use alternative strategies. Of course it would be easy to switch to deferred retrieval by default, though this would leave me a bit confused as to what exactly we were arguing about in the first place :) The pluggable ConduitSelector mechanism would of course still be useful for other scenarios, as we touched on in the original discission. > Inside ClientImpl we'd just do: > > message.getExchange().set(ConduitSelector.class, new > DefaultConduitSelector(conduit)); Do you mean for the case where there a pre-existing Conduit is passed to the ClientImpl ctor? This case is currently handled via a PreexistingConduitSelector strategy, which simply returns the preexisting Conduit from selectConduit(). Anyway regardless of the type of selector in use, the selector instance is put() in the exchange by ClientImpl.invoke(), similarly to your suggested code above. > 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(). The only difference between the UpfrontConduitSelector and the DeferredConduitSelector is whether AbstractConduitSelector.getSelectedConduit() is called eagerly or lazily. Also in both cases either a null or non-null Conduit can be passed to the ctor. Passing a non-null Conduit effectively reduces back to the PreexistingConduitSelector strategy. This flexibility is convenient for the RMClient (a subclass of the normal ClientImpl), which in some cases has a specific pre-existing Conduit to send out-of-band RM messages on, and in other cases needs a Conduit to be retrieved on-demand. Cheers, Eoghan > 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/co > > > lo > > > > c/cxf.xml > > > > > > > > Modified: > > > > > > > > incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/co > > > lo > > > > c/cxf.xml > > > > URL: > > > > > > > > http://svn.apache.org/viewvc/incubator/cxf/trunk/systests/src/test/j > > > av > > > > > > > > a/org/apache/cxf/systest/coloc/cxf.xml?view=diff&rev=529632&r1=52963 > > > 1& > > > > r2=529632 > > > > > > > > > > > > ==================================================================== > > > == > > > > ======== > > > > --- > > > > > > > > incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/co > > > lo > > > > c/cxf.xml > > > > (original) > > > > +++ > > > > > > > > incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/co > > > lo > > > > 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 >
