On 4/1/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> > > If we don't ultimately use this Conduit, this shouldn't be any > > > issue. Any resource intensive operations should be delayed until > > > open() is called. > > > > > > As it happens, that is the case with all our extant Conduit > > implementations. > > > Now would be a good time to fix that. I think you may have misunderstood me here. I'm saying all existing CXF Conduit impls DO in fact delay the heavy-lifting until send() is called (modulo config retrieval and lightweight tasks like URL creation). So there's little to fix in that sense. My point was that we should not impose this ConduitInitiator.getConduit() post-condition on all future transport impls. It would be simpler and more robust for the runtime to just take more care about when it calls getConduit().
I don't see this as being a big enough issue to require us to not instantiate a Conduit by default.
However, it may not be the case for all future Conduit > implementations, > > and its certainly not part of the Conduit contract as-is. > > > > I could for example envisage a defensively-coded Conduit > probing the > > target upfront in its ctor so as to fail-fast if a > connection would be > > impossible to establish. > > > This would be bad. What if the target doesn't exist yet because the > server isn't fully intialized. We shouldn't be checking for existance > until send() is actually called. > > I can also envisage resources to be shared across Conduit instances > > being set up in the initial ConduitInitiator.getConduit() call, as > > opposed to being deferred to the first Conduit.send(). > > > > Of course we could spell out a requirement that a Conduit > > implementation doesn't do any heavy-lifting until the first send() > > occurs. But I could see potential transport authors thinking, why > > doesn't the CXF runtime just avoid making the > > ConduitInitiator.getConduit() call if its not sure it needs > the Conduit? > > > Because we want to make ClientImpl.getConduit() available to people. > Seems like a simple enough reason to me. So that the application can make direct programmatic configuration changes to the Conduit? As opposed to driving this declaratively via the Spring config or asserted (WS-)policies? This sounds like a niche use-case, but in the spirit of accommodating diversity, I think this style could be supported also. See below for a specific proposal on how this could be achieved.
Which use case is more niche? XML config or API driven config? A *lot* of XFire users do API driven config, so I don't think thats niche. I also don't thing XML config is niche either. They're both important.
> I'm sorry, but I can't ever be +1 on this. Well a statement like that sortta makes any further discussion pointless.
Alright, maybe that was a bit strong. Apologies. Let me rephrase - without very compelling reasons, I don't want to ditch the autocreation of the Conduit. I haven't seen any compelling reasons yet, but maybe the thread on in-process dispatch will show me what I am missing soon. However my progress is blocked by this ... so to break the log-jam,
here's a proposal that will allow me the flexibility to do what I need to do, while allowing you to keep your up-front creation of the Conduit in the Client.
So to recap the only limitation that you see with initing a Conduit in the Client is the in process dispatch case that we've been referring to, right? Your other main objection (based on preference) seems to be that it isn't clear that a Conduit shouldn't consume lots of resources on new FooConduit, so we shouldn't create one by default. (I think I'm missing another object here, but can't seem to find it in our incredibly long thread) So we apply the "strategy pattern" and allow for a configurable
ConduitInitiationStrategy to be used by the Client. This defaults to an "eager upfront retrieval" strategy. And it allows me to plug in my "deferred on-demand retrieval" strategy. Even in the on-demand case, your Client.getConduit() API could force the retreival of the conduit. So everyone's happy :)
Wouldn't this be the same as doing ClientImpl.setInitializeConduit(false)? Why do we need a new class for this, aren't there really just two cases? Are you trying to determine this via some logic during each invocation? - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
