tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@apache.org>
Subject Re: Contribution services and SCDL4J
Date Sun, 08 Apr 2007 16:59:40 GMT
Some answers inline.

Venkata Krishnan wrote:
> Hi,
> I am catching up with all the work that is going on in 'modules' and am
> trying my best join the party.  Here are some questions that have come 
> up my
> mond... please help me with answers.
> - I see that the 'resolve' method in ArtifactProcessor has an argument
> 'resolver'.   Where is this resolver going to be passed from ?  I see 
> in the
> testcases that this resolver is created and then passed, but don't 
> quite get
> the bigger picture as to how a chain of resolvers would be 
> instantiated and
> passed around.  For example when the CompositeProcessor's resolve 
> method  is
> called what is the resolver that would be used.

The resolver is used by an ArtifactProcessor.resolve(model, resolver) 
method to resolve references to external models. For example you can use 
it to resolve another Composite, or a WSDLInterface referenced by one of 
your Services.

An ArtifactResolver takes an unresolved object, for example another 
Composite with its unresolved flag set to true, and is responsible for 
returning the resolved object: the actual Composite found within the 
scope of your current SCA Contribution.

We currently have a single minimalistic implementation of 
ArtifactResolver based on just a HashMap. The ContributionService puts 
into it all models returned by the ArtifactProcessor.read(...) methods. 
So, models are loaded first, then put in the ArtifactResolver's map, 
then ArtifactResolver.resolve(an unresolved Composite) finds the 
resolved Composite with the same name. At the moment, resolvable models 
like CompositeImpl implement the equals() method for this to work with 
the simple HashMap ArtifactResolver implementation.

If the resolved model object implements ArtifactResolver itself, then we 
delegate further resolution to it. I think that this will be useful to 
resolve nested models, for example WSDL portTypes or XML schemas inside 
WSDL definitions, but this capability is not used yet. This can probably 
be used as well later to replace the custom equals() methods if we prefer.

So, to summarize, at the moment, there is a single default Resolver, 
containing all models loaded from a given SCA contribution. Models are 
resolved from this single Resolver's map. I may be wrong, but I don't 
think we'll ever need the current ArtifactResolverRegistry or chains of 

> - To start putting my hands as well into this, I was looking for a humble
> start with respect to property loading.  For example if I were to verify
> where a component property defined is actually existing in the underlying
> componentType where and when would I do this.  I suppose it would be 
> in the
> 'resolve' phase  right ?

The resolve phase is probably a little early for this as you won't be 
able to assume that the ComponentTypes defining your Components are 
complete, and in particular that their references to XML types are 
already resolved. So, my recommendation is to:
- Keep the resolve() method to actual resolution of external models, for 
example resolve the references to ComponentTypes.
- Use the wire() method to further "wire" things together, for example 
connect a ComponentReference to the Reference that defines its 
characteristics in the Component's ComponentType, or merge/normalize 
property definitions between the ComponentType, the Component and its 
configuration in the enclosing Composite.

By the way I'm still not sure about how to call this "wire()" method. 
We've tried several names:
- normalize()
- optimize()
- wire()

Maybe configure() is a better name :) I'd be interested in any thoughts 
on this.

> If so which processor should do this?  I was
> looking at the CompositeProcessor.resolve for a place to do this but then
> ended up with the question in the first bullet.  (hope this is not 
> already
> done and I have missed it)

I think CompositeProcessor.wire() is the best place to do this.

> - The 'Reference' interface in assembly has accessor methods for
> 'autowire'.  I wonder if this should move up to ComponentReference as 
> I did
> not see the relvence of 'autowire' in componentType references and 
> composite
> references.  Am I missing a point ?

Good point, yes autowire should probably move up to ComponentReference.

> Thanks
> - Venkat
> On 4/6/07, Jean-Sebastien Delfino <jsdelfino@apache.org> wrote:
>> Luciano Resende wrote:
>> > I have also made some progress on this: I have simplified the
>> > packageProcessors interfaces, making it responsible only for 
>> providing a
>> > list of artifacts that need to be processed, and processing now
>> > should/will
>> > be driven by the contributionServiceImpl.
>> >
>> > I have also started to integrate the artifactProcessors and it's
>> > phases into
>> > the contributionServiceImpl, but had a question about whether or 
>> not the
>> > contribution-impl should have dependencies on assembly-impl-xml in
>> > order to
>> > be able to perform some unit tests using the artifactProcessors 
>> defined
>> > there. Thoughts ?
>> >
>> >
>> It may be simpler to write a test ArtifactProcessor in
>> contribution-impl. This way, if I break assembly-xml for example, I
>> won't break your contribution-impl unit test.
>> More generally, the contribution framework provides a base platform for
>> various extensions/plug-ins, assembly, policy, implementation-java etc.
>> So, it would look odd to have the contribution framework implementation
>> depend on one of the extensions, even for testing purposes.
>> If you have your own test ArtifactProcessor in contribution-impl, we
>> also need to test the integration of assembly-xml and contribution-impl,
>> but this can be tested in assembly-xml itself..
>> -- 
>> Jean-Sebastien
>> ---------------------------------------------------------------------
>> 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

View raw message