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]