Re: Nested composites and callbacks now working, was: Composites implementing components problem
On 4/14/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Simon Laws wrote:
> On 4/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> On 4/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >
>> > 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 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)
>> > > > >> > &
Nested composites and callbacks now working, was: Composites implementing components problem
Simon Laws wrote:
On 4/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 4/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
>
>
> 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 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 wires = new ArrayList();
> > > >> > > >> >String refName = ref.getName();
> > > >> > > >> >// get the definition of the reference
which
> > > is
> > > >> > > described
> > > >> > > >> > by the
> > > >> > > >> > component implementation
> > > >> > > >> >
org.apach
Re: Composites implementing components problem
On 4/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 4/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
>
>
> 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 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 wires = new ArrayList();
> > > >> > > >> >String refName = ref.getName();
> > > >> > > >> >// get the definition of the reference which
> > > is
> > > >> > > described
> > > >> > > >> > by the
> > > >> > > >> > component implementation
> > > >> > > >> >org.apache.tuscany.assembly.Referencere
Re: Composites implementing components problem
On 4/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:
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 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 wires = new ArrayList();
> > >> > > >> >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
> > >&g
Re: Composites implementing components problem
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 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 wires = new ArrayList();
> >> > > >> >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
> >
Re: Composites implementing components problem
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 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 wires = new ArrayList();
>> > > >> >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
Re: Composites implementing components problem
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 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 wires = new ArrayList();
> > >> >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
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 wires = new ArrayList();
> > >> >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 an
Re: Composites implementing components problem
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:
>> > 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 wires = new ArrayList();
>> >> >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.cla
Re: Composites implementing components problem
Simon Laws 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 wires = new ArrayList();
>> >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);
>>
Re: Composites implementing components problem
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 wires = new ArrayList();
> >> >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);
> >>
> >> Impleme
Re: Composites implementing components problem
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 wires = new ArrayList();
>> >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.ge
Re: Composites implementing components problem
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 wires = new ArrayList();
>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 n
Re: Composites implementing components problem
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 wires = new ArrayList();
>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 t
Re: Composites implementing components problem
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 wires = new ArrayList();
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]
Composites implementing components problem
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 wires = new ArrayList();
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
