You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Venkata Krishnan <fo...@gmail.com> on 2007/08/07 20:43:15 UTC
Policy Attachments Resolution in the Assembly Model
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy Attachments Resolution in the Assembly Model
Posted by Luciano Resende <lu...@gmail.com>.
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 <fo...@gmail.com> wrote:
> Yes Luciano, that's what I am suggesting.
>
> - Venkat
>
> On 8/8/07, Luciano Resende <lu...@gmail.com> 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 <fo...@gmail.com> 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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Luciano Resende
> > Apache Tuscany Committer
> > http://people.apache.org/~lresende
> > http://lresende.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy Attachments Resolution in the Assembly Model
Posted by Venkata Krishnan <fo...@gmail.com>.
Yes Luciano, that's what I am suggesting.
- Venkat
On 8/8/07, Luciano Resende <lu...@gmail.com> 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 <fo...@gmail.com> 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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy Attachments Resolution in the Assembly Model
Posted by Luciano Resende <lu...@gmail.com>.
>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 <fo...@gmail.com> 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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy Attachments Resolution in the Assembly Model
Posted by Venkata Krishnan <fo...@gmail.com>.
:) thanks. That makes sense to me.
- Venkat
On 8/9/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Venkata Krishnan wrote:
> > Not sure I understand this. I guess its to do with the
> > ExtensibleURLArtifactProcessor that strips off the extension and
> > searches for processors only by those extensions. So even if the
> > URLArtifactProcessor.getArtifactType() returned 'definitions.xml' we'd
> > still have a problem. I guess we have to designate some files as
> > configuration files that have specific designated processors. When
> > the contribution service picks up these files it must invoke the
> > corresponding artifact processors and in all other cases - for
> > application artifacts it could go by what its going currently. Makes
> > sense ?
> >
> > - Venkat
> >
> >
> > On 8/8/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> >> [snip]
> >> Venkata Krishnan 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
> >>>
> >>>
> >>>
> >>>
> >> Here's a simple change to make this cleaner:
> >>
> >> 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
> >>
> >> Thoughts?
> >>
> >> --
> >> Jean-Sebastien
> >>
> >>
>
> I didn't say that this didn't require any changes in any classes. I'm
> just proposing a change to how URLArtifactProcessors indicate what they
> support:
> *.foo for all files with extension .foo
> foo.bar for file foo.bar
>
> Then, yeah sure, some classes will have to change to accomodate this new
> way of declaring URLArtifactProcessors.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy Attachments Resolution in the Assembly Model
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> Not sure I understand this. I guess its to do with the
> ExtensibleURLArtifactProcessor that strips off the extension and
> searches for processors only by those extensions. So even if the
> URLArtifactProcessor.getArtifactType() returned 'definitions.xml' we'd
> still have a problem. I guess we have to designate some files as
> configuration files that have specific designated processors. When
> the contribution service picks up these files it must invoke the
> corresponding artifact processors and in all other cases - for
> application artifacts it could go by what its going currently. Makes
> sense ?
>
> - Venkat
>
>
> On 8/8/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
>> [snip]
>> Venkata Krishnan 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
>>>
>>>
>>>
>>>
>> Here's a simple change to make this cleaner:
>>
>> 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
>>
>> Thoughts?
>>
>> --
>> Jean-Sebastien
>>
>>
I didn't say that this didn't require any changes in any classes. I'm
just proposing a change to how URLArtifactProcessors indicate what they
support:
*.foo for all files with extension .foo
foo.bar for file foo.bar
Then, yeah sure, some classes will have to change to accomodate this new
way of declaring URLArtifactProcessors.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy Attachments Resolution in the Assembly Model
Posted by Venkata Krishnan <fo...@gmail.com>.
Not sure I understand this. I guess its to do with the
ExtensibleURLArtifactProcessor that strips off the extension and
searches for processors only by those extensions. So even if the
URLArtifactProcessor.getArtifactType() returned 'definitions.xml' we'd
still have a problem. I guess we have to designate some files as
configuration files that have specific designated processors. When
the contribution service picks up these files it must invoke the
corresponding artifact processors and in all other cases - for
application artifacts it could go by what its going currently. Makes
sense ?
- Venkat
On 8/8/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> [snip]
> Venkata Krishnan 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
> >
> >
> >
> Here's a simple change to make this cleaner:
>
> 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
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy Attachments Resolution in the Assembly Model
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Venkata Krishnan 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
>
>
>
Here's a simple change to make this cleaner:
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
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy Attachments Resolution in the Assembly Model
Posted by Venkata Krishnan <fo...@gmail.com>.
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Policy Attachments Resolution in the Assembly Model
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org