cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject [PROPOSAL] Pluggable Conduit Initiation Strategy
Date Mon, 02 Apr 2007 11:35:20 GMT


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. 

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:

(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

Now the idea is simply to apply the strategy pattern so as to allow a
pluggable conduit retrieval strategy. The default strategy would be to
follow the current implementation and get the Conduit upfront from
within ClientImpl.invoke(). Another potential strategy would be to defer
retrieving the Conduit until we're sure we actually need it, i.e. in the
MessageSenderInterceptor. Currently on the requestor-side, the
MessageSenderInterceptor checks Message.getConduit(), then
Exchange.getConduit() in order to retrieve the conduit. 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()). 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.

Also let me preempt another likely objection, that this introduces too
much complexity. IMO it's a simple mechanism that in the default case
will have no impact on the current entanglement between Client and
Conduit. So in the normal case, there is no appreciable complexity for
you to deal with. Everything works just the same by default, rightly or
wrongly. So I don't think it could be fairly characterized as a
far-reaching architectural change to CXF.

Cheers,
Eoghan

Mime
View raw message