On 4/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 4/12/07, Raymond Feng < [EMAIL PROTECTED]> wrote:
>
> Hi, Simon.
>
> For the composite component, it's probably not necessary to attach the
> wire.
> Can you try to add the following code in DeployerImpl.connect() to see
> if it
> helps?
>
> public void connect(Map<SCAObject, Object> models,
> org.apache.tuscany.assembly.Component definition)
> throws WiringException {
> // Skip the composite
> if(definition.getImplementation() instanceof Composite) {
> return;
> }
> // End of skip
>
> ...
> }
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Simon Laws" < [EMAIL PROTECTED]>
> To: < [EMAIL PROTECTED]>
> Sent: Thursday, April 12, 2007 12:19 PM
> Subject: Re: Composites implementing components problem
>
>
> > 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.ReferencerefDefinition =
> >> > > >> > 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Hi Raymond, Thanks for that. It may very well be that we don't have to
wire up the composite component because we expect the components in the
composite that implements the composite component to be wired instead. There
is a bit of a discontinuity though.
- The inner composite (the composite being used to implement a component)
does not have a full set of targets for the references that it defines.
These are not put in place until the composite is used to implement a
component in the outer composite.
- The outer composite contains the composite component and the information
about how this component is wired up. But the composite component is not
having wires created for it.
I put the change in and the next problem that showed up is that when the
components are started after deployment it gets an NPE because the component
in the inner composite has no wires. This is true because when the wires are
created the inner composite references have no targets. Somewhere we need to
make sure that the invocation chain is formed correctly to include the
components that part of the inner composite.
Anyhow I'm going to sleep now so I'll chase again in the morning.
Regards
Simon
So, this is getting a little complicated. As above I don't think we can
ignore the wires that are created in response to the composite components. I
think they should be attached to the appropriate components in the
composites implementing the composite components. However this seems to be a
little tricky. What I've done is traverse the model to find the component
from the inner composite, convert this to the right runtime component and
addthe wire there. Needless to say this doesn't work fully yet. Well it
works for the call out to the java component but the call the composite
component doesn't work. I suspect this is because whatever code attaches the
wire at the target end needs the same treatment. I'mm off to track this down
now:-)
I suspect the real answer is to fix up the model correctly so that the
targets are in the right place to start with. Anyone care to comment?
Simon
