Hi Greg, Please find my comments / answers inline. Thanks
- Venkat From: Greg Dritschler <[EMAIL PROTECTED]> > Date: Apr 8, 2008 7:05 PM > Subject: Re: policy itest question > To: tuscany-dev@ws.apache.org > > D'oh! I didn't think to look at the java classes for annotations. That > explains a lot. > > I agree the itest had some limitations. In particular I think it would > catch if the policy handlers were created with the wrong policy sets, but > it > didn't verify if some expected policy handlers were not created. Over here I assume that the expected PolicyHandlers are called. If there is no PolicyHandler found for a PolicySet, then that would get flagged. My intention was only to verify if the right PolicySets get applied which I could only verify by checking if the PolicyHanlder is called with the right PolicySet. The simpler option would be to get hold of the Composite just after its built and verify the PolicySets that have been attached to the various SCA Artifacts. But all of this is subject to revisit and change as the PolicyHandler is on its way out with the arrival of PolicyProviders. So verifying from handlers is not going to stay for long. > > > Doesn't the test in the assembly module do read/resolve/build > testing? How > would this be different? I think the assembly module can't test the full > inheritance of intents down to implementation or binding given assembly is > so early in the build. Would this new test address that? > With the assembly module, as you point out rightly, I could just about test for the inheritance excluding the bindings and implementation extensions. If this was also to be done in the assembly module there are issues with pulling in the extensions as dependencies. So, I'd like to cover more comprehensive tests here including binding and implementation extensions. And to do this I intend to do the read, resolve and build explicitly and verify against the built up composite instead of starting the runtime. I'd like to hear if people have objections to this as in all our itests we typically start up the runtime. > > The reason I'm asking about this is that I'm working on the support for > mutually-exclusive intents and I would like to modify an existing test > rather than start from scratch. > Yes, this makes sense. We should have all sorts of test for policies in this itest module. > > On Tue, Apr 8, 2008 at 9:20 AM, Venkata Krishnan <[EMAIL PROTECTED]> > wrote: > > > Hi Greg, > > > > This itest needs to be re-written after the changes to the > PolicyHandling > > story for the java implementation extension. > > > > Also I put in this itest to get some cases of policy annotations > verified > > at > > a rudimentary level - like checking to see if the annotations ever get > > picked up and applied. IMO, using interceptors for this testing is > quite > > ugly and not going to go very far. I am going to change this to > > explicitly > > execute read, resolve and build phases and simply verify against the > built > > up composite. > > > > Thanks > > > > - Venkat > > > > On Mon, Apr 7, 2008 at 4:12 AM, Greg Dritschler < > [EMAIL PROTECTED] > > > > > wrote: > > > > > What is the status of the policy itest? It uses the PolicyHandler > > > interface > > > to do its verification and that doesn't seem to work anymore, at least > > for > > > Java implementations. (The call to instantiate the > > > JavaPolicyHandlingRuntimeWireProcessor in JavaRuntimeModuleActivator > is > > > commented out.) Is this itest going to be rewritten? > > > > > > I can't say that I understand how this itest was supposed to have > > worked. > > > The composite uses only one intent, TestIntent_3, on the > implementation > > of > > > AddServiceComponent. That intent is provided by one policy set > > > TestPolicySet_3_implementation. Yet it looks to me like > > > TestImplPolicyHandler is quite happy if various other policy sets are > > > selected, such TestPolicySet_1_implementation or > > > TestPolicySet_2_implementation. What's the story? > > > > > > Greg Dritschler > > > > > > > > -- > Thanks & Regards, > Ramkumar Ramalingam
