Some comments inline.
Greg Dritschler wrote:
On 4/24/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
You'll need one instance of ArtifactResolver per application as well.
Is the ArtifactResolver eventually intended to resolve artifacts within a
single contribution ("application") only or across contributions in the
domain? The comments at the top of the interface make me think it is the
latter.
I'm not sure that there's a 1..1 relationship between application and
contribution. For one thing, a contribution can reference artifacts
outside itself, potentially in other contributions, so an application
will probably need a graph of contributions instead of just one
contribution. Another scenario is when a given contribution declares
multiple (deployable) composites containing multiple top level
components. I would have to understand the deployment scheme you have in
mind, but if you want to have one application per top level component
for example, then you'll have multiple applications using the same
contribution (and its dependencies).
To try to answer your specific question on ArtifactResolver. I think
that an ArtifactResolver should handle a graph of contributions: a
contribution, the other contributions it depends on, and imported
external resources as well. If you're mapping this graph to what you
mean by "application" then you need one ArtifactResolver per application.
If you're referring to the following comment at the top ArtifactResolver:
"In the SCA assemblies, these various artifacts are referenced using
either QNames or URIs that do not point to a specific entity. Resolution
of these references to concrete artifacts is necessary as part of the
operation of the SCA domain."
... this is simply trying to say that artifact resolution is an
important function in an SCA domain.
Here's an extract from the SCA assembly spec covering the same subject:
"The SCA artifact resolution is likely to be most useful for SCA domains
containing heterogeneous mixtures of contribution, where
artifact-related or packaging-related mechanisms are unlikely to work
across different kinds of contribution."
If instead it is the case that it resolves artifacts within a
single contribution only, it isn't clear to me how to set this up since
there seems to be a 1:1 relationship between the ContributionService
and the
ArtifactResolver.
Here is how the relationships are set up at the moment:
- one ArtifactResolver per ContributionService
- multiple ContributionServices per contribution repository (this may
change as we've just started to implement this repository thing)
- multiple Contributions per ContributionService
- multiple Contributions per contribution repository
So I would recommend to create one instance of ContributionService per
application, with its own ArtifactResolver. This will give you the
ability to have isolated applications, one or more contributions per
application, potentially sharing artifacts (and their resolution)
between the contributions loaded in that application.
To make this more concrete, I'll probably spend a little bit of time and
will try to come up with a slightly different variation of
SimpleRuntimeImpl showing how to do that, but that will basically just
split the start method into two methods around line 148.
I'm also wondering about the code in DeployerImpl.deploy that connects
objects. It starts as follows:
// Connect components, services and references
List<SCAObject> scaObjects = componentManager.getSCAObjects();
Since there is one deployer, and the deployer has one component manager,
this says to me that every time a composite is deployed, all
registered SCA
objects are going to be connected. If multiple contributions are
deployed
is that what should happen?
I don't think that the deployer should attempt to rewire components that
have already been wired :) I'm not sure I fully understand your question
as deployment/wiring is not really related to contributions and wiring
needs to go across components in different contributions, but let me
investigate this code further and see if there is a problem in the
Deployer, or not, when multiple applications are activated separately.
Greg Dritschler
Hope this helps.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
