Cool, if you can wait a day, i can take a look at that... Sebastien suggestion seems ok:
>Instead of URLArtifactProcessor.getType() returning >.composite for *.composite files >definition.xml for definition.xml files >URLArtifactProcessor.getType() could return >*.composite for *.composites files >definitions.xml for definition.xml But I guess we also need to change the logic on the algorithm that checks for the right processor to be used, as it's now just checking the file extension. On 8/8/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > Yes Luciano, that's what I am suggesting. > > - Venkat > > On 8/8/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > >Could we extend the logic in ExtensibleURLArtifactProcessor.read to > > >first look at extensions and if not found try with the name of the > > >file ? So the principle is - search for processors either by > > >extensions or by the file name for specific kind of documents. I sort > > >of feel a bit clumsy about this approach - whats an alternative that > > >could be cleaner ? > > > > Not sure i got this right, but are you asking for the ability to > > register artifactProcessors by fileName as well as extension ? > > > > > > On 8/8/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > > Hi Sebastien, thanks. I've figured out all of this already :) Just > > > the one hanging thing - the definitions.xml is an artifact that might > > > have to be picked up by the contribution service. While processors > > > for all other documents could be found by their unique extensions such > > > as .composte or .constrainingType its a bit of a trouble with > > > definitions.xml, the extension .xml being generic. > > > > > > Could we extend the logic in ExtensibleURLArtifactProcessor.read to > > > first look at extensions and if not found try with the name of the > > > file ? So the principle is - search for processors either by > > > extensions or by the file name for specific kind of documents. I sort > > > of feel a bit clumsy about this approach - whats an alternative that > > > could be cleaner ? > > > > > > Thanks > > > > > > - Venkat > > > > > > On 8/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > Venkata Krishnan wrote: > > > > > Hi, > > > > > > > > > > Now that I have the basic policy model in place I am trying to link > > > > > up this with the assembly model now. > > > > > > > > > > The policy intents and policy sets applicable for a domain are defined > > > > > in the definitions.xml. There is a SCADefinitions processor that > > > > > deals with reading and resolving the intents and policysets in the > > > > > definitions.xml. The SCADefinitions processor has a model resolver > > > > > into which the the various policy intents and policy sets that are > > > > > read get added. All of this is a part of the policy-xml module. > > > > > > > > > > Now looking into the aspect of dealing with the 'attachments' of > > > > > policy intents and policy sets into various SCA constructs, I see > > > > > there is a need to resolve the intents and policysets with those that > > > > > have been read from the definitions.xml. This means an artifact > > > > > processor such as the CompositeProcessor needs to be passed a resolver > > > > > that has the various policy intents and policy sets in it. > > > > > > > > > > Now the question is, do we assume that we use the same resolver that > > > > > is used to add up the read sca contructs is used to also add the > > > > > policy intents and policysets ? > > > > > > > > > > or... > > > > > > > > > > Going by the discussion in > > > > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19069.html, I > > > > > am given to understand that its best to keep all of the things related > > > > > to policies - the processor, the resolver etc. separate from those > > > > > that we have for the assembly model. If this is the case then the > > > > > CompositeProcessor, the ConstrainingType Processor etc. all have to be > > > > > set with the instance of a SCADefinitionsResolver that will be used to > > > > > resolve to policy related things. > > > > > > > > > > Could somebody please help me with some perspectives on which one of > > > > > the above two is better to follow? > > > > > > > > > > Thanks > > > > > > > > > > - Venkat > > > > > > > > > > > > > > > > > > I think we can follow the same pattern as implementations, bindings, > > > > etc: > > > > - In CompositeProcessor.resolve(model, resolver), call > > > > resolver.resolveModel(policyToResolve) to resolve an unresolved policy > > > > model object, then attach the resolved policy to the composite. > > > > - In your policy-xml module, provide a PolicyModelResolver and register > > > > it in the ModelResolverExtensionPoint. PolicyModelResolver will handle > > > > the resolution of Policy model objects (by qname I guess). Look for > > > > CompositeModelResolver for an example of a ModelResolver. > > > > > > > > -- > > > > Jean-Sebastien > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Luciano Resende > > Apache Tuscany Committer > > http://people.apache.org/~lresende > > http://lresende.blogspot.com/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
