OK, yeah I think so. A couple minor suggestions: - Pass in a Message to the class instead of an exchange. This way its clear which message you're selecting a conduit for. - I am thinking that it might be better to name the class/method something along the lines of ConduitSelector.selectConduit - as the Conduit might alright be instantiated (as in the case of a cluster of Conduits), but I'll leave that up to you.
Glad we're making progress now! :) Thanks Eoghan, - Dan On 4/3/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
Hi Dan[D], Are my responses to your final two questions acceptable to you? Cheers, Eoghan > -----Original Message----- > From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] > Sent: 02 April 2007 22:41 > To: [email protected] > Subject: RE: In Process Dispatch [was Re: [PROPOSAL] Client > and Conduit changes] > > > > > -----Original Message----- > > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > > Sent: 02 April 2007 17:41 > > To: [email protected] > > 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 >
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
