cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]
Date Mon, 02 Apr 2007 21:40:30 GMT
 

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 02 April 2007 17:41
> To: cxf-dev@incubator.apache.org
> Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client 
> and Conduit changes]
>
> 
> If all we're trying to decide on is creating a way to avoid 
> initializing a Conduit by default, then I only have two 
> questions before adopting your
> approach:
> - Why should we have a ConduitInitiatorStrategy as opposed to 
> just setting a flag on the Conduit?


Well a flag, being boolean, gives just two options. 

A pluggable strategy on the other hand would give more flexibility to
take any number of approaches ... use a preexisting conduit, or create
one upfront in ClientImpl.invoke(), or defer creating it until the
MessageSenderInterceptor, or retrieve it via some discovery/config
mechanism, or select one of a cluster of endpoints, or any other
approach we care to dream up. 

In addition to the flexibility, the strategy approach has conceptual
benefits - its much easier to digest the logic if concentrated in a
single class as opposed to being buried in code spread across multiple
classes. Standard justification for this design pattern.


> If someone sets the flag 
> to false the MessageSenderInterceptor can always fall back 
> and init a Conduit later using the EndpointInfo.
> - Is your only objection that we may not always need the 
> specific Conduit that is inited? And that this may consume 
> resources? Or is the motivation for this approach that you 
> just don't want to use a Conduit at all. 

*Both* are motivations, depending on the use case. 

In certain scenarios, the late Conduit retrieval would allow us to avoid
needlessly creating a Conduit which would lie unused if we end up
completely by-passing the transport. 

In other scenarios, the late Conduit retrieval would allow us to ensure
the correct Conduit has been selected before initing it.


> It seems like it is mostly the later, which is what all my hubbub is
about.


No, its definitely a multiple use-case idea.

/Eoghan

Mime
View raw message