>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/[email protected]/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]
