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]
