Thanks Luciano... I will look that up as well. - Venkat
On 4/9/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
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
