You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2007/04/03 09:47:14 UTC
Contribution services and SCDL4J
I have committed some new contribution services interfaces under revision #
525071 that would better align the contribution service module with the
SCDL4J proposals. Note that some of these interfaces, that would be used for
artifact resolving, will need to be implemented by the Assembly model
classes.
Please take a look at these interfaces and let me know what you guys think,
I plan to polish them little bit more tomorrow, and then start integrating
it with the other modules and the embedded runtime.
Thoughts ?
--
Luciano Resende
http://people.apache.org/~lresende
Re: Contribution services and SCDL4J
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <js...@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?
>
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 <js...@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
>> >>
>> >>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Contribution services and SCDL4J
Posted by Venkata Krishnan <fo...@gmail.com>.
Thanks Luciano... I will look that up as well.
- Venkat
On 4/9/07, Luciano Resende <lu...@gmail.com> 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 <fo...@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 <js...@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 <js...@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
>
Re: Contribution services and SCDL4J
Posted by Luciano Resende <lu...@gmail.com>.
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 <fo...@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 <js...@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 <js...@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
Re: Contribution services and SCDL4J
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Sebastien,
First, many thanks for this very explanatory reply. Please find further
queries below. Thanks.
- Venkat
On 4/8/07, Jean-Sebastien Delfino <js...@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 <js...@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
>
>
Re: Contribution services and SCDL4J
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <js...@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
Re: Contribution services and SCDL4J
Posted by Venkata Krishnan <fo...@gmail.com>.
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.
- 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 ? 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)
- 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 ?
Thanks
- Venkat
On 4/6/07, Jean-Sebastien Delfino <js...@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
>
>
Re: Contribution services and SCDL4J
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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
Re: Contribution services and SCDL4J
Posted by Luciano Resende <lu...@gmail.com>.
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 ?
On 4/4/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Jean-Sebastien Delfino wrote:
> > [snip]
> > Luciano Resende wrote:
> >> Hi Sebastien
> >>
> >> Your understanding is very right, with the new artifactProcessor
> >> interfaces, we should be able to separate the load phases in multiple
> >> phases
> >> as you described.
> >>
> >> As for your specific questions, let me try to clarify :
> >>
> >>> - The assembly module deals with 3 types of files, .componentType,
> >> .constrainingType, .composite.
> >>> Does that mean I have to implement 3 ArtifactProcessors?
> >>
> >> Not necessarily, you can associate multiple file types with same
> >> processor,
> >> as an example, I had previously associated .scdl and .composite all
> >> with the
> >> SCDLProcessor. It all depends on the algorithms used to process these
> >> files,
> >> if they are the same or very simmilar, you might consider building one
> >> artifact processor, otherwise, you should create multiple processors
> >>
> >>> If the answer is yes, how do I associate a particular
> ArtifactProcessor
> >> with a file type?
> >>
> >> Basically, the PackageProcessors will scan a file system or jar archive
> >> contribution, and for each artifact, it will use the contentType
> >> describer
> >> to identify what type of file it is, and call the artifactProcessor
> >> registered for the artifact type. At the moment, an artifactProcessor
> >> can
> >> only register for one type, but you make the contentType describer
> >> recognize
> >> multiple files extensions as one unique type as the example I described
> >> above (.scdl and .composite).
> >>
> >> Talking about this, one thing that I wasn't planning to do for now, is
> >> plugability to extend the contentType describer, so new types could be
> >> recognized... but I'm starting to think we might need this ? Thoughts ?
> >>
> >> BTW, I should have the artifactResolver registry and other things
> >> necessary
> >> to exercise the processors you are implementing by EOD today (sometime
> >> tonight) ...
> >>
> >
> > I think that we need to make this extensible, to support different
> > content types without having to go change the code in a central
> > ContentDescriber. I'm also not sure about how an artifact processor
> > can be associated with a content type.
> >
> > So, instead of each extension having to:
> > - write a ContentDescriber that returns a ContentType for say
> > .composite files
> > - register the ContentDescriber in some registry
> > - having to know about an ArtifactProcessorRegistry in my
> > ArtifactProcessor implementation
> > - register myself in that registry with that content type for
> > .composite...
> >
> > Could we start simple and I would just implement a String
> > getContentType() method (to be added to ArtifactProcessor), return
> > ".composite" from that method, and that would be your indication that
> > you need to invoke me on .composite files?
> >
>
> More progress on this: I have committed a first cut of the changes to
> port the assembly, idl-java, idl-wsdl and impl-java modules to the
> ArtifactProcessor contribution SPI. The test cases that exercize the
> artifact processors manually all seem to work.
>
> Next step: I'm going to move some of the resolution code and the logic
> to establish wires and normalize policies and component configuration to
> the ArtifactProcessors as well.
>
> --
> 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
Re: Contribution services and SCDL4J
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> [snip]
> Luciano Resende wrote:
>> Hi Sebastien
>>
>> Your understanding is very right, with the new artifactProcessor
>> interfaces, we should be able to separate the load phases in multiple
>> phases
>> as you described.
>>
>> As for your specific questions, let me try to clarify :
>>
>>> - The assembly module deals with 3 types of files, .componentType,
>> .constrainingType, .composite.
>>> Does that mean I have to implement 3 ArtifactProcessors?
>>
>> Not necessarily, you can associate multiple file types with same
>> processor,
>> as an example, I had previously associated .scdl and .composite all
>> with the
>> SCDLProcessor. It all depends on the algorithms used to process these
>> files,
>> if they are the same or very simmilar, you might consider building one
>> artifact processor, otherwise, you should create multiple processors
>>
>>> If the answer is yes, how do I associate a particular ArtifactProcessor
>> with a file type?
>>
>> Basically, the PackageProcessors will scan a file system or jar archive
>> contribution, and for each artifact, it will use the contentType
>> describer
>> to identify what type of file it is, and call the artifactProcessor
>> registered for the artifact type. At the moment, an artifactProcessor
>> can
>> only register for one type, but you make the contentType describer
>> recognize
>> multiple files extensions as one unique type as the example I described
>> above (.scdl and .composite).
>>
>> Talking about this, one thing that I wasn't planning to do for now, is
>> plugability to extend the contentType describer, so new types could be
>> recognized... but I'm starting to think we might need this ? Thoughts ?
>>
>> BTW, I should have the artifactResolver registry and other things
>> necessary
>> to exercise the processors you are implementing by EOD today (sometime
>> tonight) ...
>>
>
> I think that we need to make this extensible, to support different
> content types without having to go change the code in a central
> ContentDescriber. I'm also not sure about how an artifact processor
> can be associated with a content type.
>
> So, instead of each extension having to:
> - write a ContentDescriber that returns a ContentType for say
> .composite files
> - register the ContentDescriber in some registry
> - having to know about an ArtifactProcessorRegistry in my
> ArtifactProcessor implementation
> - register myself in that registry with that content type for
> .composite...
>
> Could we start simple and I would just implement a String
> getContentType() method (to be added to ArtifactProcessor), return
> ".composite" from that method, and that would be your indication that
> you need to invoke me on .composite files?
>
More progress on this: I have committed a first cut of the changes to
port the assembly, idl-java, idl-wsdl and impl-java modules to the
ArtifactProcessor contribution SPI. The test cases that exercize the
artifact processors manually all seem to work.
Next step: I'm going to move some of the resolution code and the logic
to establish wires and normalize policies and component configuration to
the ArtifactProcessors as well.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Contribution services and SCDL4J
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Luciano Resende wrote:
> Hi Sebastien
>
> Your understanding is very right, with the new artifactProcessor
> interfaces, we should be able to separate the load phases in multiple
> phases
> as you described.
>
> As for your specific questions, let me try to clarify :
>
>> - The assembly module deals with 3 types of files, .componentType,
> .constrainingType, .composite.
>> Does that mean I have to implement 3 ArtifactProcessors?
>
> Not necessarily, you can associate multiple file types with same
> processor,
> as an example, I had previously associated .scdl and .composite all
> with the
> SCDLProcessor. It all depends on the algorithms used to process these
> files,
> if they are the same or very simmilar, you might consider building one
> artifact processor, otherwise, you should create multiple processors
>
>> If the answer is yes, how do I associate a particular ArtifactProcessor
> with a file type?
>
> Basically, the PackageProcessors will scan a file system or jar archive
> contribution, and for each artifact, it will use the contentType
> describer
> to identify what type of file it is, and call the artifactProcessor
> registered for the artifact type. At the moment, an artifactProcessor can
> only register for one type, but you make the contentType describer
> recognize
> multiple files extensions as one unique type as the example I described
> above (.scdl and .composite).
>
> Talking about this, one thing that I wasn't planning to do for now, is
> plugability to extend the contentType describer, so new types could be
> recognized... but I'm starting to think we might need this ? Thoughts ?
>
> BTW, I should have the artifactResolver registry and other things
> necessary
> to exercise the processors you are implementing by EOD today (sometime
> tonight) ...
>
I think that we need to make this extensible, to support different
content types without having to go change the code in a central
ContentDescriber. I'm also not sure about how an artifact processor can
be associated with a content type.
So, instead of each extension having to:
- write a ContentDescriber that returns a ContentType for say .composite
files
- register the ContentDescriber in some registry
- having to know about an ArtifactProcessorRegistry in my
ArtifactProcessor implementation
- register myself in that registry with that content type for .composite...
Could we start simple and I would just implement a String
getContentType() method (to be added to ArtifactProcessor), return
".composite" from that method, and that would be your indication that
you need to invoke me on .composite files?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Contribution services and SCDL4J
Posted by Luciano Resende <lu...@gmail.com>.
Hi Sebastien
Your understanding is very right, with the new artifactProcessor
interfaces, we should be able to separate the load phases in multiple phases
as you described.
As for your specific questions, let me try to clarify :
>- The assembly module deals with 3 types of files, .componentType,
.constrainingType, .composite.
> Does that mean I have to implement 3 ArtifactProcessors?
Not necessarily, you can associate multiple file types with same processor,
as an example, I had previously associated .scdl and .composite all with the
SCDLProcessor. It all depends on the algorithms used to process these files,
if they are the same or very simmilar, you might consider building one
artifact processor, otherwise, you should create multiple processors
> If the answer is yes, how do I associate a particular ArtifactProcessor
with a file type?
Basically, the PackageProcessors will scan a file system or jar archive
contribution, and for each artifact, it will use the contentType describer
to identify what type of file it is, and call the artifactProcessor
registered for the artifact type. At the moment, an artifactProcessor can
only register for one type, but you make the contentType describer recognize
multiple files extensions as one unique type as the example I described
above (.scdl and .composite).
Talking about this, one thing that I wasn't planning to do for now, is
plugability to extend the contentType describer, so new types could be
recognized... but I'm starting to think we might need this ? Thoughts ?
BTW, I should have the artifactResolver registry and other things necessary
to exercise the processors you are implementing by EOD today (sometime
tonight) ...
On 4/4/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Luciano Resende wrote:
> > I have committed some new contribution services interfaces under
> > revision #
> > 525071 that would better align the contribution service module with the
> > SCDL4J proposals. Note that some of these interfaces, that would be
> > used for
> > artifact resolving, will need to be implemented by the Assembly model
> > classes.
> > Please take a look at these interfaces and let me know what you guys
> > think,
> > I plan to polish them little bit more tomorrow, and then start
> > integrating
> > it with the other modules and the embedded runtime.
> >
> > Thoughts ?
> >
>
> Thanks. I'll try to implement the ArtifactProcessors and ModelResolvers
> for SCA XML assembly files in the modules/assembly module.
>
> I am assuming that the ArtifactProcessor.read() method will contain the
> logic currently in the loaders, then I'll move the logic from
> CompositeUtil to the ArtifactProcessor.resolve() and
> ArtifactProcessor.normalize() methods. I added a little earlier today
> that normalize method to your ArtifactProcessor interface, to cover the
> 3rd of the 3 phases I was describing in [1].
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16229.html
>
> Here's an outline of how I'm planning to implement the ArtifactProcessor
> interface:
> - read will read the model in memory, from a StAX XMLStreamReader
> - resolve will resolve pointers to other models, calling back to the
> Contribution to find the referenced artifacts
> - normalize will apply policies at the various levels, propagage and
> merge component/service/reference configuration declarations from the
> bottom (componentType/constrainingType) to the top (composite/component)
> of the hierarchy. I'll probably just do the strict minimum here for now
> just to get going.
>
> Does that makes sense?
>
> Now some questions:
> - The assembly module deals with 3 types of files, .componentType,
> .constrainingType, .composite. Does that mean I have to implement 3
> ArtifactProcessors?
> - If the answer is yes, how do I associate a particular
> ArtifactProcessor with a file type?
>
> --
> 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
Re: Contribution services and SCDL4J
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Luciano Resende wrote:
> I have committed some new contribution services interfaces under
> revision #
> 525071 that would better align the contribution service module with the
> SCDL4J proposals. Note that some of these interfaces, that would be
> used for
> artifact resolving, will need to be implemented by the Assembly model
> classes.
> Please take a look at these interfaces and let me know what you guys
> think,
> I plan to polish them little bit more tomorrow, and then start
> integrating
> it with the other modules and the embedded runtime.
>
> Thoughts ?
>
Thanks. I'll try to implement the ArtifactProcessors and ModelResolvers
for SCA XML assembly files in the modules/assembly module.
I am assuming that the ArtifactProcessor.read() method will contain the
logic currently in the loaders, then I'll move the logic from
CompositeUtil to the ArtifactProcessor.resolve() and
ArtifactProcessor.normalize() methods. I added a little earlier today
that normalize method to your ArtifactProcessor interface, to cover the
3rd of the 3 phases I was describing in [1].
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16229.html
Here's an outline of how I'm planning to implement the ArtifactProcessor
interface:
- read will read the model in memory, from a StAX XMLStreamReader
- resolve will resolve pointers to other models, calling back to the
Contribution to find the referenced artifacts
- normalize will apply policies at the various levels, propagage and
merge component/service/reference configuration declarations from the
bottom (componentType/constrainingType) to the top (composite/component)
of the hierarchy. I'll probably just do the strict minimum here for now
just to get going.
Does that makes sense?
Now some questions:
- The assembly module deals with 3 types of files, .componentType,
.constrainingType, .composite. Does that mean I have to implement 3
ArtifactProcessors?
- If the answer is yes, how do I associate a particular
ArtifactProcessor with a file type?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org