[
https://issues.apache.org/jira/browse/TUSCANY-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514641
]
Jean-Sebastien Delfino commented on TUSCANY-1346:
-------------------------------------------------
Huang,
I agree that we need to re-resolve existing components but I'm not sure that
this needs to be done in a separate thread. What did you have in mind with
threading?
For now, I have added support for incremental building of an SCA domain, with
the ability to build a domain, add a composite to it, rebuild the domain. The
newly added components will be able to target component services already in
place in the domain.
If my proposal for incremental building (committed under revision 558740) suits
everybody's requirements, we should be able to follow the same pattern to add
support for:
1. invalidating components that are wired to component services being removed
from a domain
2. handle composite updates by doing a remove + add
3. handle composite updates in a less disruptive way as long as the component
services that they contribute do not change
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
