[
https://issues.apache.org/jira/browse/CXF-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17285946#comment-17285946
]
Tomasz Poręba commented on CXF-8422:
------------------------------------
[~reta] Ok I understand and it is fine that the reader obeys specs of its
interface. I agree that in such case forcing it with the closeCompletely()
would be a bad idea, especially that we might be working on a different class
there in some other context.
But if the [specification
|https://docs.oracle.com/javase/8/docs/api/javax/xml/stream/XMLStreamReader.html#close--]
says that reader is not responsible for closing the underlying stream, then
the responsibility is on the callers side. Just like here:
[https://stackoverflow.com/questions/5921000/xmlstreamreader-not-closing-opened-xml-file/5921022]
It's a pity, that in our case the "underlying stream" reference is local in the
call of
org.apache.cxf.staxutils.StaxUtils#createXMLStreamReader(org.xml.sax.InputSource).
It seem that "underlying stream" for this specific case, may be any of these
wrapped by a javax.xml.transform.stream.StreamSource
* {color:#000000}org.xml.sax.InputSource#getByteStream(){color}
* {color:#000000}org.xml.sax.InputSource#getCharacterStream(){color}
*
{color:#000000}{color:#000000}java.net.URL#{color}{color}{color:#00627a}openStream{color}()
I guess, that if this StreamSource could somehow be returned to the caller of
org.apache.cxf.staxutils.StaxUtils#createXMLStreamReader then its inputStream
could be gracefully closed just after {color:#000000}XMLStreamReader.{color}
> Unclosed input streams after using org.apache.cxf.tools.wsdlto.WSDLToJava
> -------------------------------------------------------------------------
>
> Key: CXF-8422
> URL: https://issues.apache.org/jira/browse/CXF-8422
> Project: CXF
> Issue Type: Bug
> Affects Versions: 3.3.8, 3.4.2
> Environment: CXF 3.3.8, Windows 10, JDK 1.8
> Reporter: Tomasz Poręba
> Assignee: Andriy Redko
> Priority: Minor
> Fix For: 3.5.0, 3.4.3, 3.3.10
>
>
> I use org.apache.cxf.tools.wsdlto.WSDLToJava in somewhat extraordinary way -
> directly in java as an utility class in my webservice building toolset (not
> via command line, nor maven).
> I noticed that after running the tool on WSDL with customizations in external
> binding file (-b bindings.xbd) some of the input streams remain open, here
> are 3 places I tracked:
>
> 1. org.apache.cxf.resource.URIResolver opens "InputStream is" internally, but
> it is not closed:
> {code:java}
> at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.JAXWSContainer.validate(JAXWSContainer.java:74)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:164)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:156)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:404)
> at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
> {code}
> 2.again org.apache.cxf.resource.URIResolver:
>
> {code:java}
> at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.customization.CustomizationParser.addBinding(CustomizationParser.java:493)
> at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.customization.CustomizationParser.parse(CustomizationParser.java:116)
> at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.customize(JAXWSDefinitionBuilder.java:115)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:188)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:156)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:404)
> at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
> {code}
> 3. closing of XmlStreamReader r by calling r.close() seems to be somewhat
> ineffective. In my debug session this was in fact an instance of
> com.ctc.wstx.sr.ValidatingStreamReader. After calling close() the file handle
> is still kept by the process.
> On the other hand calling "((ValidatingStreamReader) r).closeCompletely(); "
> instead correctly releases the handle, though this is just a wild guess.
> {code:java}
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.addBindingFiles(JAXBDataBinding.java:584)
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:442)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:715)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:259)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:156)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:404)
> at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
> {code}
>
> A side effect on windows is inability to clean up those binding files after
> the tool finishes.
> Luckily that does not affect linux installations.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
