Replies within. On 4/30/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Greg Dritschler wrote: > The WirePostProcessor is passed a Wire from which it can find the > source and > target contract and the source and target URI. If it needs context > from the > SCDL that is not in the contracts, is the processor expected to look > up the > URIs in the component manager? That seems rather indirect. Since the > code > building the wires has the source and target objects, couldn't it just > pass > them to the postprocessor? > > Greg Dritschler > Greg, If I understand correctly, the problem is that o.a.t.spi.wire.Wire duplicates some of the info already present in the assembly model, and does not give a way to access the other info that is not duplicated. What other context do you need? policies? binding info? the implementation types on both ends of the wire? anything else?
I'm thinking about policy, but why limit it? Shouldn't it have access to the complete model and sufficient context for where the wire is being added within the model? This is not the first time that we run into this kind of issue. This
seems to be a general design issue in the Tuscany runtime, not just with wires but also with component implementations and bindings, and I think that we need two fixes here: - avoid duplicating most of the assembly model in another incomplete runtime model (like o.a.t.spi.wire.Wire or o.a.t.spi.component.AtomicComponent) - make sure that Tuscany extensions get passed the pointers to the assembly model so that they get the info they need I think that the changes that we've started to make to the core runtime and the SPI work that Raymond and Ant have started will have to address this. Thoughts?
I understand the problems with the runtime model but I'm not sure where you are going with it. I assume you are still going to have builders for extensible elements like implementation and binding. Are you planning to get rid of the builders for other elements like component? How will the runtime objects created by builders be organized with respect to the assembly model? --
Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
