#16 WSDLLocator.close()


Add a new method to the WSDLLocator interface:

public void close();

The client application can call close() to release any
system resources used by the WSDLLocator object. For
example, to close any open input streams.

Requirement originally raised by Pete Hendry on the
JSR110 mailing list -


  • John Kaputin

    John Kaputin - 2006-08-02

    Logged In: YES

    Here is the original message [660] from the mailing list:

    Re: [jsr110-eg-disc] Proposal for WSDLLocator with WSDLReader

    Is it worth having both methods when the Document can simply
    be written as

    readWSDL( locator, doc.getDocumentElement());

    Also, it would be good if the locator could be explicitely
    "disposed" when the work is done as it various InputStreams
    are opened and not closed during the processing of
    importing. We have a wrapper around the call to WSDLReader
    that calls a dispose() method on the locator. The locator
    keeps track of all the inputstreams that are opened during
    parsing and closes them in dispose.

    We found problems with dynamic deployment because wsdl files
    were being kept open and so could not be overwritten on windows.


    Davanum Srinivas wrote:

    >+1 from me.
    >-- dims
    >On 6/24/05, John Kaputin <KAPUTIN@...> wrote:
    >>I have received a requirement from Axis for WSDL4J to
    support the use of a
    >>WSDLLocator for resolving import/include URIs when the
    input to the reader
    >>is a DOM Document representing the WSDL, rather than a
    WSDL URI string.
    >>Thanks to Ellis Pritchard for his suggestions.
    >>I'd like to propose a solution for review and comments by
    the WSDL4J
    >>The problem is that the existing readWSDL(WSDLLocator)
    method is the only
    >>way to set a WSDLLocator on the reader and this approach
    assumes that we
    >>start with the WSDL URI string and InputSource set in the
    locator. In the
    >>Axis requirement, the WSDL is already in memory as a
    Document before the
    >>reader is invoked. However, the only method to pass a
    Document to the
    >>reader is readWSDL(stringURI, Document) which does not
    allow a WSDLLocator
    >>to be set.
    >>The suggestion was to add a setLocator(WSDLLocator) method
    to the
    >>WSDLReader, which can be called prior to calling the
    >>doc) method. This will work, but there is a potential
    problem. Depending
    >>on how the locator is implemented, it may retain WSDL
    >>state info in the form of URIs or Input Sources. The
    intention for the
    >>reader was that it should receive document-specific
    information on each
    >>invocation, but it should not retain such information
    between invocations.
    >>If the reader is subsequently reused with a different
    readWSDL method and
    >>the use of a locator for resolving import URIs is not
    required, unexpected
    >>results may occur because the locator, if it's present,
    will always be used
    >>in preference to any input URI. The reader cannot make any
    >>about the state of the locator and it may be unsafe to
    just assume that the
    >>calling application will always use setLocator(null) when
    it's finished
    >>with a locator. This is also a risk with the existing
    >>readWSDL(WSDLLocator) method because it just leaves the
    locator reference
    >>set in the reader when it's done.
    >>Here is an alternative solution I'd like to propose:
    >>Add two new methods to WSDLReader to support the use of a
    WSDLLocator with
    >>either a Document or Element argument:
    >>public Definition readWSDL(WSDLLocator locator, Document
    >>throws WSDLException;
    >>public Definition readWSDL(WSDLLocator locator, Element
    >>throws WSDLException;
    >>Implement these two methods, and modify the existing
    >>method, so that the locator reference in the reader is set
    to null prior to
    >>returning from the method. In this way, a locator can only
    be used if the
    >>calling application has specified it explicitly in the
    invocation (and has
    >>actively taken responsiblity for setting the correct
    >>information in the locator). The reader cannot use a
    locator unless the
    >>caller expects it to.
    >>This is what the implementation code looks like:
    >>public Definition readWSDL(WSDLLocator locator, Document
    >>throws WSDLException
    >>String base = locator.getBaseURI();
    >>this.loc = locator;
    >>return readWSDL(base, wsdlDocument);
    >>//clear the locator to avoid retaining any
    document-specific state
    >>in the reader
    >>this.loc = null;
    >>As WSDL4J is the reference implementation for JSR110
    JWSDL, changes to the
    >>javax.wsdl interfaces mean changes to the JWSDL
    Specification and API. This
    >>will require a maintenance release under the JCP 2.1
    process, as was done
    >>for the WSDL4J 1.5 maintenance release back in January.
    This involves a 30
    >>day review of a Change Log containing the proposed changes
    and JCP Exec
    >>committee acceptance.
    >>John Kaputin
    >>Yahoo! Groups Links

  • John Kaputin

    John Kaputin - 2006-08-02

    Logged In: YES

    This tracker involves two code changes:
    1) a new method WSDLLocator.close()
    2) in the WSDLReader.readWSDL(WSDLLocator) method, null out
    the locator instance variable on completion of the method.

  • Tom Evans

    Tom Evans - 2006-08-07
    • assigned_to: nobody --> t_e_v_a_n_s
  • John Kaputin

    John Kaputin - 2006-10-12

    Logged In: YES

    Closed. Fix released with WSDL4J v1.6.

  • John Kaputin

    John Kaputin - 2006-10-12
    • status: open --> closed