In case you want to see it all working together, SCARuntimeTestCase in the host-embedded module is a good place to start, it will drive the contributionServices wired to all dependencies it have.
On 4/8/07, Venkata Krishnan <[EMAIL PROTECTED]> 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? 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. 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. > 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 > >> > >> > >> --------------------------------------------------------------------- > >> 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] > >
-- Luciano Resende http://people.apache.org/~lresende
