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
signature.asc
Description: This is a digitally signed message part.
