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