On 4/2/07, Glynn, Eoghan <[EMAIL PROTECTED]> 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.
(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. Now this
sounds *exactly* like what a Conduit is for. It provides a boundary between
the Client and the thing ultimately receiving a request. What this thing
receiving the request is doesn't matter - in process server or a remote
host.
Since
Message.setConduit() is called nowhere, I'd also propose dropping this
for the sake of cleanliness (but I'm not hung on that, if you really
want to keep Message.getConduit()).
I don't care either way really.
However the main change would be in
the implementation of Exchange.getConduit (). Instead of being a straight
accessor to a private field, this would instead look more like:
public class ExchangeImpl implements Exchange {
public Conduit getConduit() {
return get(ConduitInitiationStrategy.class ) != null
? get(ConduitInitiationStrategy.class).getConduit(this)
: null;
}
}
In ClientImpl.invoke(), the main change is simply to call:
exchange.put(ConduitInitiationStrategy.class , conduitStrategy);
instead of
exchange.setConduit(initedConduit);
The conduitStrategy would as I said before default to a upfront
retrieval. However this mechanism would provide the flexibility to
inject an alternate strategy via Spring.
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. Less is often more, so if the current mechanisms
are sufficient, why should we introduce new ones? You have done nothing to
show that there are use cases that absolutely require that you don't use a
Conduit. This is supposed to be a proposal and you just waved your hands
saying its not needed. 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.
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.
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?
Regards,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
