You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2007/03/16 18:08:56 UTC
ArtifactResolver questions
On Mar 16, 2007, at 9:46 AM, Raymond Feng wrote:
> Hi,
>
> Contribution is the model object that hosts the metadata and
> introspected result for the contribution. Logically, you can use
> the URI of the contribution to look up the ContributionService to
> get the Contribution. I found it simpler for ArtifactResolver
> extensions to receive Contribution directly.
Doesn't this just move the responsibility for lookup to the caller of
this SPI? And given the caller should not know about the
implementation, it has to be passed every time even if the resolver
does not need that information?
Actually, why is this a parameter at all? What makes Contribution
different from any other attribute passed in the Map?
Finally, why is DeploymentContext passed - can't I use this outside
the load phase?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: ArtifactResolver questions
Posted by Jim Marino <jm...@myromatours.com>.
>
> My orginal mindset is that we need some context for the resolving,
> for example, a resolver might use the classloader to resolve
> relative URIs.
>
> Isn't DeploymentContext designed for Load/Resolve/Build?
With the federated architecture, we can't assume DeploymentContext
anymore or that the steps above occur in the same VM. I posted a
message earlier today outlining some of this but the key thing is
that building happens on slave nodes and it is against a
PhysicalChangeSet, not the logical model. The logical model will be
handled on the Controller, which will also be responsible for
resolution, normalization, and generation of PhysicalChangeSets sets
comprising PhysicalComponentDefinitions, PhysicalWireDefinitions, and
PhysicalResourceDefinitions. This will be marshalled across to the
appropriate nodes.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: ArtifactResolver questions
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I think it might be better to polish the interface later on during the
integration of contribution service stuff that Luciano is working on.
Anyway, some comments below.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Friday, March 16, 2007 10:08 AM
Subject: ArtifactResolver questions
> On Mar 16, 2007, at 9:46 AM, Raymond Feng wrote:
>
>> Hi,
>>
>> Contribution is the model object that hosts the metadata and
>> introspected result for the contribution. Logically, you can use the URI
>> of the contribution to look up the ContributionService to get the
>> Contribution. I found it simpler for ArtifactResolver extensions to
>> receive Contribution directly.
>
> Doesn't this just move the responsibility for lookup to the caller of
> this SPI? And given the caller should not know about the implementation,
> it has to be passed every time even if the resolver does not need that
> information?
>
I thought "lookup once" at the higher level is better.
> Actually, why is this a parameter at all? What makes Contribution
> different from any other attribute passed in the Map?
>
The Map is used to hold addiontal attributes to further constrain the query
and the entries are resolver-specific as I understand. I think we like the
"strongly-typed" approach more.
> Finally, why is DeploymentContext passed - can't I use this outside the
> load phase?
>
My orginal mindset is that we need some context for the resolving, for
example, a resolver might use the classloader to resolve relative URIs.
Isn't DeploymentContext designed for Load/Resolve/Build?
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org