More answers inline.
Venkata Krishnan wrote:
Hi Sebastien,
First, many thanks for this very explanatory reply. Please find further
queries below. Thanks.
- Venkat
On 4/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
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 can I assimilate what you have mentioned above for the following as
well.
i.e. have ComponentImpl implement ArtifactResolver and make it resolve
the
implementation, reference, property and service within it. The
implementation also implements ArtifactProcessor to resolve the
underlying
componentType. Is this thinking right?
I'm not sure you need that. ArtifactResolver can be used to resolve the
main relationships to external models, basically the links between
different documents, like Composite --> JavaImplementation, or Composite
--> JavaInterface or WSDLInterface. In these cases you have a link to
the top level element of a document. I think that the relationship
between a ComponentReference and the corresponding Reference inside the
Component's Implementation is of a different nature, it can be derived
from the Component --> Implementation relationship.
After thinking more about this, I mispoke in my earlier explanation
above, when I said "resolve nested models, for example WSDL portTypes or
XML schemas inside WSDL". ArtifactResolver will be useful to resolve
nested XML schemas, but will probably not be necessary to resolve
PortTypes, since once you've resolved the WSDL Definition it's easiy
enough to do definition.getPortType(qname), we don't need an
ArtifactResolver to find the portType. I realized that yesterday when I
started to integrate the code from idl-wsdl which was dealing with WSDL
in the new interface-wsdl-xml module.
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.
I get this and will start working on this. So am just going to string up
properties, services and references starting from componentTypes at the
bottom upto the composite level.
Sounds good. Thanks!
However, I must say there is quite a bit
that has been covered already by you in this :) and I shall cover up the
left overs.
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.
I'd say 'configure' would be a bit confusing as that is overloaded
already
with some connotations. I understand that we are basically 'linking' up
resolved artifacts and hence could relate to 'wire' better. Do you
want to
use 'link'? Guess we could leave it as is for now.
Yes, link() seems better. I'd like to get other opinions as well and
then if nobody else comes with a better name. I'll rename to link() in a
few days.
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.
I shall take care of this to jump into this modularization effort.
Thanks
> 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
>>
>>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
