Hi, First, thanks for the help. I am not so comfortable with having inside an intent or a policyset, a pointer to an assembly model artifact. I somehow see a one way dependency that goes from the assembly model to the policy model i.e. an assembly model artifact must know the policies attached to it, but a policy (intent or policyset) doesn't quite need to know where it is attached. The fact that a policy intent 'constrains' or a policyset 'appliesTo' a particular 'class' of assembly model artifacts is a different thing.
I am trying another work around for this. Will let you folks know of it once I am sure it works for me locally and get your views. Thanks - Venkat On Dec 6, 2007 2:36 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > 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 >
