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 Tue, 03 Apr 2007 12:47:22 GMT


Hi Dan[D],

Are my responses to your final two questions acceptable to you?

Cheers,
Eoghan 

> -----Original Message-----
> From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com] 
> Sent: 02 April 2007 22:41
> To: cxf-dev@incubator.apache.org
> Subject: RE: In Process Dispatch [was Re: [PROPOSAL] Client 
> and Conduit changes]
> 
>  
> 
> > -----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