tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luciano Resende" <luckbr1...@gmail.com>
Subject Re: Contribution services and SCDL4J
Date Sun, 08 Apr 2007 21:19:38 GMT
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 <for.svkrish@gmail.com> 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 <jsdelfino@apache.org> 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 <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
> > >>
> > >>
> > >
> >
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>



-- 
Luciano Resende
http://people.apache.org/~lresende

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message