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
