On 4/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Simon Laws wrote:
> > On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >>
> >> Simon Laws wrote:
> >> > I'm trying to bring the composite-impl sample up. The sample uses
> >> nested
> >> > composite files and if fails trying to wire up the references from
> >> a top
> >> > level component (which is implemented in a separate composite - see
> >> > [1]) to
> >> > another component.
> >> >
> >> > The failure happens during the connect phase of
> >> > DeployerImpl.deploy(). Here
> >> > it loops round all of the references specified in the model for the
>
> >> > component in question and then goes to the component implementation
> to
> >> > get
> >> > the reference definition so it can subsequently create a wire. Here
> is
> >> > the
> >> > top of the loop from DeployerImpl.connect() (I added some comments
> >> > here to
> >> > highlight the points of interest)
> >> >
> >> > // for each the references specified in the SCDL for the
> >> > component
> >> > for (ComponentReference ref : definition.getReferences()) {
> >> > List<Wire> wires = new ArrayList<Wire>();
> >> > String refName = ref.getName();
> >> > // get the definition of the reference which is
> described
> >> > by the
> >> > component implementation
> >> > org.apache.tuscany.assembly.Reference refDefinition =
> >> > getReference(definition.getImplementation(), refName);
> >> > assert refDefinition != null;
> >> >
> >> > So when it comes to "SourceComponent" [1] it finds that the
> >> component is
> >> > implemented by another composite. When this information is read
> >> into the
> >> > model by the CompositeProcessor there is code that specifically
> reads
> >> the
> >> > implementation.composite element, i.e.
> >> >
> >> > } else if
> >> > (IMPLEMENTATION_COMPOSITE_QNAME.equals(name)) {
> >> >
> >> > // Read an implementation.composite
> >> > Composite implementation =
> >> > factory.createComposite();
> >> > implementation.setName(getQName(reader,
> >> > NAME));
> >> > implementation.setUnresolved(true);
> >> >
> >> component.setImplementation(implementation);
> >> >
> >> > Now all this does as far as I can see is create a composite type
> with
> >> > just
> >> > the composite name in it (I assume that the intention is to resolve
> >> this
> >> > later on). Hence the connect step fails because the component
> >> > implementation
> >> > in our example has nothing in it. Specifically it has none of the
> >> > reference
> >> > definition information that it would have to look in the other
> >> composite
> >> > file to get.
> >> >
> >> > The problem is I'm not sure when this information is intended to be
> >> > linked
> >> > up. During the resolve phase when this component implementation is
> >> > reached
> >> > the resolver just finds a composite with nothing in it and, as far
> as
> >> > I can
> >> > tell, just ignores it. How does the system know that this
> >> implementation
> >> > refers to a composite defined elsewhere rather than just defining a
>
> >> > composite with nothing in it?
> >> >
> >> > I would assume at the resolve or optimize stages this should happen
> so
> >> > that
> >> > we have a complete model when it comes time to build the runtime.
> >> > Maybe we
> >> > need a new type or flag to indicate that this is a composite
> >> > implementing a
> >> > component. I'll keep plugging away but if someone could give me a
> >> > pointer
> >> > that would be great?
> >> >
> >> > [1]
> >> >
> >>
>
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/composite-impl/src/main/resources/OuterComposite.composite
> >>
> >> >
> >> >
> >>
> >> Simon,
> >>
> >> This code:
> >> // Read an implementation.composite
> >> Composite implementation =
> >> factory.createComposite();
> >> implementation.setName(getQName(reader,
> >> NAME));
> >> implementation.setUnresolved(true);
> >> component.setImplementation
> (implementation);
> >> creates a reference to the named composite marked Unresolved.
> >>
> >> Later in the CompositeProcessor.resolve method, we resolve the
> >> Implementations of all the Components in the Composite, including
> >> references to other Composites, as follows:
> >> // Resolve component implementations, services and references
> >> for (Component component: composite.getComponents()) {
> >> constrainingType = component.getConstrainingType();
> >> constrainingType = resolver.resolve(
> ConstrainingType.class,
> >> constrainingType);
> >> component.setConstrainingType(constrainingType);
> >>
> >> Implementation implementation =
> >> component.getImplementation();
> >> implementation = resolveImplementation(implementation,
> >> resolver);
> >> component.setImplementation(implementation);
> >>
> >> resolveContracts(component.getServices(), resolver);
> >> resolveContracts(component.getReferences(), resolver);
> >> }
> >>
> >> Hope this helps.
> >>
> >> --
> >> Jean-Sebastien
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >> Thanks Sebastien, That's really helpful. Thanks also for making some
> >> fixes
> > to the SCDL. I'm made some more changes to make the reference names
> match
> > and I'm now able to get past the problem point in my mail above. Not
> > quite
> > there yet but getting further. A question though.
> >
> > It's still reporting problems with the references in the component
> > implementation composite files. This time it is complaining that the
> > references don't have enough targets. This is true in their standalone
> > state
> > when they are processed as part of the contribution these composites
> > don't
> > have targets on ther references. This only happens in the top level
> > composite that uses them.
> >
> > Is this expected behaviour?
> >
> > Regards
> >
> > Simon
> >
>
> Interesting :) I think that we currently report a problem when a
> reference with multiplicity 1..x has no target. In your case, if the
> reference is promoted, then we shouldn't report a problem right away
> when we analyze the composite, as we basically defer any wiring to the
> outer level, i.e. an outer composite containing a component implemented
> by this composite. So I think we can relax the check in CompositeUtil. A
> promoted reference with multiplicity 1.x and no targets is OK and
> shouldn't be reported as a problem. Its targets will be checked when we
> get to the outer composite.
>
> Makes sense?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Sounds like a fine idea to me. How do you know though that a composite
is going to be used later in an outer composite? Do you just record the
error as you see it and then remove it later when it the outer composite is
processed? I.e. look to see if any component use the composite as an
implementation and then go and remove all/selected errors for the
implementing composite.
Regards
Simon
Does anyone know why in CompositeCompoentExtension [1] the isCallback flag
is not passed down to binding.createTargetInvoker? This causes an NPE on the
composite-impl test when processing the callback interfaces because
createTargetInvoker explicitly tests for it. This is not the only problem
still left to find but would be interested to know if there is a good
reason.
Simon
[1]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/spi/extension/CompositeComponentExtension.java
