cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: svn commit: r529632 - /incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/coloc/cxf.xml
Date Fri, 20 Apr 2007 01:43:19 GMT
> > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message