cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: [PROPOSAL] Pluggable Conduit Initiation Strategy
Date Mon, 02 Apr 2007 15:44:15 GMT

> -----Original Message-----
> From: Dan Diephouse [] 
> Sent: 02 April 2007 15:28
> To:
> Subject: Re: [PROPOSAL] Pluggable Conduit Initiation Strategy
> On 4/2/07, Glynn, Eoghan <> wrote:
> >
> >
> >
> > Dan,
> >
> > The previous thread has bifurcated outta control :-0 and is getting 
> > impossible for anyone else to follow.
> >
> > So to put some order on this, I'm starting a fresh thread on which 
> > I'll spell out in simple terms what I'm proposing to do in terms of 
> > the conduit retrieval strategy.
> >
> > In a separate email, I'll attempt to respond to the scrutiny you're 
> > imposing on the in-process dispatch use-case.
> Great.
> So please don't respond on this thread with further requests for
> > clarification on the in-process use-case. That's just one 
> of several 
> > potential applications of this mechanism. So lets keep this 
> > [sub-]discussion focused on:
> I would love to hear the other potential applications of this 
> mechanisms.

Well I mentioned other use-cases in my mails last week. Direct quotes:

"an interceptor in the outbound chain to ... divert the message to a
different endpoint, that maybe necessitates a different Conduit instance
to the one selected up front by the Client"

"where I want to be able to dynamically switch to a different Conduit
from within the interceptor chain ... this would facilitate late-binding
to one of a cluster of target endpoints."

Are you saying that you missed/ignored this in the previous threads, or
you want to hear more use-cases, or more detail, or what?

> (a) the merits or otherwise of this proposed change
> >
> > (b) why you want to force the coupling of the Client and Conduit in
> > *ALL* cases
> Here is in a nutshell why I view that we should keep usage of 
> the Conduit with the Client.
> The Client produces a request in the form of a message, xml 
> document, pojo, etc which must be dispatched somewhere. That 
> is, the thing produced must at some point leave the system of 
> the Client and go to somewhere else. 

IMO the message thingy *doesn't* have to leave the "system of the
client" in the in-process dispatch case. Unless of course you
artificially demarcate the "system of the client" to be something other
than the obvious candidates, i.e. the local process space or the domain
of the Bus instance.

> Now this sounds 
> *exactly* like what a Conduit is for. It provides a boundary 
> between the Client and the thing ultimately receiving a 
> request. 

Well in my view the Client is responsible for assembling the interceptor
chain, and dispatching the outbound message on that. So the boundary
abutted by the client is the interceptor chain, not the Conduit.

And I wouldn't be surprised if that's the conceptual picture that a lot
of other people also carry around in their heads ... i.e. a typical
stack, with the Client on top, in the middle a chain of interceptors
covering the spectrum from logical to protocol, and a Conduit at the
base. That just my understanding, I'm not forcing it on anyone though.  

And hey, it doesn't unduly concern me that you have a different picture
and see a tight coupling between Client and Conduit. Fine, I'm proposing
you can keep that tight coupling in the default case. But what I don't
understand is why you're insisting on this being the one-and-only good,
right & true way.

> > And let me preempt your first objection, that this is unnecessary.
> > Wearing my CXF user hat, I want to build logic that requires more 
> > flexibility than is provided by a tightly coupled Client 
> and Conduit. 
> > So there is a user requirement for this. The user being me. Who's 
> > currently blocked by this log-jam, and so is proposing what 
> I think is 
> > a very reasonable compromise position. In particular, note 
> that I've 
> > conceded that the default behavior should remain as is.
> I'm not trying to thwart your user requirement. But I reserve 
> the right to understand such a requirement before saying that 
> we should definitely integrate this into CXF.

And in the absence of this understanding condensing in your mind, what?

> Less is often 
> more, so if the current mechanisms are sufficient, why should 
> we introduce new ones?  

Are you really telling me that every change you've introduced yourself,
or suggestion from the user community that you've championed, has
under-gone this level of scrutiny?

I detect a certain amount of bar-raising going on.

There are plenty of cases in the code, or currently in the works, where
alternate means are introduced for achieving similar ends.

> You have done nothing to show that 
> there are use cases that absolutely require that you don't 
> use a Conduit. 

Done nothing? 

I've spent an inordinate amount of time trying to explain this to you.

It is not that I've an *absolute* requirement not to use a Conduit.

I just want the freedom to choose which Conduit is used (if any) from
within the interceptor chain. Not to have one (possibly redundant or
wrong) foisted on me by the Client. 

Please explain why you don't want this flexibility to be supported by

Your preferred upfront retrieval would still be the default. What do you
care if I build some logic on top of CXF that retrieves the Conduit at a
slightly later point in time?

> This is supposed to be a proposal and you just 
> waved your hands saying its not needed. 

Speaking of hand-waving ... I haven't heard any good reasons as to why
you're insisting that the Conduit *MUST* be retrieved upfront in the
Client in *ALL* cases. Why so intransigent on this point?

> I'm simply saying I 
> would like to understand what they are. Maybe you're right, 
> and your other thread on in-process dispatch will show me why 
> its required that we ditch the Conduit & 
> MessageSenderInterceptor for some invocations.
> My stance is that conduits are pretty flexible really, so I 
> don't see what limitations they impose.

The limitations are not in the Conduits themselves. I just want the
flexibility to retrieve the target Conduit at a later stage in the

> Is sending occurring at the wrong time? If you're not happy 
> with when the dispatching is occurring (i.e. its a different 
> phase), just stick the MessageSenderInterceptor in a different phase.
> Do you not want to use the bundled Conduits? Write your own.

I'm perfectly happy with the bundled Conduits. I wrote a chunk of that
code myself. 

I just want the flexibility to only use a Conduit when its required, and
not to be forced to prematurely retrieve one when it may turn out that I
want to use a different one instead.

> Are we not happy with our ability to select a different 
> Conduit inside the MessageSenderInterceptor? I don't see how 
> this could be an issue. Just set a new Conduit on the 
> Exchange in a previous interceptor.
> What exactly do you find so limiting about the Conduit abstraction?

One last time ... Its not the Conduit abstraction that limiting. Its
being forced to select a Conduit upfront in the Client.


View raw message