On 4/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:
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
Ok replying to my own email here. I didn't find out the answer to the
previous question but changed the code to let it through the wire creation
piece. I now get a very strange effect. The system throws an unsupported
method exception trying to add the wire back into the component objecy
(CompositeComponentImpl in this case). Sure enough looking at the code you
see
public void attachWire(Wire wire) {
throw new UnsupportedOperationException();
}
Now this must have worked at some stage so some configuration must be wrong
somewhere. I notice that POJOAtomicComponent does implement these methods
but I can't find anything to do with composites that does. AnyhowI'll
invetigate the module activation stuff around the POJO piece and see how
these get put into the system. Is it just that we need to make a similar
thing for composite implementations?
Regards
Simon
