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. 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? 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. 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 > > >
