You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cxf.apache.org by eg...@apache.org on 2007/04/17 16:57:45 UTC
svn commit: r529632 -
/incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/coloc/cxf.xml
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/coloc/cxf.xml
Modified: incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/coloc/cxf.xml
URL: http://svn.apache.org/viewvc/incubator/cxf/trunk/systests/src/test/java/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/coloc/cxf.xml (original)
+++ incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/coloc/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>
Re: svn commit: r529632 - /incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/coloc/cxf.xml
Posted by Dan Diephouse <da...@envoisolutions.com>.
> > 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 :)
>
Maybe we were arguing about different things. My points were that:
a) there needs to be a get/setConduit() on Client
b) Ultimately we should always have a Conduit associated with an exchange
(of course coloc doesn't follow this, but I'll exempt this as a special case
for now )
c) Calling getConduit() should create a conduit if one doesn't exist
We were of course talking about the proposed changes as well. I may have
conflated these issues with the need to always create a conduit if its not
set. For instance I said
"My point is that a user should just be able to do client.getConduit() and
change some transport settings. They shouldn't have to explicitly create the
Conduit though, which is what your proposal does."
I think we were discussing many different things there though. For instance
we could be talking about: getting rid of get/set/Conduit completely, having
getConduit do/not do initilization, and whether or not we should init the
conduit in Client.invoke() if it hasn't been init'd. I was focusing on the
first two things and I think I should've been focusing on the last one now
:-)
So to be clear, as long as a user can call getConduit and have a conduit
init'd for them, I'm ok with whatever. Apologies for any confusion caused
:-\
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: svn commit: r529632 - /incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/coloc/cxf.xml
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 18 April 2007 16:36
> To: cxf-dev@incubator.apache.org
> 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 <eo...@iona.com> wrote:
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 17 April 2007 17:37
> > > To: cxf-dev@incubator.apache.org
> > > 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, eglynn@apache.org <eg...@apache.org> 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
>
Re: svn commit: r529632 - /incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/coloc/cxf.xml
Posted by Dan Diephouse <da...@envoisolutions.com>.
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 <eo...@iona.com> wrote:
>
>
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 17 April 2007 17:37
> > To: cxf-dev@incubator.apache.org
> > 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, eglynn@apache.org <eg...@apache.org> 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
RE: svn commit: r529632 - /incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/coloc/cxf.xml
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 17 April 2007 17:37
> To: cxf-dev@incubator.apache.org
> 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, eglynn@apache.org <eg...@apache.org> 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
>
Re: svn commit: r529632 - /incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/coloc/cxf.xml
Posted by Dan Diephouse <da...@envoisolutions.com>.
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
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, eglynn@apache.org <eg...@apache.org> 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/coloc/cxf.xml
>
> Modified:
> incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/coloc/cxf.xml
> URL:
> http://svn.apache.org/viewvc/incubator/cxf/trunk/systests/src/test/java/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/coloc/cxf.xml
> (original)
> +++
> incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/coloc/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