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
Resolvers.
- 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
