Peter,
the programming model I outlined is the correct API-based model for using
the Component API. In your case, I don't think you need to use the
Component API. Just use the Element API. During WSDL parsing (including
deserializing extensions) you're dealing with XML infosets, so you should
be able to do this just using the Element API.
The objects passed to your deserializer.unmarshall method by Woden will
include a DescriptionElement for the 'desc' parameter and a
BindingFaultReferenceElement or a BindingMessageReferenceElement for the
'parent' parameter (actually a BindingFaultReferenceImpl object, but it's
BindingFaultReferenceElement that is registered in Woden's extension
registry...ditto for binding message reference).
So, I think you can drop the first two lines (...toComponent() and
...getBindings()) and refer to WSDL Elements instead of Components.
Try this:
if (parent instanceof BindingFaultReferenceElement) {
InterfaceFaultReferenceElement interfaceFaultReferenceElement =
((BindingFaultReferenceElement)parent).getInterfaceFaultReferenceElement();
...
} else if (parent instanceof BindingMessageReferenceElement) {
InterfaceMessageReferenceElement interfaceMessageReferenceElement =
((BindingMessageReferenceElement)parent).getInterfaceMessageReferenceElement();
...
} else {
throw new IllegalArgumentException("Unsupported parent type:
'"+parent.getClass().getName()+"'");
BTW, you've highlighted a problem with the unmarshall method signature.
The 'parent' parameter should be of type WSDLElement, not Object. I guess
I just copied the original signature from WSDL4J. I'll fix this via a
JIRA.
regards,
John Kaputin
"Peter Danielsen" <[EMAIL PROTECTED]> wrote on 07/09/2007 15:50:52:
> 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]
>
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]
