[
https://issues.apache.org/jira/browse/CXF-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17295427#comment-17295427
]
Tomasz Poręba commented on CXF-8422:
------------------------------------
[~reta] I checked current 3.3.10-SNAPSHOT builds and it works fine for me now -
the file handles are correctly released in my app.
The bug is gone even without that additional property (tried
-Dorg.apache.cxf.staxutils.autoCloseInputSource=true) so maybe those
URIResolvers were the root cause.
Thanks!
> 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)
