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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Luciano Resende http://people.apache.org/~lresende
