You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Greg Dritschler (JIRA)" <tu...@ws.apache.org> on 2008/04/17 05:33:22 UTC
[jira] Created: (TUSCANY-2239) Support for mutually-exclusive
intents
Support for mutually-exclusive intents
--------------------------------------
Key: TUSCANY-2239
URL: https://issues.apache.org/jira/browse/TUSCANY-2239
Project: Tuscany
Issue Type: New Feature
Components: Java SCA Core Runtime
Reporter: Greg Dritschler
The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites.
I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the <intent/> element in definitions.xml. For example:
<intent name="propagatesTransaction" constrains="implementation" excludes="suspendsTransaction"/>
@excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below.
<intent name="suspendsTransaction" constrains="implementation" excludes="propagatesTransaction"/>
The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out.
<intent name="noManagedTransaction" constrains="implementation"
excludes="managedTransaction managedTransaction.global managedTransaction.local"/>
A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a "default" inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite:
<component name="C1" requires="propagatesTransaction">
<reference name="r1"/>
<reference name="r2"/>
<reference name="r3" requires="suspendsTransaction"/>
</component>
In this case the first two references inherit the default intent "propagatesTransaction" from the component element. However the third reference does not inherit it because it specifies an exclusive intent "suspendsTransaction" which overrides the component-level default.
The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example:
<component name="D1">
<implementation.composite name="CZ1"/>
<reference name="r1" requires="suspendsTransaction"/>
</component>
Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent "propagatesTransaction". This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Created: (TUSCANY-2239) Support for mutually-exclusive intents
Posted by Greg Dritschler <gr...@gmail.com>.
The patch validates the final list of intents collected into the binding or
implementation does not contain exclusive intents. I suppose you could do
validation calls at other levels to better pinpoint the source of the error.
Greg
On Sat, Apr 19, 2008 at 7:37 AM, Venkata Krishnan <fo...@gmail.com>
wrote:
> Hi,
>
> With specific reference to the inheritance of intents and policysets
> across
> the SCDL-XML hierarchy i.e. the one by which child elements inherit that
> which is specified in the parent element I have a question as follows :-
>
> Do we need to bother about the validity of what a child element actually
> inherits UNLESS its a binding or implementation element ? For example how
> very important is it to worry about validating for Mutually exclusive
> intents at a 'reference' element.
>
> I am wondering if I could just about aggregate all intents and policysets
> upto the immediate parent of a binding or implementation element. Then at
> this point, when the binding or implementation is about to inherit, I
> would
> apply validations related to checks for mutually exclusive intents.
>
> I am thinking on these lines because it seems to me that the binding and
> implementation elements are where intents and policyset actually matter.
> If
> specified in any other levle its only for convenience so as to cover a
> whole
> bunch of child elements.
>
> Am I trying to overly simply things here missing some key point ?
>
> Thanks
>
> - Venkat
>
>
> On Fri, Apr 18, 2008 at 7:08 PM, Greg Dritschler <
> greg.dritschler@gmail.com>
> wrote:
>
> > Thanks Mike. As you know I relied on these 2 JIRAs to compose a
> solution.
> > With respect to POLICY-39, I didn't implement some of the features like
> > wildcarding of qualifiers or not requiring reciprocal exclusions in the
> > interest of getting the basics done and into the code base. These
> > features
> > could be added later if someone has an interest in them.
> >
> > On Thu, Apr 17, 2008 at 9:54 AM, Mike Edwards <
> > mike.edwards.inglenook@gmail.com> wrote:
> >
> > > Greg Dritschler (JIRA) wrote:
> > >
> > > > Support for mutually-exclusive intents
> > > > --------------------------------------
> > > >
> > > > Key: TUSCANY-2239
> > > > URL:
> > https://issues.apache.org/jira/browse/TUSCANY-2239
> > > > Project: Tuscany
> > > > Issue Type: New Feature
> > > > Components: Java SCA Core Runtime
> > > > Reporter: Greg Dritschler
> > > >
> > > >
> > > > The SCA Policy specification does not provide a means to define
> > intents
> > > > which are mutually exclusive. This is a noticeable omission when
> > > > considering the intents in the SCA Transaction specification which
> are
> > > > mutually exclusive by nature (managedTransaction vs.
> > noManagedTransaction,
> > > > propagatesTransaction vs. suspendsTransaction). There is a need to
> > be able
> > > > to define intents which are mutually exclusive and for the exclusion
> > to be
> > > > checked by the SCA runtime to avoid the error of specifying
> exclusive
> > > > intents on a single artifact. In addition, there should be rules
> > defined
> > > > for the handling of mutually exclusive intents which are attached at
> > > > different levels of a composite or a hierarchy of composites.
> > > >
> > > > I have attached a patch to provide the capability to define mutually
> > > > exclusive intents. This is achieved using a new @excludes attribute
> > on the
> > > > <intent/> element in definitions.xml. For example:
> > > >
> > > > <intent name="propagatesTransaction" constrains="implementation"
> > > > excludes="suspendsTransaction"/>
> > > >
> > > > @excludes is a list of intents which are mutually-exclusive with the
> > > > named intent. In order to be effective, a reciprocal definition
> needs
> > to be
> > > > made as shown below.
> > > >
> > > > <intent name="suspendsTransaction" constrains="implementation"
> > > > excludes="propagatesTransaction"/>
> > > >
> > > > The patch makes no assumptions about the relationship of qualified
> > > > intents to the base intent. Therefore exclusive relationships
> between
> > > > qualified intents need to be spelled out.
> > > >
> > > > <intent name="noManagedTransaction" constrains="implementation"
> > > > excludes="managedTransaction managedTransaction.global
> > > > managedTransaction.local"/>
> > > >
> > > > A key part of the patch is that there now are two types of intent
> > > > inheritance with respect to exclusive intents. There is a "default"
> > > > inheritance between certain hierarchical elements within a
> composite.
> > For
> > > > example consider this snippet from a composite:
> > > >
> > > > <component name="C1" requires="propagatesTransaction">
> > > > <reference name="r1"/>
> > > > <reference name="r2"/>
> > > > <reference name="r3" requires="suspendsTransaction"/>
> > > > </component>
> > > >
> > > > In this case the first two references inherit the default intent
> > > > "propagatesTransaction" from the component element. However the
> third
> > > > reference does not inherit it because it specifies an exclusive
> intent
> > > > "suspendsTransaction" which overrides the component-level default.
> > > >
> > > > The second type of inheritance is used when inheriting intents from
> an
> > > > implementation (e.g. introspected Java code, or an implementation
> > > > composite). In this case the intents of the implementation cannot
> be
> > > > overridden. Consider this example:
> > > >
> > > > <component name="D1">
> > > > <implementation.composite name="CZ1"/>
> > > > <reference name="r1" requires="suspendsTransaction"/>
> > > > </component>
> > > >
> > > > Let's assume CZ1 contains the component C1 shown earlier and that it
> > > > promotes the component reference C1/r1 as r1. C1/r1 has the intent
> > > > "propagatesTransaction". This intent is considered a requirement of
> > the
> > > > implementation and it cannot be overridden by the using composite.
> > > > Therefore D1 is in error.
> > > >
> > > > Folks,
> > >
> > > I would like to make everyone aware that the OASIS Policy TC have been
> > > working on the topic of mutually exclusive intents and there is both a
> > > formal Issue and an agreed resolution to that issue.
> > >
> > > The related topic of inheritance of intents has also received the same
> > > treatment!
> > >
> > > The issues concerned are:
> > >
> > > a) Issue 39 Need Support for Mutually exclusive intents
> > > http://www.osoa.org/jira/browse/POLICY-39
> > >
> > > The agreed resolution is on the page linked above.
> > > It is very close to the solution expressed above, but it does deal
> with
> > > qualified intents in detail.
> > >
> > > b) Issue 38 Improve description of the overides available to the two
> > > different hierarchies in SCA
> > > http://www.osoa.org/jira/browse/POLICY-38
> > >
> > > This is a comprehensive description of how intents are inherited by a
> > > given element in SCA - both from the surrounding SCDL and also from
> any
> > > implementations that are being used.
> > >
> > > The full resolution text is attached to the following email:
> > > http://lists.oasis-open.org/archives/sca-policy/200804/msg00018.html
> > >
> > > ...this is actually a complete updated version of the Policy
> > specification
> > > with change markings.
> > >
> > >
> > > Hope this clarifies things,
> > >
> > > Yours, Mike.
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
Re: [jira] Created: (TUSCANY-2239) Support for mutually-exclusive intents
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
With specific reference to the inheritance of intents and policysets across
the SCDL-XML hierarchy i.e. the one by which child elements inherit that
which is specified in the parent element I have a question as follows :-
Do we need to bother about the validity of what a child element actually
inherits UNLESS its a binding or implementation element ? For example how
very important is it to worry about validating for Mutually exclusive
intents at a 'reference' element.
I am wondering if I could just about aggregate all intents and policysets
upto the immediate parent of a binding or implementation element. Then at
this point, when the binding or implementation is about to inherit, I would
apply validations related to checks for mutually exclusive intents.
I am thinking on these lines because it seems to me that the binding and
implementation elements are where intents and policyset actually matter. If
specified in any other levle its only for convenience so as to cover a whole
bunch of child elements.
Am I trying to overly simply things here missing some key point ?
Thanks
- Venkat
On Fri, Apr 18, 2008 at 7:08 PM, Greg Dritschler <gr...@gmail.com>
wrote:
> Thanks Mike. As you know I relied on these 2 JIRAs to compose a solution.
> With respect to POLICY-39, I didn't implement some of the features like
> wildcarding of qualifiers or not requiring reciprocal exclusions in the
> interest of getting the basics done and into the code base. These
> features
> could be added later if someone has an interest in them.
>
> On Thu, Apr 17, 2008 at 9:54 AM, Mike Edwards <
> mike.edwards.inglenook@gmail.com> wrote:
>
> > Greg Dritschler (JIRA) wrote:
> >
> > > Support for mutually-exclusive intents
> > > --------------------------------------
> > >
> > > Key: TUSCANY-2239
> > > URL:
> https://issues.apache.org/jira/browse/TUSCANY-2239
> > > Project: Tuscany
> > > Issue Type: New Feature
> > > Components: Java SCA Core Runtime
> > > Reporter: Greg Dritschler
> > >
> > >
> > > The SCA Policy specification does not provide a means to define
> intents
> > > which are mutually exclusive. This is a noticeable omission when
> > > considering the intents in the SCA Transaction specification which are
> > > mutually exclusive by nature (managedTransaction vs.
> noManagedTransaction,
> > > propagatesTransaction vs. suspendsTransaction). There is a need to
> be able
> > > to define intents which are mutually exclusive and for the exclusion
> to be
> > > checked by the SCA runtime to avoid the error of specifying exclusive
> > > intents on a single artifact. In addition, there should be rules
> defined
> > > for the handling of mutually exclusive intents which are attached at
> > > different levels of a composite or a hierarchy of composites.
> > >
> > > I have attached a patch to provide the capability to define mutually
> > > exclusive intents. This is achieved using a new @excludes attribute
> on the
> > > <intent/> element in definitions.xml. For example:
> > >
> > > <intent name="propagatesTransaction" constrains="implementation"
> > > excludes="suspendsTransaction"/>
> > >
> > > @excludes is a list of intents which are mutually-exclusive with the
> > > named intent. In order to be effective, a reciprocal definition needs
> to be
> > > made as shown below.
> > >
> > > <intent name="suspendsTransaction" constrains="implementation"
> > > excludes="propagatesTransaction"/>
> > >
> > > The patch makes no assumptions about the relationship of qualified
> > > intents to the base intent. Therefore exclusive relationships between
> > > qualified intents need to be spelled out.
> > >
> > > <intent name="noManagedTransaction" constrains="implementation"
> > > excludes="managedTransaction managedTransaction.global
> > > managedTransaction.local"/>
> > >
> > > A key part of the patch is that there now are two types of intent
> > > inheritance with respect to exclusive intents. There is a "default"
> > > inheritance between certain hierarchical elements within a composite.
> For
> > > example consider this snippet from a composite:
> > >
> > > <component name="C1" requires="propagatesTransaction">
> > > <reference name="r1"/>
> > > <reference name="r2"/>
> > > <reference name="r3" requires="suspendsTransaction"/>
> > > </component>
> > >
> > > In this case the first two references inherit the default intent
> > > "propagatesTransaction" from the component element. However the third
> > > reference does not inherit it because it specifies an exclusive intent
> > > "suspendsTransaction" which overrides the component-level default.
> > >
> > > The second type of inheritance is used when inheriting intents from an
> > > implementation (e.g. introspected Java code, or an implementation
> > > composite). In this case the intents of the implementation cannot be
> > > overridden. Consider this example:
> > >
> > > <component name="D1">
> > > <implementation.composite name="CZ1"/>
> > > <reference name="r1" requires="suspendsTransaction"/>
> > > </component>
> > >
> > > Let's assume CZ1 contains the component C1 shown earlier and that it
> > > promotes the component reference C1/r1 as r1. C1/r1 has the intent
> > > "propagatesTransaction". This intent is considered a requirement of
> the
> > > implementation and it cannot be overridden by the using composite.
> > > Therefore D1 is in error.
> > >
> > > Folks,
> >
> > I would like to make everyone aware that the OASIS Policy TC have been
> > working on the topic of mutually exclusive intents and there is both a
> > formal Issue and an agreed resolution to that issue.
> >
> > The related topic of inheritance of intents has also received the same
> > treatment!
> >
> > The issues concerned are:
> >
> > a) Issue 39 Need Support for Mutually exclusive intents
> > http://www.osoa.org/jira/browse/POLICY-39
> >
> > The agreed resolution is on the page linked above.
> > It is very close to the solution expressed above, but it does deal with
> > qualified intents in detail.
> >
> > b) Issue 38 Improve description of the overides available to the two
> > different hierarchies in SCA
> > http://www.osoa.org/jira/browse/POLICY-38
> >
> > This is a comprehensive description of how intents are inherited by a
> > given element in SCA - both from the surrounding SCDL and also from any
> > implementations that are being used.
> >
> > The full resolution text is attached to the following email:
> > http://lists.oasis-open.org/archives/sca-policy/200804/msg00018.html
> >
> > ...this is actually a complete updated version of the Policy
> specification
> > with change markings.
> >
> >
> > Hope this clarifies things,
> >
> > Yours, Mike.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: [jira] Created: (TUSCANY-2239) Support for mutually-exclusive intents
Posted by Greg Dritschler <gr...@gmail.com>.
Thanks Mike. As you know I relied on these 2 JIRAs to compose a solution.
With respect to POLICY-39, I didn't implement some of the features like
wildcarding of qualifiers or not requiring reciprocal exclusions in the
interest of getting the basics done and into the code base. These features
could be added later if someone has an interest in them.
On Thu, Apr 17, 2008 at 9:54 AM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> Greg Dritschler (JIRA) wrote:
>
> > Support for mutually-exclusive intents
> > --------------------------------------
> >
> > Key: TUSCANY-2239
> > URL: https://issues.apache.org/jira/browse/TUSCANY-2239
> > Project: Tuscany
> > Issue Type: New Feature
> > Components: Java SCA Core Runtime
> > Reporter: Greg Dritschler
> >
> >
> > The SCA Policy specification does not provide a means to define intents
> > which are mutually exclusive. This is a noticeable omission when
> > considering the intents in the SCA Transaction specification which are
> > mutually exclusive by nature (managedTransaction vs. noManagedTransaction,
> > propagatesTransaction vs. suspendsTransaction). There is a need to be able
> > to define intents which are mutually exclusive and for the exclusion to be
> > checked by the SCA runtime to avoid the error of specifying exclusive
> > intents on a single artifact. In addition, there should be rules defined
> > for the handling of mutually exclusive intents which are attached at
> > different levels of a composite or a hierarchy of composites.
> >
> > I have attached a patch to provide the capability to define mutually
> > exclusive intents. This is achieved using a new @excludes attribute on the
> > <intent/> element in definitions.xml. For example:
> >
> > <intent name="propagatesTransaction" constrains="implementation"
> > excludes="suspendsTransaction"/>
> >
> > @excludes is a list of intents which are mutually-exclusive with the
> > named intent. In order to be effective, a reciprocal definition needs to be
> > made as shown below.
> >
> > <intent name="suspendsTransaction" constrains="implementation"
> > excludes="propagatesTransaction"/>
> >
> > The patch makes no assumptions about the relationship of qualified
> > intents to the base intent. Therefore exclusive relationships between
> > qualified intents need to be spelled out.
> >
> > <intent name="noManagedTransaction" constrains="implementation"
> > excludes="managedTransaction managedTransaction.global
> > managedTransaction.local"/>
> >
> > A key part of the patch is that there now are two types of intent
> > inheritance with respect to exclusive intents. There is a "default"
> > inheritance between certain hierarchical elements within a composite. For
> > example consider this snippet from a composite:
> >
> > <component name="C1" requires="propagatesTransaction">
> > <reference name="r1"/>
> > <reference name="r2"/>
> > <reference name="r3" requires="suspendsTransaction"/>
> > </component>
> >
> > In this case the first two references inherit the default intent
> > "propagatesTransaction" from the component element. However the third
> > reference does not inherit it because it specifies an exclusive intent
> > "suspendsTransaction" which overrides the component-level default.
> >
> > The second type of inheritance is used when inheriting intents from an
> > implementation (e.g. introspected Java code, or an implementation
> > composite). In this case the intents of the implementation cannot be
> > overridden. Consider this example:
> >
> > <component name="D1">
> > <implementation.composite name="CZ1"/>
> > <reference name="r1" requires="suspendsTransaction"/>
> > </component>
> >
> > Let's assume CZ1 contains the component C1 shown earlier and that it
> > promotes the component reference C1/r1 as r1. C1/r1 has the intent
> > "propagatesTransaction". This intent is considered a requirement of the
> > implementation and it cannot be overridden by the using composite.
> > Therefore D1 is in error.
> >
> > Folks,
>
> I would like to make everyone aware that the OASIS Policy TC have been
> working on the topic of mutually exclusive intents and there is both a
> formal Issue and an agreed resolution to that issue.
>
> The related topic of inheritance of intents has also received the same
> treatment!
>
> The issues concerned are:
>
> a) Issue 39 Need Support for Mutually exclusive intents
> http://www.osoa.org/jira/browse/POLICY-39
>
> The agreed resolution is on the page linked above.
> It is very close to the solution expressed above, but it does deal with
> qualified intents in detail.
>
> b) Issue 38 Improve description of the overides available to the two
> different hierarchies in SCA
> http://www.osoa.org/jira/browse/POLICY-38
>
> This is a comprehensive description of how intents are inherited by a
> given element in SCA - both from the surrounding SCDL and also from any
> implementations that are being used.
>
> The full resolution text is attached to the following email:
> http://lists.oasis-open.org/archives/sca-policy/200804/msg00018.html
>
> ...this is actually a complete updated version of the Policy specification
> with change markings.
>
>
> Hope this clarifies things,
>
> Yours, Mike.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [jira] Created: (TUSCANY-2239) Support for mutually-exclusive
intents
Posted by Mike Edwards <mi...@gmail.com>.
Greg Dritschler (JIRA) wrote:
> Support for mutually-exclusive intents
> --------------------------------------
>
> Key: TUSCANY-2239
> URL: https://issues.apache.org/jira/browse/TUSCANY-2239
> Project: Tuscany
> Issue Type: New Feature
> Components: Java SCA Core Runtime
> Reporter: Greg Dritschler
>
>
> The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites.
>
> I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the <intent/> element in definitions.xml. For example:
>
> <intent name="propagatesTransaction" constrains="implementation" excludes="suspendsTransaction"/>
>
> @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below.
>
> <intent name="suspendsTransaction" constrains="implementation" excludes="propagatesTransaction"/>
>
> The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out.
>
> <intent name="noManagedTransaction" constrains="implementation"
> excludes="managedTransaction managedTransaction.global managedTransaction.local"/>
>
> A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a "default" inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite:
>
> <component name="C1" requires="propagatesTransaction">
> <reference name="r1"/>
> <reference name="r2"/>
> <reference name="r3" requires="suspendsTransaction"/>
> </component>
>
> In this case the first two references inherit the default intent "propagatesTransaction" from the component element. However the third reference does not inherit it because it specifies an exclusive intent "suspendsTransaction" which overrides the component-level default.
>
> The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example:
>
> <component name="D1">
> <implementation.composite name="CZ1"/>
> <reference name="r1" requires="suspendsTransaction"/>
> </component>
>
> Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent "propagatesTransaction". This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error.
>
Folks,
I would like to make everyone aware that the OASIS Policy TC have been
working on the topic of mutually exclusive intents and there is both a
formal Issue and an agreed resolution to that issue.
The related topic of inheritance of intents has also received the same
treatment!
The issues concerned are:
a) Issue 39 Need Support for Mutually exclusive intents
http://www.osoa.org/jira/browse/POLICY-39
The agreed resolution is on the page linked above.
It is very close to the solution expressed above, but it does deal with
qualified intents in detail.
b) Issue 38 Improve description of the overides available to the two
different hierarchies in SCA
http://www.osoa.org/jira/browse/POLICY-38
This is a comprehensive description of how intents are inherited by a
given element in SCA - both from the surrounding SCDL and also from any
implementations that are being used.
The full resolution text is attached to the following email:
http://lists.oasis-open.org/archives/sca-policy/200804/msg00018.html
...this is actually a complete updated version of the Policy
specification with change markings.
Hope this clarifies things,
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-2239) Support for mutually-exclusive
intents
Posted by "Greg Dritschler (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Greg Dritschler updated TUSCANY-2239:
-------------------------------------
Attachment: tuscany-2239.patch
> Support for mutually-exclusive intents
> --------------------------------------
>
> Key: TUSCANY-2239
> URL: https://issues.apache.org/jira/browse/TUSCANY-2239
> Project: Tuscany
> Issue Type: New Feature
> Components: Java SCA Core Runtime
> Reporter: Greg Dritschler
> Attachments: tuscany-2239.patch
>
>
> The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites.
> I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the <intent/> element in definitions.xml. For example:
> <intent name="propagatesTransaction" constrains="implementation" excludes="suspendsTransaction"/>
> @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below.
> <intent name="suspendsTransaction" constrains="implementation" excludes="propagatesTransaction"/>
> The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out.
> <intent name="noManagedTransaction" constrains="implementation"
> excludes="managedTransaction managedTransaction.global managedTransaction.local"/>
> A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a "default" inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite:
> <component name="C1" requires="propagatesTransaction">
> <reference name="r1"/>
> <reference name="r2"/>
> <reference name="r3" requires="suspendsTransaction"/>
> </component>
> In this case the first two references inherit the default intent "propagatesTransaction" from the component element. However the third reference does not inherit it because it specifies an exclusive intent "suspendsTransaction" which overrides the component-level default.
> The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example:
> <component name="D1">
> <implementation.composite name="CZ1"/>
> <reference name="r1" requires="suspendsTransaction"/>
> </component>
> Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent "propagatesTransaction". This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Resolved: (TUSCANY-2239) Support for mutually-exclusive
intents
Posted by "Venkatakrishnan (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Venkatakrishnan resolved TUSCANY-2239.
--------------------------------------
Resolution: Fixed
Greg, thanks for the re-patch ;-). All committed now - from r650027 to r650031.
> Support for mutually-exclusive intents
> --------------------------------------
>
> Key: TUSCANY-2239
> URL: https://issues.apache.org/jira/browse/TUSCANY-2239
> Project: Tuscany
> Issue Type: New Feature
> Components: Java SCA Core Runtime
> Reporter: Greg Dritschler
> Assignee: Venkatakrishnan
> Attachments: tuscany-2239-CompositeWireBuilder.patch, tuscany-2239.patch
>
>
> The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites.
> I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the <intent/> element in definitions.xml. For example:
> <intent name="propagatesTransaction" constrains="implementation" excludes="suspendsTransaction"/>
> @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below.
> <intent name="suspendsTransaction" constrains="implementation" excludes="propagatesTransaction"/>
> The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out.
> <intent name="noManagedTransaction" constrains="implementation"
> excludes="managedTransaction managedTransaction.global managedTransaction.local"/>
> A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a "default" inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite:
> <component name="C1" requires="propagatesTransaction">
> <reference name="r1"/>
> <reference name="r2"/>
> <reference name="r3" requires="suspendsTransaction"/>
> </component>
> In this case the first two references inherit the default intent "propagatesTransaction" from the component element. However the third reference does not inherit it because it specifies an exclusive intent "suspendsTransaction" which overrides the component-level default.
> The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example:
> <component name="D1">
> <implementation.composite name="CZ1"/>
> <reference name="r1" requires="suspendsTransaction"/>
> </component>
> Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent "propagatesTransaction". This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-2239) Support for mutually-exclusive
intents
Posted by "Greg Dritschler (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590785#action_12590785 ]
Greg Dritschler commented on TUSCANY-2239:
------------------------------------------
I have attached a new patch for CompositeWireBuilderImpl.
> Support for mutually-exclusive intents
> --------------------------------------
>
> Key: TUSCANY-2239
> URL: https://issues.apache.org/jira/browse/TUSCANY-2239
> Project: Tuscany
> Issue Type: New Feature
> Components: Java SCA Core Runtime
> Reporter: Greg Dritschler
> Assignee: Venkatakrishnan
> Attachments: tuscany-2239-CompositeWireBuilder.patch, tuscany-2239.patch
>
>
> The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites.
> I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the <intent/> element in definitions.xml. For example:
> <intent name="propagatesTransaction" constrains="implementation" excludes="suspendsTransaction"/>
> @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below.
> <intent name="suspendsTransaction" constrains="implementation" excludes="propagatesTransaction"/>
> The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out.
> <intent name="noManagedTransaction" constrains="implementation"
> excludes="managedTransaction managedTransaction.global managedTransaction.local"/>
> A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a "default" inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite:
> <component name="C1" requires="propagatesTransaction">
> <reference name="r1"/>
> <reference name="r2"/>
> <reference name="r3" requires="suspendsTransaction"/>
> </component>
> In this case the first two references inherit the default intent "propagatesTransaction" from the component element. However the third reference does not inherit it because it specifies an exclusive intent "suspendsTransaction" which overrides the component-level default.
> The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example:
> <component name="D1">
> <implementation.composite name="CZ1"/>
> <reference name="r1" requires="suspendsTransaction"/>
> </component>
> Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent "propagatesTransaction". This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-2239) Support for mutually-exclusive
intents
Posted by "Greg Dritschler (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Greg Dritschler updated TUSCANY-2239:
-------------------------------------
Attachment: (was: tuscany-2239-CompositeWireBuilder.patch)
> Support for mutually-exclusive intents
> --------------------------------------
>
> Key: TUSCANY-2239
> URL: https://issues.apache.org/jira/browse/TUSCANY-2239
> Project: Tuscany
> Issue Type: New Feature
> Components: Java SCA Core Runtime
> Reporter: Greg Dritschler
> Assignee: Venkatakrishnan
> Attachments: tuscany-2239-CompositeWireBuilder.patch, tuscany-2239.patch
>
>
> The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites.
> I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the <intent/> element in definitions.xml. For example:
> <intent name="propagatesTransaction" constrains="implementation" excludes="suspendsTransaction"/>
> @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below.
> <intent name="suspendsTransaction" constrains="implementation" excludes="propagatesTransaction"/>
> The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out.
> <intent name="noManagedTransaction" constrains="implementation"
> excludes="managedTransaction managedTransaction.global managedTransaction.local"/>
> A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a "default" inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite:
> <component name="C1" requires="propagatesTransaction">
> <reference name="r1"/>
> <reference name="r2"/>
> <reference name="r3" requires="suspendsTransaction"/>
> </component>
> In this case the first two references inherit the default intent "propagatesTransaction" from the component element. However the third reference does not inherit it because it specifies an exclusive intent "suspendsTransaction" which overrides the component-level default.
> The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example:
> <component name="D1">
> <implementation.composite name="CZ1"/>
> <reference name="r1" requires="suspendsTransaction"/>
> </component>
> Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent "propagatesTransaction". This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-2239) Support for mutually-exclusive
intents
Posted by "Greg Dritschler (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Greg Dritschler updated TUSCANY-2239:
-------------------------------------
Attachment: tuscany-2239-CompositeWireBuilder.patch
> Support for mutually-exclusive intents
> --------------------------------------
>
> Key: TUSCANY-2239
> URL: https://issues.apache.org/jira/browse/TUSCANY-2239
> Project: Tuscany
> Issue Type: New Feature
> Components: Java SCA Core Runtime
> Reporter: Greg Dritschler
> Assignee: Venkatakrishnan
> Attachments: tuscany-2239-CompositeWireBuilder.patch, tuscany-2239.patch
>
>
> The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites.
> I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the <intent/> element in definitions.xml. For example:
> <intent name="propagatesTransaction" constrains="implementation" excludes="suspendsTransaction"/>
> @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below.
> <intent name="suspendsTransaction" constrains="implementation" excludes="propagatesTransaction"/>
> The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out.
> <intent name="noManagedTransaction" constrains="implementation"
> excludes="managedTransaction managedTransaction.global managedTransaction.local"/>
> A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a "default" inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite:
> <component name="C1" requires="propagatesTransaction">
> <reference name="r1"/>
> <reference name="r2"/>
> <reference name="r3" requires="suspendsTransaction"/>
> </component>
> In this case the first two references inherit the default intent "propagatesTransaction" from the component element. However the third reference does not inherit it because it specifies an exclusive intent "suspendsTransaction" which overrides the component-level default.
> The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example:
> <component name="D1">
> <implementation.composite name="CZ1"/>
> <reference name="r1" requires="suspendsTransaction"/>
> </component>
> Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent "propagatesTransaction". This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Assigned: (TUSCANY-2239) Support for mutually-exclusive
intents
Posted by "Venkatakrishnan (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Venkatakrishnan reassigned TUSCANY-2239:
----------------------------------------
Assignee: Venkatakrishnan
> Support for mutually-exclusive intents
> --------------------------------------
>
> Key: TUSCANY-2239
> URL: https://issues.apache.org/jira/browse/TUSCANY-2239
> Project: Tuscany
> Issue Type: New Feature
> Components: Java SCA Core Runtime
> Reporter: Greg Dritschler
> Assignee: Venkatakrishnan
> Attachments: tuscany-2239.patch
>
>
> The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites.
> I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the <intent/> element in definitions.xml. For example:
> <intent name="propagatesTransaction" constrains="implementation" excludes="suspendsTransaction"/>
> @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below.
> <intent name="suspendsTransaction" constrains="implementation" excludes="propagatesTransaction"/>
> The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out.
> <intent name="noManagedTransaction" constrains="implementation"
> excludes="managedTransaction managedTransaction.global managedTransaction.local"/>
> A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a "default" inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite:
> <component name="C1" requires="propagatesTransaction">
> <reference name="r1"/>
> <reference name="r2"/>
> <reference name="r3" requires="suspendsTransaction"/>
> </component>
> In this case the first two references inherit the default intent "propagatesTransaction" from the component element. However the third reference does not inherit it because it specifies an exclusive intent "suspendsTransaction" which overrides the component-level default.
> The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example:
> <component name="D1">
> <implementation.composite name="CZ1"/>
> <reference name="r1" requires="suspendsTransaction"/>
> </component>
> Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent "propagatesTransaction". This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-2239) Support for mutually-exclusive
intents
Posted by "Venkatakrishnan (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590695#action_12590695 ]
Venkatakrishnan commented on TUSCANY-2239:
------------------------------------------
Hi Greg, thanks many for the patch. However, I have a bit of trouble with applying the changes in the CompositeWireBuilderImpl.java. Could you please regenerate a patch for this file alone and attach here ?
Thanks
- Venkat
> Support for mutually-exclusive intents
> --------------------------------------
>
> Key: TUSCANY-2239
> URL: https://issues.apache.org/jira/browse/TUSCANY-2239
> Project: Tuscany
> Issue Type: New Feature
> Components: Java SCA Core Runtime
> Reporter: Greg Dritschler
> Assignee: Venkatakrishnan
> Attachments: tuscany-2239.patch
>
>
> The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites.
> I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the <intent/> element in definitions.xml. For example:
> <intent name="propagatesTransaction" constrains="implementation" excludes="suspendsTransaction"/>
> @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below.
> <intent name="suspendsTransaction" constrains="implementation" excludes="propagatesTransaction"/>
> The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out.
> <intent name="noManagedTransaction" constrains="implementation"
> excludes="managedTransaction managedTransaction.global managedTransaction.local"/>
> A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a "default" inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite:
> <component name="C1" requires="propagatesTransaction">
> <reference name="r1"/>
> <reference name="r2"/>
> <reference name="r3" requires="suspendsTransaction"/>
> </component>
> In this case the first two references inherit the default intent "propagatesTransaction" from the component element. However the third reference does not inherit it because it specifies an exclusive intent "suspendsTransaction" which overrides the component-level default.
> The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example:
> <component name="D1">
> <implementation.composite name="CZ1"/>
> <reference name="r1" requires="suspendsTransaction"/>
> </component>
> Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent "propagatesTransaction". This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org