[jira] Resolved: (TUSCANY-1346) Resolution to TUSCANY-1332 assumes a closed top-level composite that does not support addition of new components

["Jean-Sebastien Delfino (JIRA)" <tu...@ws.apache.org>]

     [ https://issues.apache.org/jira/browse/TUSCANY-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Sebastien Delfino resolved TUSCANY-1346.
---------------------------------------------

    Resolution: Fixed

I think that this is now fixed. Individual top level composites are assembled separately, and resolution of cross composite references is left to the responsibility of the particular bindings. This new design, by not trying to establish in memory model pointers between independent composites, removes the issues that we were seeing before when we had these pointers in place. In other words, we do not need to update these pointers anymore when independent composites are added/removed/updated, because these pointers do not exist anymore :)

> Resolution to TUSCANY-1332 assumes a closed top-level composite that does not support addition of new components
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-1346
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1346
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Assembly Model, Java SCA Core Runtime, Java SCA Embedded Runtime
>    Affects Versions: Java-SCA-0.90, Java-SCA-0.91
>            Reporter: Matthew Sykes
>            Assignee: Jean-Sebastien Delfino
>             Fix For: Java-SCA-Next
>
>
> The resolution to TUSCANY-1332 involved exploitation of the composite include function to "include" all known deployable composites into the domain such that the components contained within the deployable composites would be wired together when the domain level composite was activated.  While this resolved the issues of wiring across multiple composites contained within different contributions, this approach requires that the system know of all composites that may be part of the domain at the time the domain is activated.
> When embedding Tuscany in a server runtime, however, deployment and activation of composites may occur after the domain is activated.  With the current implementation that is contained with EmbeddedSCADomain, runtimes that consume Tuscany would have to stop and restart the domain composite to deploy and activate new components and their services.  While this may be appropriate for small systems, it's not workable in complex environments.
> I believe Tuscany needs a wiring and activation model that is more dynamic such that components can be added to (or removed from) the domain and wired after the domain composite was initially activated.  This flexibility would have implications to the way wiring is done and how multiplicity is validated as the shape of the domain changes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org