On Dec 5, 2007 11:04 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Would it help if the Intent/PolicySet has a pointer to the its attachpoint > (i.e., where the intent/policy is declared)? > > Thanks, > Raymond > > ----- Original Message ----- > From: "Venkata Krishnan" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Wednesday, December 05, 2007 1:40 AM > Subject: Implementation Policies > > > > Hi, > > > > To set the context its about specification of policies on implementation > > elements in a composite. Since we have implementation model instances > > being reused we have trouble with capturing what policies were set on > an > > implementation under a specific Component. > > > > > > I have this going in the trunk but with a bit of a hack in > > ComponentImpl.getImplementation. Now am looking at cleaning that a bit > > and > > exploring options. > > > > One of the alternatives suggested earlier is to have the implementation > > policies stored in the component itself. But the problem is Component > > themselves can have policies specified over them which will have be > > inherited by the service, implementation and reference child elements > > within. One way of getting around this is to add up the component's > > policies to the services and references child elements right at the time > > of > > reading from the scdl. Then when the implementation child element is > > loaded > > we read its policies and store it into the component. This seems a good > > way > > out but bites during the build phase as follows :- > > > > - One of the things we do in the build phase is validating if policysets > > specified on an implementation element i.e. checking to see if a > specified > > policyset does apply to the implementation type in question. The specs > > says > > that its ok if this validation fails for policysets that have been > > inherited > > (say from the composite or the component), but if this validation fails > > for > > a policyset directly specified for the element then its an error in > > defining > > the composite and it must be flagged. > > > > * > > > ------------------------------------------------------------------------------------------------------------------------ > > 551 When computing the policySets that apply to a particular element, > the > > @appliesTo attribute > > 552 of each relevant policySet is checked against the element. If the > > policySet is attached > > 553 directly to the element and does not apply to that element an error > is > > raised. If a policySet > > 554 that is attached to an ancestor element does not apply to the > element > > in > > question, it is simply > > 555 discarded. > > > ------------------------------------------------------------------------------------------------------------------------- > > * > > > > So if we are going to store in the component model, the policysets > > specified > > on its implementation then during validation its not possible to figure > > out > > if the policyset came thro inheriting the component's policyset or from > > direct definition. > > > > Is there a way out of this ? > > > > Thanks. > > > > - Venkat > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Or have a pointer from each attachpoint to their policy and also a pointer from the component which aggregates them. A similar thing happens in contributions and the domain where composites are both contributed composites and deployable composite.
Simon
