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 <[EMAIL PROTECTED]> 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 < > [EMAIL PROTECTED]> > 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 < > > [EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > >
