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
