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 Wed, 04 Apr 2007 20:13:19 GMT
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 <jsdelfino@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

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