Hi Peter, the WSDL 2.0 infoset and the WSDL 2.0 component model are subtley different in the containment behaviour of <wsdl:description> versus the Description component. If you want the short answer to your question, see "Correct programming model:" below. A more detailed explanation follows here...
The DescriptionElement represents a <wsdl:description> element and it contains only the interface, binding or service elements declared directly within this description element. You have to navigate via ImportElement or IncludeElement to get to interface, binding and service elements in nested WSDL documents. The Description component provides a flattened view of the WSDL. It corresponds to a <wsdl:description> element at the root of a composite WSDL tree but it contains all interfaces, bindings and services in the WSDL tree, regardless of whether they are declared directly in the root wsdl:description or in an imported or included wsdl:description. The addInterfaceElement / addBindingElement / addServiceElement methods of DescriptionElement will set a reference to that parent description element. However, a Component model is derived from the Element or WSDL infoset model by invoking the toComponent() method on a DescriptionElement and the returned Description contains all of the directly declared, imported and included Interface, Binding and Service components. So we can only determine at the time the Component model is created which DescriptionImpl reference to set as the containing Description for Interface, Binding and Service components (i.e. which DescriptionImpl reference to set fDescriptionComponent to). This might not correspond to the <wsdl:description> element that the wsdl:interface, wsdl:binding and wsdl:service elements are directly declared within - it could be a wsdl:description higher up the WSDL import tree. Typically, the Description component we're interested in corresponds to the root wsdl:element in a composite WSDL tree. This is the behaviour of WSDLReader.readWSDL methods ... pass in the URI of a WSDL document and get back the Description component corresponding to the root wsdl:description element. But it is possible to navigate a composite WSDL tree via the Element API (i.e. via ImportElement and IncludeElement) and call toComponent() on any DescriptionElement and get back a corresponding Component model. Correct programming model: The Woden implementation will be correctly initialised if the Woden API programming model is followed. So to get to any WSDL component you must start at the Description component and navigate down the component model hierarchy to the component you need. For example, in this sequence: 1. Description.getBindings 2. Binding.getBindingMessageReferences() 3. BindingMessageReference.getInterfaceMessageReference(). If you're starting with a DescriptionElement, call toComponent() on it then follow the above sequence. Casting a WSDL Element it to a WSDL Component - e.g. (BindingMessageReference)BindingMessageReferenceElement - is not part of the programming model. The fDescriptionComponent variable will not be initialized and attempts to use the Component API will throw a NPE as the implementation navigates the underlying object model to resolve references. Is this what you're doing in your deserializer unmarshall method? Note, the implementation of the Component API just provides a view of the WSDL derived dynamically from the underlying Element or WSDL infoset object model - the Component model is not derived and stored at parse-time and it's not cached via lazy initialization. When we've finished developing full support for WSDL 2.0 functionality, including Element model updatability and possibly Component model updatability, we'll look at performance of the object model consider whether this is necessary. Let me know if you still have the problem when using the programming model described above. In this case, it might help to see a Java code fragment from your unmarshall method. regards, John Kaputin "Peter Danielsen" <[EMAIL PROTECTED]> wrote on 07/09/2007 04:43:17: > Hi, > > Thanks for implementing the ExtensionRegistrar proposal in JIRA > Woden-163! I appreciate the effort you took to get it into the final > form in SVN. > > I'm working on an extension and would like to validate an element in > its deserializer's unmarshall method. When the extension element is > contained in a BindingMessageReference I try to get its > InterfaceMessageReference, but a null pointer exception occurs in > org.apache.woden.internal.wsdl20.BindingImpl#getInterface when it > tries to use its fDescriptionComponent member. That member is still > null at this point in processing. > > I'm wondering why > org.apache.woden.internal.wsdl20.DescriptionImpl#addBinding doesn't > set the binding's DescriptionComponent property as soon as it adds the > binding to the Description? Currently, it's only set by > DescriptionImpl#getBindings(). > > The same pattern is exhibited with services and interfaces. > > I was expecting interfaces, bindings, and services to be linked to > their containing description as soon as they are created. This would > allow processing at any stage (e.g. interface, binding, service, > endpoint) to refer back to the results of previous stages. > > Thanks in advance for any insights. > > Peter > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
