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

2007-06-22 Thread Huang Kai (JIRA)

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

Huang Kai commented on TUSCANY-1346:


How about re-resolving the original and newly added components in a 
seperate thread, and replace all the old components when the resolvement is 
done. 
My rough thought is: Clone all the components, and do the rewiring work in 
the cloned compnents, but keep all the 
implementationProvider/bindingProvider/scopeContainer refer to the same 
instance to keep their states unchanged.   

 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

 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]



[jira] Created: (TUSCANY-1319) contribution meta documents not merged

2007-05-31 Thread Huang Kai (JIRA)
contribution meta documents not merged
--

 Key: TUSCANY-1319
 URL: https://issues.apache.org/jira/browse/TUSCANY-1319
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Reporter: Huang Kai


in SCA spec 1.10.2.2 write: ...accommodate this, it is also possible to have 
an identically structured document at META-INF/sca-contribution-generated.xml. 
If this document exists (or is generated on an as-needed basis), it will be 
merged into the contents of sca-contribution.xml, with the entries in 
sca-contribution.xml taking priority if there are any conflicting declarations.
Tuscany seems won't load sca-contribution-generated.xml if sca-contribution.xml 
exists.


-- 
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]