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: [EMAIL PROTECTED] Tel/Fax: +44 (0)1962 817363 (internal 7-247363) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
