You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Greg Dritschler (JIRA)" <tu...@ws.apache.org> on 2007/05/03 22:35:15 UTC

[jira] Updated: (TUSCANY-1242) Provide a runtime which supports multiple composites

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

Greg Dritschler updated TUSCANY-1242:
-------------------------------------

    Attachment: jira.patch

The patch is a first step at providing a Tuscany runtime that supports multiple composites.

I decided to break the logic in SimpleRuntimeImpl.start into separate methods for adding a contribution and deploying components.  The method signatures are based on the way the code in SimpleRuntimeImpl.start() currently works.  Clearly these aren't the method signatures we want in the end.  However the code to support the contribution service and to resolve the model discrepancies is still in progress, so it is difficult to come up with better interfaces right at this moment.

I also added methods to SimpleRuntimeImpl to support undeploying components and removing a contribution.  Again I expect the signatures to evolve.

I changed DefaultSCARuntime to call the new methods in SimpleRuntimeImpl appropriately.  The names of these two classes perhaps are backwards -- DefaultSCARuntime perhaps should provide the basic runtime infrastructure and SimpleRuntimeImpl perhaps should be the class that provides a simple runtime capable of running one contribution.  However I decided not to rename things at this point to make it easier to accept the patch.

Other changes:

* ContributionServiceImpl uses an ArtifactResolver to resolve artifacts in contributions.  The problem is that the default implementation DefaultArtifactResolver doesn't know how  to isolate artifacts by contribution.  As a temporary workaround, I changed   ContributionServiceImpl to use a transient DefaultArtifactResolver during resolution processing.  Follow on work will be needed to work out the correct relationship between the ContributionService,  a Contribution, and an ArtifactResolver.

* BuilderRegistryImpl was using the ComponentManager to keep lists of SCAObjects and model objects for the deployer to be able to correlate them.  These lists are really a temporary workaround for relating the different models.  Furthermore the lists are transient and don't need to be kept after a deploy completes.  For that reason I moved the lists from the ComponentManager to the DeploymentContext.  I expect the lists will go away altogether when the model relationship issues are resolved.

* I moved the code which sets up SimpleCompositeContextImpl from SimpleRuntimeImpl to DefaultSCARuntime.  This is something that belongs on the thread of execution.  DefaultSCARuntime "knows" the application is going to run on the current thread.  SimpleRuntimeImpl shouldn't assume that.

* I removed the tuscanySystem member variable in SimpleRuntimeImpl, which pointed to the single composite that start() handled before.  Since the runtime has to handle more than one composite,  this variable doesn't make sense anymore.  I had to change some of the code that was using tuscanySystem to do component lookups.

* I removed the use of SimpleRuntimeInfo which didn't seem to be serving much purpose anymore.

> Provide a runtime which supports multiple composites
> ----------------------------------------------------
>
>                 Key: TUSCANY-1242
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1242
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: Java SCA Standalone Runtime
>            Reporter: Greg Dritschler
>         Attachments: jira.patch
>
>
> The current runtime implementations are capable of starting a single composite only.  This isn't very usable outside a standalone environment.

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