You are viewing a plain text version of this content. The canonical link for it is here.
Posted to woden-dev@ws.apache.org by John Kaputin <KA...@uk.ibm.com> on 2007/01/29 05:08:26 UTC
Use the Woden API to avoid NPEs
A couple of recent posts have been about unexpected NPEs occuring in Woden,
but it turns out these relate to the incorrect programming model being
used.
NPEs can be avoided by using Woden via its API - don't create impl classes
directly via their ctors and don't cast object from their Element to
Component interfaces. The implementation needs to be correctly initialized
and this is guaranteed to happen by using Woden via its API, but not
otherwise. The User Guide on the Woden website needs updating but it's API
usage and programming examples are still basically correct and provide some
guidance. The User Guide and API javadoc will be more complete for M7.
All components should be accessed from the 'top' of the component model -
from the Description component. If you have a DescriptionElement, call
toComponent() on it and traverse the component tree. There's a reason that
the toComponent() method is found on the DescriptionElement but not on any
other Elements; The component model implementation needs to be correctly
initialized and this is triggered by the toComponent() method on
DescriptionElement.
So here's some tips on using the correct API-based programming model:
1) To create a DescriptionElement use
WSDLFactory.newInstance().newDescription(), not new DescriptionImpl(). This
will ensure the extension registry reference is initialized.
2) To create child elements, don't use the Impl ctors. Use the 'add'
methods on the parent element as these will instantiate the object,
initialize its parent reference and return it to the caller.
Eg: InterfaceElement.addInterfaceFaultElement()
3) To use any Components, call toComponent() on the DescriptionElement and
navigate via the Component API from the Description to the required
component.
Note, you can call toElement() on any Component, but not the other way
around.
Many of the Woden unit tests do use impl classes directly, violating the
Woden API. I've even written some of these myself! This was done for
convenience originally - short cuts when creating tests, but as Woden has
evolved it has become more important to use the API correctly. These unit
tests don't actually break, either because setters have been used to
correctly initialize them or because they don't exercise the code paths
that might cause problems when not correctly initialized. However, as
users may end up looking at the test cases for coding examples I think we
should review them and change them to use the API where it's easy to do so.
And document the exceptions if there are any (e.g. it might just be easier
in some cases to set up a complex test case programmatically by using
non-API techniques).
John Kaputin
Web Services Development, Hursley Laboratory
IBM United Kingdom Ltd
Hursley Park MP211, Winchester, SO21 2JN, UK.
email: kaputin@uk.ibm.com
Tel/Fax: +44 (0)1962 817363 (internal 7-247363)
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Use the Woden API to avoid NPEs
Posted by Graham Turrell <GT...@uk.ibm.com>.
Hi John,
Agree 100% with both your comments below.
Regards,
Graham Turrell
John Kaputin/UK/IBM@IBMGB wrote on 29/01/2007 12:20:20:
> Woden provides a warranty on it's (good) behaviour if you use it via the
> prescribed programming model - via its API. If as white box unit testers
> you to choose to use the Impl classes and their ctors directly, rather
than
> build a model via the API, then you need to ensure everything is
> initialized correctly which requires some knowledge of the internals so
> that you can include the necessary initialization in your test case setup
> code. I guess this is what I was getting at. Unit test programmer
beware
> and expect the unexpected (e.g. NPE) if you do it wrong.
>
> With regards to whether or not users might be misled by our unit test
code
> and/or use it as an excuse for coding outside the API, I do think we need
> to be clear in our User documentation that using Woden via it's API and
> it's prescribed programming model is the only supported usage.
>
> regards,
> John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Use the Woden API to avoid NPEs
Posted by John Kaputin <KA...@uk.ibm.com>.
> +1 to your point about constructors. If the ctors are available
internally
> then they certainly should be available to the white-box tester.
Woden provides a warranty on it's (good) behaviour if you use it via the
prescribed programming model - via its API. If as white box unit testers
you to choose to use the Impl classes and their ctors directly, rather than
build a model via the API, then you need to ensure everything is
initialized correctly which requires some knowledge of the internals so
that you can include the necessary initialization in your test case setup
code. I guess this is what I was getting at. Unit test programmer beware
and expect the unexpected (e.g. NPE) if you do it wrong.
With regards to whether or not users might be misled by our unit test code
and/or use it as an excuse for coding outside the API, I do think we need
to be clear in our User documentation that using Woden via it's API and
it's prescribed programming model is the only supported usage.
regards,
John Kaputin
Graham Turrell/UK/IBM@IBMGB wrote on 29/01/2007 10:21:21:
> Agree with Jeremy's comments. I don't think the unit tests should be
> advertised or seen as a guide to using the API at a system or functional
> level.
> Their purpose is simply to test the methods under test, using the minimum
> necessary preconfiguration to accurately test the methods' normal (and
> abnormal) behaviour.
> +1 to your point about constructors. If the ctors are available
internally
> then they certainly should be available to the white-box tester.
>
> Probably plenty of scope for discussion here, and reviews would be good
for
> that.
>
> Kind Regards,
>
> Graham.
> _____________________________________________
> Graham C Turrell CEng, MBCS
> Chartered IT Practitioner
>
> WebSphere ESB Foundation Technologies
> DE3F16 / MP 211
> IBM Labs
> Hursley Park
> Winchester, Hampshire
> England. SO21 2JN
>
> Tel +44-(0)1962-815018
> email: gturrell@uk.ibm.com
>
> "No army can withstand the force of an idea whose time
> has come.". -Victor Hugo
>
> jpjhughes@gmail.com wrote on 29/01/2007 09:38:07:
>
> > On 29/01/07, John Kaputin <KA...@uk.ibm.com> wrote:
> > [...]
> > > Many of the Woden unit tests do use impl classes directly, violating
> the
> > > Woden API. I've even written some of these myself! This was done for
> > > convenience originally - short cuts when creating tests, but as Woden
> has
> > > evolved it has become more important to use the API correctly. These
> unit
> > > tests don't actually break, either because setters have been used to
> > > correctly initialize them or because they don't exercise the code
paths
> > > that might cause problems when not correctly initialized. However,
as
> > > users may end up looking at the test cases for coding examples I
think
> we
> > > should review them and change them to use the API where it's easy to
do
> so.
> >
> > +1 to that.
> >
> > > And document the exceptions if there are any (e.g. it might just be
> easier
> > > in some cases to set up a complex test case programmatically by using
> > > non-API techniques).
> >
> > wouldn't that mean users have an excuse to do the same. 'White box'
> > unit tests should be allowed to use ctors - we could document these
> > tests as such and discourage users to copy the code.
> >
> > Cheers,
> > Jeremy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: woden-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Use the Woden API to avoid NPEs
Posted by Graham Turrell <GT...@uk.ibm.com>.
Agree with Jeremy's comments. I don't think the unit tests should be
advertised or seen as a guide to using the API at a system or functional
level.
Their purpose is simply to test the methods under test, using the minimum
necessary preconfiguration to accurately test the methods' normal (and
abnormal) behaviour.
+1 to your point about constructors. If the ctors are available internally
then they certainly should be available to the white-box tester.
Probably plenty of scope for discussion here, and reviews would be good for
that.
Kind Regards,
Graham.
_____________________________________________
Graham C Turrell CEng, MBCS
Chartered IT Practitioner
WebSphere ESB Foundation Technologies
DE3F16 / MP 211
IBM Labs
Hursley Park
Winchester, Hampshire
England. SO21 2JN
Tel +44-(0)1962-815018
email: gturrell@uk.ibm.com
"No army can withstand the force of an idea whose time
has come.". -Victor Hugo
jpjhughes@gmail.com wrote on 29/01/2007 09:38:07:
> On 29/01/07, John Kaputin <KA...@uk.ibm.com> wrote:
> [...]
> > Many of the Woden unit tests do use impl classes directly, violating
the
> > Woden API. I've even written some of these myself! This was done for
> > convenience originally - short cuts when creating tests, but as Woden
has
> > evolved it has become more important to use the API correctly. These
unit
> > tests don't actually break, either because setters have been used to
> > correctly initialize them or because they don't exercise the code paths
> > that might cause problems when not correctly initialized. However, as
> > users may end up looking at the test cases for coding examples I think
we
> > should review them and change them to use the API where it's easy to do
so.
>
> +1 to that.
>
> > And document the exceptions if there are any (e.g. it might just be
easier
> > in some cases to set up a complex test case programmatically by using
> > non-API techniques).
>
> wouldn't that mean users have an excuse to do the same. 'White box'
> unit tests should be allowed to use ctors - we could document these
> tests as such and discourage users to copy the code.
>
> Cheers,
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Use the Woden API to avoid NPEs
Posted by Jeremy Hughes <hu...@apache.org>.
On 29/01/07, John Kaputin <KA...@uk.ibm.com> wrote:
[...]
> Many of the Woden unit tests do use impl classes directly, violating the
> Woden API. I've even written some of these myself! This was done for
> convenience originally - short cuts when creating tests, but as Woden has
> evolved it has become more important to use the API correctly. These unit
> tests don't actually break, either because setters have been used to
> correctly initialize them or because they don't exercise the code paths
> that might cause problems when not correctly initialized. However, as
> users may end up looking at the test cases for coding examples I think we
> should review them and change them to use the API where it's easy to do so.
+1 to that.
> And document the exceptions if there are any (e.g. it might just be easier
> in some cases to set up a complex test case programmatically by using
> non-API techniques).
wouldn't that mean users have an excuse to do the same. 'White box'
unit tests should be allowed to use ctors - we could document these
tests as such and discourage users to copy the code.
Cheers,
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org