John,
Thank you for replying and for including the correct programming
model. I wasn't trying to cast a WSDL Element to a WSDL Component.
Here's what I was trying to do in the unmarshall method. It's based
on the knowledge that this extension element can only appear in a
BindingFaultReference or a BindingMessageReference. The unmarshall
method includes the parameters DescriptionElement descriptionElement
and Object parent.
Description description = descriptionElement.toComponent();
description.getBindings(); // inserted only to prevent NPE
if (parent instanceof BindingFaultReference) {
InterfaceFaultReference interfaceFaultReference =
((BindingFaultReference)parent).getInterfaceFaultReference();
...
} else if (parent instanceof BindingMessageReference) {
InterfaceMessageReference interfaceMessageReference =
((BindingMessageReference)parent).getInterfaceMessageReference();
...
} else {
throw new IllegalArgumentException("Unsupported parent type:
'"+parent.getClass().getName()+"'");
}
My thought was that if I know the type of the parent of the object
being unmarshalled then I should be able to go directly to the
corrresponding part of the <interface>. In this situation, the
correct programming model sequence seems like extra work because I
would first have to look upward through the parent's ancestors to find
the Binding to be used in step 2 of the downward navigation. I
already knew the BindingFaultReference/BindingMessageReference so
searching for it didn't seem necessary.
If I understand your explanation of the component creation correctly,
it sounds like the issue I've run into is the dynamic derivation of
the Component model implementation. In its current state, the only way
to access a Description's components during deserialization is to:
1. Create the Description from DescriptionElement.toComponent
2. Use getBindings(), etc. to set the Description to sub-component
linkage whenever something is needed from the Description.
It seems more natural to me to only have to call toComponent. Having
to also call getBindings() was a bit of a surprise. Regardless, is
the approach I've outlined the best for the problem I'm trying to
solve?
Thanks,
Peter
On 9/7/07, John Kaputin <[EMAIL PROTECTED]> wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
