[jira] [Commented] (CXF-8422) Unclosed input streams after using org.apache.cxf.tools.wsdlto.WSDLToJava
[
https://issues.apache.org/jira/browse/CXF-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288101#comment-17288101
]
Andriy Redko commented on CXF-8422:
---
[~Poręba] came up with this idea [1] to close input source streams:
- introduce new system property
`org.apache.cxf.staxutils.autoCloseInputSource`, by default is `false`
(preserving the current behavior)
- when set, the stream behind InputSource is going to be closed
Would it solve your problem with XMLStreamReader? I am not comfortable with
automatically closing the InputSource by default (except the case when the
stream is created from URL), it could break the preconditions the existing
applications my have.
[1] https://issues.apache.org/jira/browse/CXF-8422
> 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)
[jira] [Created] (CXF-8427) Response exception mappers not invoked on MP async methods
Andy McCright created CXF-8427:
--
Summary: Response exception mappers not invoked on MP async methods
Key: CXF-8427
URL: https://issues.apache.org/jira/browse/CXF-8427
Project: CXF
Issue Type: Bug
Components: MicroProfile
Affects Versions: 3.4.2
Reporter: Andy McCright
Assignee: Andy McCright
Fix For: 3.5.0, 3.4.3
MP Async methods have a return type of CompletionStage and the exception
processing should occur via the CS, not on the actual invocation of the method.
So if a response exception mapper is registered with a MP Rest Client
interface, the associated exception should be on the throws clause for
synchronous methods, but not necessarily for asynchronous methods.
Here's and example:
{code:java}
public interface MyClient {
@GET
@Path("sync")
String getSync() throws MyCustomException;
@GET
@Path("async")
CompletionStage getAync();
{code}
{code:java}
public class MyCustomExceptionResponseMapper implements
ResponseExceptionMapper {
@Override
public boolean handles(int status, MultivaluedMap headers) {
return status == 499;
}
@Override
public MyCustomException toThrowable(Response response) {
return new MyCustomException();
}
}
{code}
For sync invocation, we would expect the invocation to throw the exception:
{code:java}
try {
myClient.getSync();
} catch (MyCustomException ex) {
//...
}
{code}
But for async invocation, we would expect the exception to be throw from the
CompletionStage, like:
{code:java}
CompletionStage cs = myClient.getAsync();
cs.exceptionally(ex -> {
Throwable cause = ex.getCause(); // ex should be a CompletionException
if (cause instanceof MyCustomException) {
// ...
}
});
// or
try {
cs.toCompletableFuture().get();
} catch (ExecutionException ex) {
Throwable cause = ex.getCause();
if (cause instanceof MyCustomException) {
//...
}
}
{code}
Currently, the async flow fails because CXF is checking that the exception type
is listed in the throws clause of the interface method signature. So instead
of throwing a MyCustomException wrapped in a CompletionException (or
ExecutionException), it is throwing a wrapped WebApplicationException.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CXF-8427) Response exception mappers not invoked on MP async methods
[
https://issues.apache.org/jira/browse/CXF-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288156#comment-17288156
]
Andy McCright commented on CXF-8427:
Resolved with commit 01106a1171fd53c5077cbae74143e1421977d91e [1]
[1]
https://github.com/apache/cxf/commit/a84f6e203940e93d81406031d571052ccb4e3fef
> Response exception mappers not invoked on MP async methods
> --
>
> Key: CXF-8427
> URL: https://issues.apache.org/jira/browse/CXF-8427
> Project: CXF
> Issue Type: Bug
> Components: MicroProfile
>Affects Versions: 3.4.2
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
> Fix For: 3.5.0, 3.4.3
>
>
> MP Async methods have a return type of CompletionStage and the exception
> processing should occur via the CS, not on the actual invocation of the
> method. So if a response exception mapper is registered with a MP Rest
> Client interface, the associated exception should be on the throws clause for
> synchronous methods, but not necessarily for asynchronous methods.
> Here's and example:
> {code:java}
> public interface MyClient {
> @GET
> @Path("sync")
> String getSync() throws MyCustomException;
> @GET
> @Path("async")
> CompletionStage getAync();
> {code}
> {code:java}
> public class MyCustomExceptionResponseMapper implements
> ResponseExceptionMapper {
> @Override
> public boolean handles(int status, MultivaluedMap
> headers) {
> return status == 499;
> }
> @Override
> public MyCustomException toThrowable(Response response) {
> return new MyCustomException();
> }
> }
> {code}
> For sync invocation, we would expect the invocation to throw the exception:
> {code:java}
> try {
> myClient.getSync();
> } catch (MyCustomException ex) {
> //...
> }
> {code}
> But for async invocation, we would expect the exception to be throw from the
> CompletionStage, like:
> {code:java}
> CompletionStage cs = myClient.getAsync();
> cs.exceptionally(ex -> {
> Throwable cause = ex.getCause(); // ex should be a CompletionException
> if (cause instanceof MyCustomException) {
> // ...
> }
> });
> // or
> try {
> cs.toCompletableFuture().get();
> } catch (ExecutionException ex) {
> Throwable cause = ex.getCause();
> if (cause instanceof MyCustomException) {
> //...
> }
> }
> {code}
> Currently, the async flow fails because CXF is checking that the exception
> type is listed in the throws clause of the interface method signature. So
> instead of throwing a MyCustomException wrapped in a CompletionException (or
> ExecutionException), it is throwing a wrapped WebApplicationException.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CXF-8427) Response exception mappers not invoked on MP async methods
[
https://issues.apache.org/jira/browse/CXF-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy McCright resolved CXF-8427.
Resolution: Fixed
> Response exception mappers not invoked on MP async methods
> --
>
> Key: CXF-8427
> URL: https://issues.apache.org/jira/browse/CXF-8427
> Project: CXF
> Issue Type: Bug
> Components: MicroProfile
>Affects Versions: 3.4.2
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
> Fix For: 3.5.0, 3.4.3
>
>
> MP Async methods have a return type of CompletionStage and the exception
> processing should occur via the CS, not on the actual invocation of the
> method. So if a response exception mapper is registered with a MP Rest
> Client interface, the associated exception should be on the throws clause for
> synchronous methods, but not necessarily for asynchronous methods.
> Here's and example:
> {code:java}
> public interface MyClient {
> @GET
> @Path("sync")
> String getSync() throws MyCustomException;
> @GET
> @Path("async")
> CompletionStage getAync();
> {code}
> {code:java}
> public class MyCustomExceptionResponseMapper implements
> ResponseExceptionMapper {
> @Override
> public boolean handles(int status, MultivaluedMap
> headers) {
> return status == 499;
> }
> @Override
> public MyCustomException toThrowable(Response response) {
> return new MyCustomException();
> }
> }
> {code}
> For sync invocation, we would expect the invocation to throw the exception:
> {code:java}
> try {
> myClient.getSync();
> } catch (MyCustomException ex) {
> //...
> }
> {code}
> But for async invocation, we would expect the exception to be throw from the
> CompletionStage, like:
> {code:java}
> CompletionStage cs = myClient.getAsync();
> cs.exceptionally(ex -> {
> Throwable cause = ex.getCause(); // ex should be a CompletionException
> if (cause instanceof MyCustomException) {
> // ...
> }
> });
> // or
> try {
> cs.toCompletableFuture().get();
> } catch (ExecutionException ex) {
> Throwable cause = ex.getCause();
> if (cause instanceof MyCustomException) {
> //...
> }
> }
> {code}
> Currently, the async flow fails because CXF is checking that the exception
> type is listed in the throws clause of the interface method signature. So
> instead of throwing a MyCustomException wrapped in a CompletionException (or
> ExecutionException), it is throwing a wrapped WebApplicationException.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CXF-8422) Unclosed input streams after using org.apache.cxf.tools.wsdlto.WSDLToJava
[
https://issues.apache.org/jira/browse/CXF-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288228#comment-17288228
]
Tomasz Poręba commented on CXF-8422:
[~reta] Sure, it would be ok for me. Is there any nightly build where I can
test the new behavior?
> 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)
