You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Ramkumar R <ra...@gmail.com> on 2009/11/09 11:48:10 UTC
[2.x] SCA artifact resolution mechanism
The SCA Assembly Model Spec v1.1 states the following in section 11.2.1.
11.2.1 SCA Artifact Resolution
3458 When a contribution contains a reference to an artifact from a
namespace that is declared in an import
3459 statement of the contribution, if the SCA artifact resolution mechanism
is used to resolve the artifact, the
3460 SCA runtime MUST resolve artifacts in the following order:
3461 1. from the locations identified by the import statement(s) for the
namespace. Locations MUST NOT
3462 be searched recursively in order to locate artifacts (i.e. only a
one-level search is performed).
3463 2. from the contents of the contribution itself. [ASM12023]
Currently, the ModelResolver does not consider the location attribute while
resolving the artifacts.
I believe we need to replace the existing method in our
org.apache.tuscany.sca.contribution.resolver.ModelResolver
code...
<T> T resolveModel(Class<T> modelClass, T unresolved, ProcessorContext
context);
with...
<T> T resolveModel(Class<T> modelClass, T unresolved, String
contributionLocaiton, ProcessorContext context);
to make this work as specified in the specs.
Please let me know, if there are any concerns over this approach. Thanks.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [2.x] SCA artifact resolution mechanism
Posted by Ramkumar R <ra...@gmail.com>.
Fixes were required in the DeployerImpl code to take care of resolving
import.java using location attribute.
Committed revision 835344.
On Thu, Nov 12, 2009 at 2:42 PM, Ramkumar R <ra...@gmail.com> wrote:
> Hi Ant,
>
> Sure, I will take a look at this one.
>
>
> On Thu, Nov 12, 2009 at 2:35 PM, ant elder <an...@gmail.com> wrote:
>
>> On Tue, Nov 10, 2009 at 9:32 AM, Ramkumar R <ra...@gmail.com>
>> wrote:
>> > Thanks for your suggestion Luciano.
>> >
>> > I have fixed this issue by modifying the deployer to add dependencies
>> > based on the namespace location attribute.
>> >
>> > Committed at revision 834397.
>> >
>>
>> There are several tests in the Java Implementation conformance test
>> suite related to imports which are still failing:
>>
>> POJO_9004_TestCase
>> POJO_9005_TestCase
>> POJO_10001_TestCase
>> POJO_10006_TestCase
>>
>> As you've just been looking at the area would you take a look?
>>
>> ...ant
>>
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [2.x] SCA artifact resolution mechanism
Posted by Ramkumar R <ra...@gmail.com>.
Hi Ant,
Sure, I will take a look at this one.
On Thu, Nov 12, 2009 at 2:35 PM, ant elder <an...@gmail.com> wrote:
> On Tue, Nov 10, 2009 at 9:32 AM, Ramkumar R <ra...@gmail.com> wrote:
> > Thanks for your suggestion Luciano.
> >
> > I have fixed this issue by modifying the deployer to add dependencies
> > based on the namespace location attribute.
> >
> > Committed at revision 834397.
> >
>
> There are several tests in the Java Implementation conformance test
> suite related to imports which are still failing:
>
> POJO_9004_TestCase
> POJO_9005_TestCase
> POJO_10001_TestCase
> POJO_10006_TestCase
>
> As you've just been looking at the area would you take a look?
>
> ...ant
>
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [2.x] SCA artifact resolution mechanism
Posted by ant elder <an...@gmail.com>.
On Tue, Nov 10, 2009 at 9:32 AM, Ramkumar R <ra...@gmail.com> wrote:
> Thanks for your suggestion Luciano.
>
> I have fixed this issue by modifying the deployer to add dependencies
> based on the namespace location attribute.
>
> Committed at revision 834397.
>
There are several tests in the Java Implementation conformance test
suite related to imports which are still failing:
POJO_9004_TestCase
POJO_9005_TestCase
POJO_10001_TestCase
POJO_10006_TestCase
As you've just been looking at the area would you take a look?
...ant
Re: [2.x] SCA artifact resolution mechanism
Posted by Ramkumar R <ra...@gmail.com>.
Thanks for your suggestion Luciano.
I have fixed this issue by modifying the deployer to add dependencies
based on the namespace location attribute.
Committed at revision 834397.
On Mon, Nov 9, 2009 at 9:51 PM, Luciano Resende <lu...@gmail.com>wrote:
> On Mon, Nov 9, 2009 at 3:01 AM, Simon Laws <si...@googlemail.com>
> wrote:
> > Hi Ram
> >
> > I thought the location specific to the import processing. Why would we
> > want it on the resolveModel interface generally?
> >
> > Regards
> >
>
> Yes, I think the idea is, if you find a specific contribution URI on
> the import, then you delegate to the resolver of the specific
> contribution, otherwise, you delegate to the special resolver that
> goes over a broad set of contributions. This filter could probably be
> done either with the "match" algorithm available in the import/export
> models or when the Deployer process the dependencies (see
> DeployerImpl.addContributionDependencies)
>
> --
> Luciano Resende
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [2.x] SCA artifact resolution mechanism
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Nov 9, 2009 at 3:01 AM, Simon Laws <si...@googlemail.com> wrote:
> Hi Ram
>
> I thought the location specific to the import processing. Why would we
> want it on the resolveModel interface generally?
>
> Regards
>
Yes, I think the idea is, if you find a specific contribution URI on
the import, then you delegate to the resolver of the specific
contribution, otherwise, you delegate to the special resolver that
goes over a broad set of contributions. This filter could probably be
done either with the "match" algorithm available in the import/export
models or when the Deployer process the dependencies (see
DeployerImpl.addContributionDependencies)
--
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [2.x] SCA artifact resolution mechanism
Posted by Simon Laws <si...@googlemail.com>.
Hi Ram
I thought the location specific to the import processing. Why would we
want it on the resolveModel interface generally?
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com