[
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.
