Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <7b774c950704191843r7b6334bte80e948eef2efafa@mail.gmail.com>
Date: Thu, 19 Apr 2007 20:43:19 -0500
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: svn commit: r529632 -
 /incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/coloc/cxf.xml
In-Reply-To: <FA1787F64A095C4090E76EBAF8B183E071FD6E@emea-ems1.IONAGLOBAL.COM>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_62837_6468636.1177033399280"
References: <7b774c950704180836tb74eb85p5241ea3af3f87acd@mail.gmail.com>
	 <FA1787F64A095C4090E76EBAF8B183E071FD6E@emea-ems1.IONAGLOBAL.COM>

------=_Part_62837_6468636.1177033399280
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

> > 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

------=_Part_62837_6468636.1177033399280--