[CXF-2900] WSDLValidator through Stax2DOM leaves input streams open which causes input files to be locked.

• Type: Bug
• Status: Closed
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 2.2.9
• Fix Version/s: 2.2.10
• Component/s: Tooling

Environment

java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)

Microsoft Windows [Version 6.0.6002]

• Assignee: Daniel Kulp
• Reporter: Gary D. Gregory
• Created: 15/Jul/10 23:58
• Updated: 10/Mar/11 23:16
• Resolved: 16/Jul/10 15:06

Description

The WSDLValidator class leaves input stream open. This causes the validated file to be locked and it cannot be deleted, which messes up our software.

Only when the Java process exists can the file be reclaimed. It is possible that a GC closes the file when the input stream is found and no longer reachable.

I am invoking the WSDLValidator class programatically like this:

    private static void cxfValidateWsdl(File wsdlFile) throws Exception {
        CommandInterfaceUtils.commandCommonMain();
        ToolRunner.runTool(WSDLValidator.class, WSDLValidator.class.getResourceAsStream("wsdlvalidator.xml"), false, new String[] {
                "-verbose", wsdlFile.toURI().toString() });
    }

Down the line, CXF opens but does not close the input file stream in Stax2DOM:

    public Document getDocument(URL url) throws ToolException {
        try {
            StreamSource src = new StreamSource(url.openStream(), url.toExternalForm());
            return StaxUtils.read(StaxUtils.createXMLStreamReader(src), true);
        } catch (Exception e) {
            throw new ToolException(e);
        }
    }

This is fixed for all getDocument methods in the attached patch.

I am not sure how to work around this aside from rebuilding CXF or waiting for 2.2.10.