Hi, I have put in a few more changes to get the support for policies on operations going without the hack that I had previously introduced to the ComponentImpl.getImplementation and setImplementation. I am continuing to use OperationsConfigurator and ConfiguredOperation interfaces as am yet to convince myself about holding 'operation' instances within 'Intent' instances ;-).
Thanks - Venkat On Dec 8, 2007 11:39 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > >
