[ 
https://issues.apache.org/jira/browse/CXF-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17285513#comment-17285513
 ] 

Alan Mehio commented on CXF-8422:
---------------------------------

If it is possible to change the Jira title to "Unclosed input streams needs to 
be closed across different classes"

The suggested fix for URIResolver  to implements AutoCloseable   which shows 
the changes across different java classes 

[https://github.com/apache/cxf/pull/745/files/3d97660d122aadf131ece15150bf7837c6091d6d]

I looked at  this file change 
[https://github.com/apache/cxf/pull/745/files/3d97660d122aadf131ece15150bf7837c6091d6d#diff-ec321b4b406c3fa7b6a078eb75d8c9889c1df8a117ad1ec62ba2d2cd8fb9ade5]

 l line 146 , we can find more improvement here to close another input stream 
with try with resource  statement

from 
{code:java}
   try {       d = StaxUtils.read(url.openStream());       } catch (Exception 
e) {       throw new ServiceConstructionException(new 
Message("ERROR_READING_SCHEMA", LOG, l), e);       }   {code}
|
 
to 
{code:java}
try (InputStream is = url.openStream()) {try (InputStream is = 
url.openStream()) {            d = StaxUtils.read(is);            } catch 
(IOException | XMLStreamException e ) {                throw new 
ServiceConstructionException(new Message("ERROR_READING_SCHEMA", LOG, l), e);   
         }{code}
The idea is to go through more files and look for any open resource and try to 
use the java language feature "try with resources" 
 
|

> 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)

Reply via email to