[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
