Hi, I've tried another way out of this and it works... here is a jist of what I've done...
- During the composite loading phase itself aggregate the policies into the child elements. This makes the component free to take over the implementation policies since it has already given away the policies that the child element should inherit. - Just before an Implementation is resolved, validate the policies that have been specified on the implementation. Upto the resolution point every component has its own implementation model instance. Its only after resolution that they might end up sharing an existing instance. So at this point the validity of policies specified on the implementation is checked and then copied over to the component. - From then on wherever implemenation policies are to be computed the component's policies are used (since that is where we have now stored the implementation's policies) I've now got rid of the hacks and also cleaned up the policy computing code out of the CompositeWireBuilder. I am right now resolving some conflicts after an update I did just now... I shall check in this after that. Next I shall iron out the hack around support for policies in operations and then get back to the secure-bigbank scenario to move that further. Thanks - Venkat On Dec 6, 2007 3:20 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > 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 > > > >
