You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Julien Bigot (JIRA)" <de...@tuscany.apache.org> on 2008/10/14 14:29:44 UTC
[jira] Created: (TUSCANY-2643) composite scope handled incorectly
composite scope handled incorectly
----------------------------------
Key: TUSCANY-2643
URL: https://issues.apache.org/jira/browse/TUSCANY-2643
Project: Tuscany
Issue Type: Bug
Components: C++ SCA
Affects Versions: Cpp-Next
Environment: Svn revision 704493
Reporter: Julien Bigot
Attachments: first-solution.patch
Scope composite is not handled correctly.
The actual behavior is to return the same implementation instance for all call to a service of a component whose scope is composite. In the case where there is more than one component with composite scope, this means that the first implementation instantiated is returned regardless of the actual component one is looking for.
If the two components have a different ComponentType, this will likely lead to a segfault.
I have implemented another behavior.
With my patch, when using a service of a composite implementation, the name of the component is used as a unique ID, this is still not optimal as two components can have the same name inside two different composite or if more than one instance of a given composite are created.
This does not scale well too as a map is used. The straightforward solution would be to have the implementation instance referenced in the Component class. but as this class is defined in the tuscany::sca::model namespace, I'm not sure it is Ok to modify it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Issue Comment Edited: (TUSCANY-2643) composite scope handled incorectly
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Oct 20, 2008 at 9:52 AM, Julien Bigot <ju...@irisa.fr> wrote:
> Hi,
>
> I guess we agree here, perhaps using different words.
>
> The actual behavior is obviously wrong : 1 implementation shared by all
> components whose scope is composite, regardless of their type or name, or
> whatever else.
>
> Therefore I provided a first patch ( second-solution.patch ) that is less
> wrong
> but that still does not implement the behavior you described : 1
> implementation shared by all instances of a given component regardless of
> the
> instance of the composite (only looking at the last part of the URI
> Composite
> + component )
>
> The behavior you describe as correct here is implemented with the sum of
> the
> two patches ( second-solution.patch + copy_composite_on_instanciation.patch
> )
>
> I am therefore looking for the review of these patches. Simon Laws said
> he'll
> look into it, but I guess that the more reviews you have the better it is.
> If
> you have any comment about these, please let me know. I'll be happy to
> correct
> any error I made or to make it comply better with any code policy I didn't
> follow.
>
> In longer term, I am convinced that the actual model implemented in tuscany
> CPP doesn't capture all concepts correctly. We started a discussion to get
> a
> cleaner model on the wiki, at
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Native+Model
> so if anyone wants to join the discussion, this would be interesting. I
> don't
> want to start coding something based on a misunderstanding on my side.
>
> I hope this makes things clearer,
> Julien
>
> Le vendredi 17 octobre 2008 à 12:09, Mike Edwards a écrit :
> > Folks,
> >
> > I'm a little late to the party here as I had my head buried in something
> > else for the past couple of days, but I'll make the following
> observations:
> >
> > 1- Each component in the domain should *ALWAYS* have its own unique
> > implementations instance(s)
> >
> > 2- No component should be sharing implementation instance(s) with any
> other
> > component (corollary of point 1)
> >
> > 3- If a Composite is used as an implementation multiple times by two or
> > more Components, then all the components within that composite MUST be
> > instantiated multiple times, one for each use of the composite as an
> > implementation.
> > Each usage of the composite generates a unique "Structural URI" for each
> of
> > the contained components, consisting of the names of each component from
> > the Domain level down - eg Component1/Component2, where Component1 is at
> > Domain level and Component2 is inside a composite used as the
> > implementation of Component1. (See resolution to Issue 16 in the OASIS
> SCA
> > Assembly TC for details of this). This implies a unique structural URI
> for
> > EACH USAGE of a component.
> >
> > 3- The only distinction is then concerning the *NUMBER* of instances of
> an
> > implementation for a particular component - and the basic choice is 1 or
> > MANY
> >
> > 4- Java implementations of COMPOSITE scope imply 1 implementation
> instance
> > per component
> >
> > 5- Java implementations of STATELESS or CONVERSATION scope imply many
> > implementation instances, with the number at any one time dictated by the
> > number of invocations (STATELESS) or the number of outstanding
> > conversations (CONVERSATION) [there may be more instances held in some
> > pool, but this is simply a convenience for the implementation of the
> > runtime]
> >
> > I hope that this helps clarify a couple of points.
> >
> > Yours, Mike.
> >
> > Julien Bigot (JIRA) wrote:
> > > [
> > >
> https://issues.apache.org/jira/browse/TUSCANY-2643?page=com.atlassian.jir
> >
> >a.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640188#
> > >action_12640188 ]
> > >
> > > julien.bigot edited comment on TUSCANY-2643 at 10/16/08 8:29 AM:
> > > -----------------------------------------------------------------
> > >
> > > With this new patch, (plus the one titled second-solution.patch), the
> > > behavior should be as expected.
> > >
> > > - if more than one composite instance (i.e. component whose
> > > implementation is implementation.composite) are instances of the same
> > > composite (they share the same type) and if this composite contains a
> > > component whose scope is composite, *each one will have its own
> > > implementation instance*.
> > >
> > > In the case Simon explained
> > >
> > > CompositeA
> > > Component1 - implementation.java -> MyClass - scope = COMPOSITE
> > > Component2 - implementation.java -> MyClass - scope = COMPOSITE
> > >
> > > CompositeB
> > > Component3 - implementation.composite -> Composite A
> > > Component4 - implementation.composite -> Composite A
> > >
> > > If you fire up CompositeB there will be 4 implementation instances :
> > > 1 instance for Component3/Component1
> > > 1 instance for Component3/Component2
> > > 1 instance for Component4/Component1
> > > 1 instance for Component4/Component2
> > >
> > > was (Author: julien.bigot):
> > > With this new patch, (plus the one titled second-solution.patch),
> the
> > > behavior should be as expected.
> > >
> > > - if more than one composite instance (i.e. component whose
> > > implementation is implementation.composite) are instances of the same
> > > composite (they share the same type) and if this composite contains a
> > > component whose scope is composite, *each one will have its own
> > > implementation instance*.
> > >
> > > In the case Simon explained
> > >
> > > CompositeA
> > > Component1 - implementation.java -> MyClass - scope = COMPOSITE
> > > Component2 - implementation.java -> MyClass - scope = COMPOSITE
> > >
> > > CompositeB
> > > Component3 - implementation.composite -> Composite A
> > > Component4 - implementation.composite -> Composite A
> > >
> > > There will be 4 implementation instances :
> > >
> > > If you fire up CompositeB there will be 4 implementation instances :
> > > 1 instance for Component3/Component1
> > > 1 instance for Component3/Component2
> > > 1 instance for Component4/Component1
> > > 1 instance for Component4/Component2
>
>
> Hi Julien
Got my CPP environment up and running at the weekend. I've applied you
patches locally and the calculator sample still runs ;-) Looking at the
patches they look like a good start to me. In summary.
second-solution.patch - moves the static to store the composite instance
from the wrapper to the instance. IIUC the wrapper is common to all
components that are implemented by a specific component type so moving the
static allows one instance to to be stored for each component as opposed to
each component type.
copy_composite_on_instanciation.patch - allows a copy of a composite to be
created when it is used as a component implementation.
I'll go ahead and check the change in.
Regards
Simon
Re: [jira] Issue Comment Edited: (TUSCANY-2643) composite scope handled incorectly
Posted by Julien Bigot <ju...@irisa.fr>.
Hi,
I guess we agree here, perhaps using different words.
The actual behavior is obviously wrong : 1 implementation shared by all
components whose scope is composite, regardless of their type or name, or
whatever else.
Therefore I provided a first patch ( second-solution.patch ) that is less wrong
but that still does not implement the behavior you described : 1
implementation shared by all instances of a given component regardless of the
instance of the composite (only looking at the last part of the URI Composite
+ component )
The behavior you describe as correct here is implemented with the sum of the
two patches ( second-solution.patch + copy_composite_on_instanciation.patch )
I am therefore looking for the review of these patches. Simon Laws said he'll
look into it, but I guess that the more reviews you have the better it is. If
you have any comment about these, please let me know. I'll be happy to correct
any error I made or to make it comply better with any code policy I didn't
follow.
In longer term, I am convinced that the actual model implemented in tuscany
CPP doesn't capture all concepts correctly. We started a discussion to get a
cleaner model on the wiki, at
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Native+Model
so if anyone wants to join the discussion, this would be interesting. I don't
want to start coding something based on a misunderstanding on my side.
I hope this makes things clearer,
Julien
Le vendredi 17 octobre 2008 à 12:09, Mike Edwards a écrit :
> Folks,
>
> I'm a little late to the party here as I had my head buried in something
> else for the past couple of days, but I'll make the following observations:
>
> 1- Each component in the domain should *ALWAYS* have its own unique
> implementations instance(s)
>
> 2- No component should be sharing implementation instance(s) with any other
> component (corollary of point 1)
>
> 3- If a Composite is used as an implementation multiple times by two or
> more Components, then all the components within that composite MUST be
> instantiated multiple times, one for each use of the composite as an
> implementation.
> Each usage of the composite generates a unique "Structural URI" for each of
> the contained components, consisting of the names of each component from
> the Domain level down - eg Component1/Component2, where Component1 is at
> Domain level and Component2 is inside a composite used as the
> implementation of Component1. (See resolution to Issue 16 in the OASIS SCA
> Assembly TC for details of this). This implies a unique structural URI for
> EACH USAGE of a component.
>
> 3- The only distinction is then concerning the *NUMBER* of instances of an
> implementation for a particular component - and the basic choice is 1 or
> MANY
>
> 4- Java implementations of COMPOSITE scope imply 1 implementation instance
> per component
>
> 5- Java implementations of STATELESS or CONVERSATION scope imply many
> implementation instances, with the number at any one time dictated by the
> number of invocations (STATELESS) or the number of outstanding
> conversations (CONVERSATION) [there may be more instances held in some
> pool, but this is simply a convenience for the implementation of the
> runtime]
>
> I hope that this helps clarify a couple of points.
>
> Yours, Mike.
>
> Julien Bigot (JIRA) wrote:
> > [
> > https://issues.apache.org/jira/browse/TUSCANY-2643?page=com.atlassian.jir
> >a.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640188#
> >action_12640188 ]
> >
> > julien.bigot edited comment on TUSCANY-2643 at 10/16/08 8:29 AM:
> > -----------------------------------------------------------------
> >
> > With this new patch, (plus the one titled second-solution.patch), the
> > behavior should be as expected.
> >
> > - if more than one composite instance (i.e. component whose
> > implementation is implementation.composite) are instances of the same
> > composite (they share the same type) and if this composite contains a
> > component whose scope is composite, *each one will have its own
> > implementation instance*.
> >
> > In the case Simon explained
> >
> > CompositeA
> > Component1 - implementation.java -> MyClass - scope = COMPOSITE
> > Component2 - implementation.java -> MyClass - scope = COMPOSITE
> >
> > CompositeB
> > Component3 - implementation.composite -> Composite A
> > Component4 - implementation.composite -> Composite A
> >
> > If you fire up CompositeB there will be 4 implementation instances :
> > 1 instance for Component3/Component1
> > 1 instance for Component3/Component2
> > 1 instance for Component4/Component1
> > 1 instance for Component4/Component2
> >
> > was (Author: julien.bigot):
> > With this new patch, (plus the one titled second-solution.patch), the
> > behavior should be as expected.
> >
> > - if more than one composite instance (i.e. component whose
> > implementation is implementation.composite) are instances of the same
> > composite (they share the same type) and if this composite contains a
> > component whose scope is composite, *each one will have its own
> > implementation instance*.
> >
> > In the case Simon explained
> >
> > CompositeA
> > Component1 - implementation.java -> MyClass - scope = COMPOSITE
> > Component2 - implementation.java -> MyClass - scope = COMPOSITE
> >
> > CompositeB
> > Component3 - implementation.composite -> Composite A
> > Component4 - implementation.composite -> Composite A
> >
> > There will be 4 implementation instances :
> >
> > If you fire up CompositeB there will be 4 implementation instances :
> > 1 instance for Component3/Component1
> > 1 instance for Component3/Component2
> > 1 instance for Component4/Component1
> > 1 instance for Component4/Component2
Re: [jira] Issue Comment Edited: (TUSCANY-2643) composite scope handled
incorectly
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
I'm a little late to the party here as I had my head buried in something else for the past couple of
days, but I'll make the following observations:
1- Each component in the domain should *ALWAYS* have its own unique implementations instance(s)
2- No component should be sharing implementation instance(s) with any other component (corollary of
point 1)
3- If a Composite is used as an implementation multiple times by two or more Components, then all
the components within that composite MUST be instantiated multiple times, one for each use of the
composite as an implementation.
Each usage of the composite generates a unique "Structural URI" for each of the contained
components, consisting of the names of each component from the Domain level down - eg
Component1/Component2, where Component1 is at Domain level and Component2 is inside a composite used
as the implementation of Component1. (See resolution to Issue 16 in the OASIS SCA Assembly TC for
details of this). This implies a unique structural URI for EACH USAGE of a component.
3- The only distinction is then concerning the *NUMBER* of instances of an implementation for a
particular component - and the basic choice is 1 or MANY
4- Java implementations of COMPOSITE scope imply 1 implementation instance per component
5- Java implementations of STATELESS or CONVERSATION scope imply many implementation instances, with
the number at any one time dictated by the number of invocations (STATELESS) or the number of
outstanding conversations (CONVERSATION) [there may be more instances held in some pool, but this is
simply a convenience for the implementation of the runtime]
I hope that this helps clarify a couple of points.
Yours, Mike.
Julien Bigot (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/TUSCANY-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640188#action_12640188 ]
>
> julien.bigot edited comment on TUSCANY-2643 at 10/16/08 8:29 AM:
> -----------------------------------------------------------------
>
> With this new patch, (plus the one titled second-solution.patch), the behavior should be as expected.
>
> - if more than one composite instance (i.e. component whose implementation is implementation.composite) are instances of the same composite (they share the same type) and if this composite contains a component whose scope is composite, *each one will have its own implementation instance*.
>
> In the case Simon explained
>
> CompositeA
> Component1 - implementation.java -> MyClass - scope = COMPOSITE
> Component2 - implementation.java -> MyClass - scope = COMPOSITE
>
> CompositeB
> Component3 - implementation.composite -> Composite A
> Component4 - implementation.composite -> Composite A
>
> If you fire up CompositeB there will be 4 implementation instances :
> 1 instance for Component3/Component1
> 1 instance for Component3/Component2
> 1 instance for Component4/Component1
> 1 instance for Component4/Component2
>
> was (Author: julien.bigot):
> With this new patch, (plus the one titled second-solution.patch), the behavior should be as expected.
>
> - if more than one composite instance (i.e. component whose implementation is implementation.composite) are instances of the same composite (they share the same type) and if this composite contains a component whose scope is composite, *each one will have its own implementation instance*.
>
> In the case Simon explained
>
> CompositeA
> Component1 - implementation.java -> MyClass - scope = COMPOSITE
> Component2 - implementation.java -> MyClass - scope = COMPOSITE
>
> CompositeB
> Component3 - implementation.composite -> Composite A
> Component4 - implementation.composite -> Composite A
>
> There will be 4 implementation instances :
>
> If you fire up CompositeB there will be 4 implementation instances :
> 1 instance for Component3/Component1
> 1 instance for Component3/Component2
> 1 instance for Component4/Component1
> 1 instance for Component4/Component2
>
[jira] Issue Comment Edited: (TUSCANY-2643) composite scope handled
incorectly
Posted by "Julien Bigot (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640188#action_12640188 ]
julien.bigot edited comment on TUSCANY-2643 at 10/16/08 8:29 AM:
-----------------------------------------------------------------
With this new patch, (plus the one titled second-solution.patch), the behavior should be as expected.
- if more than one composite instance (i.e. component whose implementation is implementation.composite) are instances of the same composite (they share the same type) and if this composite contains a component whose scope is composite, *each one will have its own implementation instance*.
In the case Simon explained
CompositeA
Component1 - implementation.java -> MyClass - scope = COMPOSITE
Component2 - implementation.java -> MyClass - scope = COMPOSITE
CompositeB
Component3 - implementation.composite -> Composite A
Component4 - implementation.composite -> Composite A
If you fire up CompositeB there will be 4 implementation instances :
1 instance for Component3/Component1
1 instance for Component3/Component2
1 instance for Component4/Component1
1 instance for Component4/Component2
was (Author: julien.bigot):
With this new patch, (plus the one titled second-solution.patch), the behavior should be as expected.
- if more than one composite instance (i.e. component whose implementation is implementation.composite) are instances of the same composite (they share the same type) and if this composite contains a component whose scope is composite, *each one will have its own implementation instance*.
In the case Simon explained
CompositeA
Component1 - implementation.java -> MyClass - scope = COMPOSITE
Component2 - implementation.java -> MyClass - scope = COMPOSITE
CompositeB
Component3 - implementation.composite -> Composite A
Component4 - implementation.composite -> Composite A
There will be 4 implementation instances :
If you fire up CompositeB there will be 4 implementation instances :
1 instance for Component3/Component1
1 instance for Component3/Component2
1 instance for Component4/Component1
1 instance for Component4/Component2
> composite scope handled incorectly
> ----------------------------------
>
> Key: TUSCANY-2643
> URL: https://issues.apache.org/jira/browse/TUSCANY-2643
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SCA
> Affects Versions: Cpp-Next
> Environment: Svn revision 704493
> Reporter: Julien Bigot
> Attachments: copy_composite_on_instanciation.patch, first-solution.patch, second-solution.patch
>
>
> Scope composite is not handled correctly.
> The actual behavior is to return the same implementation instance for all call to a service of a component whose scope is composite. In the case where there is more than one component with composite scope, this means that the first implementation instantiated is returned regardless of the actual component one is looking for.
> If the two components have a different ComponentType, this will likely lead to a segfault.
> I have implemented another behavior.
> With my patch, when using a service of a composite implementation, the name of the component is used as a unique ID, this is still not optimal as two components can have the same name inside two different composite or if more than one instance of a given composite are created.
> This does not scale well too as a map is used. The straightforward solution would be to have the implementation instance referenced in the Component class. but as this class is defined in the tuscany::sca::model namespace, I'm not sure it is Ok to modify it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2643) composite scope handled incorectly
Posted by "Julien Bigot (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Bigot updated TUSCANY-2643:
----------------------------------
Attachment: first-solution.patch
> composite scope handled incorectly
> ----------------------------------
>
> Key: TUSCANY-2643
> URL: https://issues.apache.org/jira/browse/TUSCANY-2643
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SCA
> Affects Versions: Cpp-Next
> Environment: Svn revision 704493
> Reporter: Julien Bigot
> Attachments: first-solution.patch
>
>
> Scope composite is not handled correctly.
> The actual behavior is to return the same implementation instance for all call to a service of a component whose scope is composite. In the case where there is more than one component with composite scope, this means that the first implementation instantiated is returned regardless of the actual component one is looking for.
> If the two components have a different ComponentType, this will likely lead to a segfault.
> I have implemented another behavior.
> With my patch, when using a service of a composite implementation, the name of the component is used as a unique ID, this is still not optimal as two components can have the same name inside two different composite or if more than one instance of a given composite are created.
> This does not scale well too as a map is used. The straightforward solution would be to have the implementation instance referenced in the Component class. but as this class is defined in the tuscany::sca::model namespace, I'm not sure it is Ok to modify it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2643) composite scope handled incorectly
Posted by "Julien Bigot (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Bigot updated TUSCANY-2643:
----------------------------------
Attachment: copy_composite_on_instanciation.patch
With this new patch, (plus the one titled second-solution.patch), the behavior should be as expected.
- if more than one composite instance (i.e. component whose implementation is implementation.composite) are instances of the same composite (they share the same type) and if this composite contains a component whose scope is composite, *each one will have its own implementation instance*.
In the case Simon explained
CompositeA
Component1 - implementation.java -> MyClass - scope = COMPOSITE
Component2 - implementation.java -> MyClass - scope = COMPOSITE
CompositeB
Component3 - implementation.composite -> Composite A
Component4 - implementation.composite -> Composite A
There will be 4 implementation instances :
If you fire up CompositeB there will be 4 implementation instances :
1 instance for Component3/Component1
1 instance for Component3/Component2
1 instance for Component4/Component1
1 instance for Component4/Component2
> composite scope handled incorectly
> ----------------------------------
>
> Key: TUSCANY-2643
> URL: https://issues.apache.org/jira/browse/TUSCANY-2643
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SCA
> Affects Versions: Cpp-Next
> Environment: Svn revision 704493
> Reporter: Julien Bigot
> Attachments: copy_composite_on_instanciation.patch, first-solution.patch, second-solution.patch
>
>
> Scope composite is not handled correctly.
> The actual behavior is to return the same implementation instance for all call to a service of a component whose scope is composite. In the case where there is more than one component with composite scope, this means that the first implementation instantiated is returned regardless of the actual component one is looking for.
> If the two components have a different ComponentType, this will likely lead to a segfault.
> I have implemented another behavior.
> With my patch, when using a service of a composite implementation, the name of the component is used as a unique ID, this is still not optimal as two components can have the same name inside two different composite or if more than one instance of a given composite are created.
> This does not scale well too as a map is used. The straightforward solution would be to have the implementation instance referenced in the Component class. but as this class is defined in the tuscany::sca::model namespace, I'm not sure it is Ok to modify it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2643) composite scope handled incorectly
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639828#action_12639828 ]
Simon Laws commented on TUSCANY-2643:
-------------------------------------
Of course
CompositeB
Component3 - implementation.composite -> Composite A
Component4 - implementation.composite -> Composite B
Should have read
CompositeB
Component3 - implementation.composite -> Composite A
Component4 - implementation.composite -> Composite A
> composite scope handled incorectly
> ----------------------------------
>
> Key: TUSCANY-2643
> URL: https://issues.apache.org/jira/browse/TUSCANY-2643
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SCA
> Affects Versions: Cpp-Next
> Environment: Svn revision 704493
> Reporter: Julien Bigot
> Attachments: first-solution.patch, second-solution.patch
>
>
> Scope composite is not handled correctly.
> The actual behavior is to return the same implementation instance for all call to a service of a component whose scope is composite. In the case where there is more than one component with composite scope, this means that the first implementation instantiated is returned regardless of the actual component one is looking for.
> If the two components have a different ComponentType, this will likely lead to a segfault.
> I have implemented another behavior.
> With my patch, when using a service of a composite implementation, the name of the component is used as a unique ID, this is still not optimal as two components can have the same name inside two different composite or if more than one instance of a given composite are created.
> This does not scale well too as a map is used. The straightforward solution would be to have the implementation instance referenced in the Component class. but as this class is defined in the tuscany::sca::model namespace, I'm not sure it is Ok to modify it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-2643) composite scope handled incorectly
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Laws resolved TUSCANY-2643.
---------------------------------
Resolution: Fixed
Fix Version/s: Cpp-Next
Committed to trunk at r706173
> composite scope handled incorectly
> ----------------------------------
>
> Key: TUSCANY-2643
> URL: https://issues.apache.org/jira/browse/TUSCANY-2643
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SCA
> Affects Versions: Cpp-Next
> Environment: Svn revision 704493
> Reporter: Julien Bigot
> Assignee: Simon Laws
> Fix For: Cpp-Next
>
> Attachments: copy_composite_on_instanciation.patch, first-solution.patch, second-solution.patch
>
>
> Scope composite is not handled correctly.
> The actual behavior is to return the same implementation instance for all call to a service of a component whose scope is composite. In the case where there is more than one component with composite scope, this means that the first implementation instantiated is returned regardless of the actual component one is looking for.
> If the two components have a different ComponentType, this will likely lead to a segfault.
> I have implemented another behavior.
> With my patch, when using a service of a composite implementation, the name of the component is used as a unique ID, this is still not optimal as two components can have the same name inside two different composite or if more than one instance of a given composite are created.
> This does not scale well too as a map is used. The straightforward solution would be to have the implementation instance referenced in the Component class. but as this class is defined in the tuscany::sca::model namespace, I'm not sure it is Ok to modify it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2643) composite scope handled incorectly
Posted by "Julien Bigot (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Bigot updated TUSCANY-2643:
----------------------------------
Attachment: second-solution.patch
After some discussions with slaws on IRC, I think this solution is better. The behavior implemented is now the following : an implementation instance is linked to a component.
i.e.
- if more than one component whose scope is composite share the same componentType (even inside an unique composite), each one will have its own implementation instance.
- if more than one composite instance (i.e. component whose implementation is implementation.composite) are instances of the same composite (they share the same type) and if this composite contains a component whose scope is composite, these will share the same implementation instance.
> composite scope handled incorectly
> ----------------------------------
>
> Key: TUSCANY-2643
> URL: https://issues.apache.org/jira/browse/TUSCANY-2643
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SCA
> Affects Versions: Cpp-Next
> Environment: Svn revision 704493
> Reporter: Julien Bigot
> Attachments: first-solution.patch, second-solution.patch
>
>
> Scope composite is not handled correctly.
> The actual behavior is to return the same implementation instance for all call to a service of a component whose scope is composite. In the case where there is more than one component with composite scope, this means that the first implementation instantiated is returned regardless of the actual component one is looking for.
> If the two components have a different ComponentType, this will likely lead to a segfault.
> I have implemented another behavior.
> With my patch, when using a service of a composite implementation, the name of the component is used as a unique ID, this is still not optimal as two components can have the same name inside two different composite or if more than one instance of a given composite are created.
> This does not scale well too as a map is used. The straightforward solution would be to have the implementation instance referenced in the Component class. but as this class is defined in the tuscany::sca::model namespace, I'm not sure it is Ok to modify it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2643) composite scope handled incorectly
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Laws reassigned TUSCANY-2643:
-----------------------------------
Assignee: Simon Laws
> composite scope handled incorectly
> ----------------------------------
>
> Key: TUSCANY-2643
> URL: https://issues.apache.org/jira/browse/TUSCANY-2643
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SCA
> Affects Versions: Cpp-Next
> Environment: Svn revision 704493
> Reporter: Julien Bigot
> Assignee: Simon Laws
> Attachments: copy_composite_on_instanciation.patch, first-solution.patch, second-solution.patch
>
>
> Scope composite is not handled correctly.
> The actual behavior is to return the same implementation instance for all call to a service of a component whose scope is composite. In the case where there is more than one component with composite scope, this means that the first implementation instantiated is returned regardless of the actual component one is looking for.
> If the two components have a different ComponentType, this will likely lead to a segfault.
> I have implemented another behavior.
> With my patch, when using a service of a composite implementation, the name of the component is used as a unique ID, this is still not optimal as two components can have the same name inside two different composite or if more than one instance of a given composite are created.
> This does not scale well too as a map is used. The straightforward solution would be to have the implementation instance referenced in the Component class. but as this class is defined in the tuscany::sca::model namespace, I'm not sure it is Ok to modify it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2643) composite scope handled incorectly
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639826#action_12639826 ]
Simon Laws commented on TUSCANY-2643:
-------------------------------------
Hi Julien
I agree with;
- if more than one component whose scope is composite share the same componentType (even inside an unique composite), each one will have its own implementation instance.
Not sure I agree with;
- if more than one composite instance (i.e. component whose implementation is implementation.composite) are instances of the same composite (they share the same type) and if this composite contains a component whose scope is composite, these will share the same implementation instance.
If I have
CompositeA
Component1 - implementation.java -> MyClass - scope = COMPOSITE
Component2 - implementation.java -> MyClass - scope = COMPOSITE
CompositeB
Component3 - implementation.composite -> Composite A
Component4 - implementation.composite -> Composite B
In line with your first comment, if I fire up CompositeA then I would expect
1 instance of Component1
1 instance of Component2
If I fire up CompositeB then I would expect
1 instance of Component3/Component1
1 instance of Component3/Component2
1 instance of Component4/Component1
1 instance of Component4/Component2
Sound right?
Simon
> composite scope handled incorectly
> ----------------------------------
>
> Key: TUSCANY-2643
> URL: https://issues.apache.org/jira/browse/TUSCANY-2643
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SCA
> Affects Versions: Cpp-Next
> Environment: Svn revision 704493
> Reporter: Julien Bigot
> Attachments: first-solution.patch, second-solution.patch
>
>
> Scope composite is not handled correctly.
> The actual behavior is to return the same implementation instance for all call to a service of a component whose scope is composite. In the case where there is more than one component with composite scope, this means that the first implementation instantiated is returned regardless of the actual component one is looking for.
> If the two components have a different ComponentType, this will likely lead to a segfault.
> I have implemented another behavior.
> With my patch, when using a service of a composite implementation, the name of the component is used as a unique ID, this is still not optimal as two components can have the same name inside two different composite or if more than one instance of a given composite are created.
> This does not scale well too as a map is used. The straightforward solution would be to have the implementation instance referenced in the Component class. but as this class is defined in the tuscany::sca::model namespace, I'm not sure it is Ok to modify it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.