policy itest question

[Greg Dritschler <gr...@gmail.com>]

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

Re: policy itest question

[Venkata Krishnan <fo...@gmail.com>]

Hi Greg,

Please find my comments / answers inline.  Thanks

- Venkat

From: Greg Dritschler <gr...@gmail.com>
> 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 <fo...@gmail.com>
> 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 <
> greg.dritschler@gmail.com
> > >
> > 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

Re: policy itest question

[Greg Dritschler <gr...@gmail.com>]

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 <fo...@gmail.com>
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 <greg.dritschler@gmail.com
> >
> 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
> >
>

Re: policy itest question

[Venkata Krishnan <fo...@gmail.com>]

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 <gr...@gmail.com>
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
>