Module com.sun.xml.ws
Package com.sun.xml.ws.api.wsdl.parser

Class WSDLParserExtension

java.lang.Object
com.sun.xml.ws.api.wsdl.parser.WSDLParserExtension
Direct Known Subclasses:
PolicyWSDLParserExtension, W3CAddressingWSDLParserExtension
public abstract class WSDLParserExtension extends Object
Extends the WSDL parsing process.

This interface is implemented by components that build on top of the JAX-WS RI, to participate in the WSDL parsing process that happens in the runtime. This allows such components to retrieve information from WSDL extension elements, and use that later to, for example, configure Tubes.

How it works?

Each method on this interface denotes one extension point in WSDL (the place where foreign elements/attributes can be added.) A RuntimeWSDLParser starts parsing WSDL with a fixed set of WSDLParserExtensions, and as it finds extension elements/attributes, it calls appropriate callback methods to provide a chance for WSDLParserExtension to parse such an extension element.

There are two kinds of callbacks.

Attribute callbacks

One is for attributes, which ends with the name Attributes. This callback is invoked with XMLStreamReader that points to the start tag of the WSDL element.

The callback method can read interesting attributes on it. The method must return without advancing the parser to the next token.

Element callbacks

The other callback is for extension elements, which ends with the name Elements. When a callback is invoked, XMLStreamReader points to the start tag of the extension element. The callback method can do one of the following:

  1. Return false without moving XMLStreamReader, to indicate that the extension element isn't recognized. This allows the next WSDLParserExtension to see this extension element.
  2. Parse the whole subtree rooted at the element, move the cursor to the XMLStreamConstants.END_ELEMENT state, and return true, indicating that the extension element is consumed. No other WSDLParserExtensions are notified of this extension.

Parsing in callback

For each callback, the corresponding WSDL model object is passed in, so that WSDLParserExtension can relate what it's parsing to the WSDLModel. Most likely, extensions can parse their data into an WSDLExtension-derived classes, then use WSDLExtensible interface to hook them into WSDLModel.

Note that since the WSDLModel itself is being built, WSDLParserExtension may not invoke any of the query methods on the WSDL model. Those references are passed just so that WSDLParserExtension can hold on to those references, or put WSDLExtensible objects into the model, not to query it.

If WSDLParserExtension needs to query WSDLModel, defer that processing until finished(WSDLParserExtensionContext), when it's safe to use WSDLModel can be used safely.

Also note that WSDLParserExtensions are called in no particular order. This interface is not designed for having multiple WSDLParserExtensions parse the same extension element.

Error Handling

For usability, WSDLParserExtensions are expected to check possible errors in the extension elements that it parses. When an error is found, it may throw a WebServiceException to abort the parsing of the WSDL. This exception will be propagated to the user, so it should have detailed error messages pointing at the problem.

Discovery

The JAX-WS RI locates the implementation of WSDLParserExtensions by using the standard service look up mechanism, in particular looking for META-INF/services/com.sun.xml.ws.api.wsdl.parser.WSDLParserExtension

TODO

As it's designed today, extensions cannot access to any of the environmental information before the parsing begins (such as what WSService this WSDL is being parsed for, etc.) We might need to reconsider this aspect. The JAX-WS team waits for feedback on this topic.

Author:
Kohsuke Kawaguchi