On Mon, Oct 20, 2008 at 9:52 AM, Julien Bigot <[EMAIL PROTECTED]> 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
