[jira] [Updated] (CXF-9062) Be able to create AsyncHTTPConduit based on URLConnectionHTTPConduit
[ https://issues.apache.org/jira/browse/CXF-9062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9062: -- Fix Version/s: 4.1.0 3.6.5 4.0.6 > Be able to create AsyncHTTPConduit based on URLConnectionHTTPConduit > > > Key: CXF-9062 > URL: https://issues.apache.org/jira/browse/CXF-9062 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > When system property "org.apache.cxf.transport.http.forceURLConnection" is > true, we should create AsyncHTTPConduit based on the original > URLConnectionHTTPConduit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CXF-9057) Chunked Stream is closed regularly when Exception is thrown
[
https://issues.apache.org/jira/browse/CXF-9057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887378#comment-17887378
]
Johannes Herr edited comment on CXF-9057 at 10/7/24 3:49 PM:
-
I have attached the file {{chunked-reproducer.tar.gz}}. To run it:
{noformat}
tar xzf chunked-reproducer.tar.gz
cd chunked-demo/
mvn test
{noformat}
{{ServerMock}} is a Jetty Server with a CXF SOAP-API. It defines a service to
download data which will throw an exception, while streaming the result. It
also provides a servlet that does the same for comparions.
{{ServerMockTest}} defines 3 Test. One uses the generated CXF client to call
the streaming service. Here an exception would be expected, which is not
thrown. Instead incomplete data is returned.
The other two test cases use raw sockets to be able to print the server
response to stdout. There are not asserts. It is just a demonstration of the
differing behaviour of CXF and servlets. One would see the same if one inspects
the traffic of the first test case with Wireshark.
I hope this helps. Let me know if you need anything else.
was (Author: johannes.herr):
I have attached the file {{chunked-reproducer.tar.gz}}. To run it:
{{noformat}}
tar xzf chunked-reproducer.tar.gz
cd chunked-demo/
mvn test
{{noformat}}
{{ServerMock}} is a Jetty Server with a CXF SOAP-API. It defines a service to
download data which will throw an exception, while streaming the result. It
also provides a servlet that does the same for comparions.
{{ServerMockTest}} defines 3 Test. One uses the generated CXF client to call
the streaming service. Here an exception would be expected, which is not
thrown. Instead incomplete data is returned.
The other two test cases use raw sockets to be able to print the server
response to stdout. There are not asserts. It is just a demonstration of the
differing behaviour of CXF and servlets. One would see the same if one inspects
the traffic of the first test case with Wireshark.
I hope this helps. Let me know if you need anything else.
> Chunked Stream is closed regularly when Exception is thrown
> ---
>
> Key: CXF-9057
> URL: https://issues.apache.org/jira/browse/CXF-9057
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.8
>Reporter: Johannes Herr
>Priority: Major
> Attachments: chunked-reproducer.tar.gz
>
>
> In response to SOAP requests served by Apache CXF we send large datasets
> streamed directly from a database. Because of the size of the data, chunked
> encoding is used. Unfortunately when a database error occurs and an exception
> is thrown while data is sent, the client will receive a regular ending to the
> chunked data stream. That means he has no way to recognise that an error
> occurred and that he has only received a partial file.
> To be more specific the response looks somewhat like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Tue, 10 Sep 2024 16:17:45 GMT
> Content-Type: multipart/related; type="application/xop+xml";
> boundary="uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940";
> start=""; start-info="text/xml"
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8000
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID:
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>[...]
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type:
> Content-Transfer-Encoding: binary
> Content-ID: <03d4ea67-6e8b-4d1f-91b0-b63208989f9...@cxf.apache.org>
> [...]xxx
> 356
> xx
> 0
> {code}
> That means the response ends with the "0" entry, indicating that the transfer
> is complete.
[jira] [Commented] (CXF-9057) Chunked Stream is closed regularly when Exception is thrown
[
https://issues.apache.org/jira/browse/CXF-9057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887378#comment-17887378
]
Johannes Herr commented on CXF-9057:
I have attached the file {{chunked-reproducer.tar.gz}}. To run it:
{{noformat}}
tar xzf chunked-reproducer.tar.gz
cd chunked-demo/
mvn test
{{noformat}}
{{ServerMock}} is a Jetty Server with a CXF SOAP-API. It defines a service to
download data which will throw an exception, while streaming the result. It
also provides a servlet that does the same for comparions.
{{ServerMockTest}} defines 3 Test. One uses the generated CXF client to call
the streaming service. Here an exception would be expected, which is not
thrown. Instead incomplete data is returned.
The other two test cases use raw sockets to be able to print the server
response to stdout. There are not asserts. It is just a demonstration of the
differing behaviour of CXF and servlets. One would see the same if one inspects
the traffic of the first test case with Wireshark.
I hope this helps. Let me know if you need anything else.
> Chunked Stream is closed regularly when Exception is thrown
> ---
>
> Key: CXF-9057
> URL: https://issues.apache.org/jira/browse/CXF-9057
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.8
>Reporter: Johannes Herr
>Priority: Major
> Attachments: chunked-reproducer.tar.gz
>
>
> In response to SOAP requests served by Apache CXF we send large datasets
> streamed directly from a database. Because of the size of the data, chunked
> encoding is used. Unfortunately when a database error occurs and an exception
> is thrown while data is sent, the client will receive a regular ending to the
> chunked data stream. That means he has no way to recognise that an error
> occurred and that he has only received a partial file.
> To be more specific the response looks somewhat like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Tue, 10 Sep 2024 16:17:45 GMT
> Content-Type: multipart/related; type="application/xop+xml";
> boundary="uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940";
> start=""; start-info="text/xml"
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8000
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID:
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>[...]
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type:
> Content-Transfer-Encoding: binary
> Content-ID: <03d4ea67-6e8b-4d1f-91b0-b63208989f9...@cxf.apache.org>
> [...]xxx
> 356
> xx
> 0
> {code}
> That means the response ends with the "0" entry, indicating that the transfer
> is complete.
> What should happen instead is that the response should be closed without
> sending the final 0 entry. ([https://stackoverflow.com/a/17203961/136247])
> For example when we use a Servlet to stream data to a client a throw an
> exception the result will look something like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Fri, 13 Sep 2024 09:31:48 GMT
> Content-Type: text/plain;charset=utf-8
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8
> Chunk 1
> 8
> Chunk 2
> 8
> Chunk 3
> 8
> Chunk 4
> 8
> Chunk 5
> {code}
> Here there is no closing 0 marker. As a result clients can recognise the
> error. (Curl will report "curl: (18) transfer closed with outstanding read
> data remaining", Chrome "Failed to load resource:
> net::ERR_INCOMPLETE_CHUNKED_ENCODING")
> CXF should do the same and not end the chunked stream regularly, when an
> exception is thrown.
> I have tested
[jira] [Updated] (CXF-9057) Chunked Stream is closed regularly when Exception is thrown
[
https://issues.apache.org/jira/browse/CXF-9057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Herr updated CXF-9057:
---
Attachment: chunked-reproducer.tar.gz
> Chunked Stream is closed regularly when Exception is thrown
> ---
>
> Key: CXF-9057
> URL: https://issues.apache.org/jira/browse/CXF-9057
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.8
>Reporter: Johannes Herr
>Priority: Major
> Attachments: chunked-reproducer.tar.gz
>
>
> In response to SOAP requests served by Apache CXF we send large datasets
> streamed directly from a database. Because of the size of the data, chunked
> encoding is used. Unfortunately when a database error occurs and an exception
> is thrown while data is sent, the client will receive a regular ending to the
> chunked data stream. That means he has no way to recognise that an error
> occurred and that he has only received a partial file.
> To be more specific the response looks somewhat like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Tue, 10 Sep 2024 16:17:45 GMT
> Content-Type: multipart/related; type="application/xop+xml";
> boundary="uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940";
> start=""; start-info="text/xml"
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8000
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID:
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>[...]
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type:
> Content-Transfer-Encoding: binary
> Content-ID: <03d4ea67-6e8b-4d1f-91b0-b63208989f9...@cxf.apache.org>
> [...]xxx
> 356
> xx
> 0
> {code}
> That means the response ends with the "0" entry, indicating that the transfer
> is complete.
> What should happen instead is that the response should be closed without
> sending the final 0 entry. ([https://stackoverflow.com/a/17203961/136247])
> For example when we use a Servlet to stream data to a client a throw an
> exception the result will look something like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Fri, 13 Sep 2024 09:31:48 GMT
> Content-Type: text/plain;charset=utf-8
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8
> Chunk 1
> 8
> Chunk 2
> 8
> Chunk 3
> 8
> Chunk 4
> 8
> Chunk 5
> {code}
> Here there is no closing 0 marker. As a result clients can recognise the
> error. (Curl will report "curl: (18) transfer closed with outstanding read
> data remaining", Chrome "Failed to load resource:
> net::ERR_INCOMPLETE_CHUNKED_ENCODING")
> CXF should do the same and not end the chunked stream regularly, when an
> exception is thrown.
> I have tested with Tomcat and Jetty. Both show the same behaviour.
> To provide some detail, Exceptions are caught by CXF here:
> org/apache/cxf/phase/PhaseInterceptorChain.java:328
> {code:java}
> } catch (RuntimeException ex) {
> if (!faultOccurred) {
> faultOccurred = true;
> wrapExceptionAsFault(message, ex);
> }
> state = State.ABORTED;
> }
> {code}
> The exception is logged, but not rethrown.
> If the exception would be thrown, for instance Tomcats ErrorReportValve would
> shut down the output and thereby prevent the end of the input and closing 0
> to be written.
> org/apache/catalina/valves/ErrorReportValve.java:112
> {code:java}
> // Now close immediately to signal to the client that
>
[jira] [Commented] (CXF-9062) Be able to create AsyncHTTPConduit based on URLConnectionHTTPConduit
[ https://issues.apache.org/jira/browse/CXF-9062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886966#comment-17886966 ] Freeman Yue Fang commented on CXF-9062: --- Sent PR https://github.com/apache/cxf/pull/2093 > Be able to create AsyncHTTPConduit based on URLConnectionHTTPConduit > > > Key: CXF-9062 > URL: https://issues.apache.org/jira/browse/CXF-9062 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > > When system property "org.apache.cxf.transport.http.forceURLConnection" is > true, we should create AsyncHTTPConduit based on the original > URLConnectionHTTPConduit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9063) OpenTelemetry context leak with CXF async client
[ https://issues.apache.org/jira/browse/CXF-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886953#comment-17886953 ] Andriy Redko commented on CXF-9063: --- Awesome, thanks a lot [~ffang]! > OpenTelemetry context leak with CXF async client > > > Key: CXF-9063 > URL: https://issues.apache.org/jira/browse/CXF-9063 > Project: CXF > Issue Type: Bug > Components: Core, Tracing >Affects Versions: 4.0.5 >Reporter: Matthew Robson >Priority: Major > > There seems to be a Otel context leak when using a CXF producer in async > mode. This causes different requests to have the same traceId. As a > workaround, setting synchronous=true on the CXF producer resolves the issue. > Unit test to reproduce added to camel: > https://github.com/apache/camel/blob/7d83a62b8e442dc9ac6fd79b153192add940301e/components/camel-opentelemetry/src/test/java/org/apache/camel/opentelemetry/AsyncCxfTest.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9064) AsyncHTTPConduit doesn't close wrappedStream on close
[
https://issues.apache.org/jira/browse/CXF-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886936#comment-17886936
]
Alexey Deryabin commented on CXF-9064:
--
Thank you [~reta] for quick response.
You are right, the {{wrappedStream}} is closed by the {{supe.close()}} call
chain but my concern about the local variable {{out}} which is pointed to the
old {{wrappedStream}}.
You never close old stream that is why tempFile is leaking in some cases.
> AsyncHTTPConduit doesn't close wrappedStream on close
> -
>
> Key: CXF-9064
> URL: https://issues.apache.org/jira/browse/CXF-9064
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.6.4
>Reporter: Alexey Deryabin
>Priority: Major
>
> I found that in
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit$AsyncWrappedOutputStream
> on close method the wrappedStream is not closed but reassigned to the new
> anonymous OutputStream in handleHeadersTrustCaching by setupWrappedStream.
> It is in cxf-rt-transports-http-hc module.
> My suggest to add out.close() on 426 line.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9063) OpenTelemetry context leak with CXF async client
[ https://issues.apache.org/jira/browse/CXF-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886929#comment-17886929 ] Freeman Yue Fang commented on CXF-9063: --- Hi [~reta], I have checked this issue quickly and put my comment in CAMEL-21302. For now I think most likely we need to address it in camel code base. Best Regards Freeman > OpenTelemetry context leak with CXF async client > > > Key: CXF-9063 > URL: https://issues.apache.org/jira/browse/CXF-9063 > Project: CXF > Issue Type: Bug > Components: Core, Tracing >Affects Versions: 4.0.5 >Reporter: Matthew Robson >Priority: Major > > There seems to be a Otel context leak when using a CXF producer in async > mode. This causes different requests to have the same traceId. As a > workaround, setting synchronous=true on the CXF producer resolves the issue. > Unit test to reproduce added to camel: > https://github.com/apache/camel/blob/7d83a62b8e442dc9ac6fd79b153192add940301e/components/camel-opentelemetry/src/test/java/org/apache/camel/opentelemetry/AsyncCxfTest.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9064) AsyncHTTPConduit doesn't close wrappedStream on close
[ https://issues.apache.org/jira/browse/CXF-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886809#comment-17886809 ] Andriy Redko commented on CXF-9064: --- Thanks [~exprompt], the wrappedStream is closed by `super.close()` call chain, more specifically AbstractWrappedOutputStream::close() (if it is not cached), does it address your concern? Thank you. > AsyncHTTPConduit doesn't close wrappedStream on close > - > > Key: CXF-9064 > URL: https://issues.apache.org/jira/browse/CXF-9064 > Project: CXF > Issue Type: Bug >Affects Versions: 3.6.4 >Reporter: Alexey Deryabin >Priority: Major > > I found that in > org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit$AsyncWrappedOutputStream > on close method the wrappedStream is not closed but reassigned to the new > anonymous OutputStream in handleHeadersTrustCaching by setupWrappedStream. > It is in cxf-rt-transports-http-hc module. > My suggest to add out.close() on 426 line. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9063) OpenTelemetry context leak with CXF async client
[ https://issues.apache.org/jira/browse/CXF-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886808#comment-17886808 ] Andriy Redko commented on CXF-9063: --- Thanks [~mrobson], will look at it shortly > OpenTelemetry context leak with CXF async client > > > Key: CXF-9063 > URL: https://issues.apache.org/jira/browse/CXF-9063 > Project: CXF > Issue Type: Bug > Components: Core, Tracing >Affects Versions: 4.0.5 >Reporter: Matthew Robson >Priority: Major > > There seems to be a Otel context leak when using a CXF producer in async > mode. This causes different requests to have the same traceId. As a > workaround, setting synchronous=true on the CXF producer resolves the issue. > Unit test to reproduce added to camel: > https://github.com/apache/camel/blob/7d83a62b8e442dc9ac6fd79b153192add940301e/components/camel-opentelemetry/src/test/java/org/apache/camel/opentelemetry/AsyncCxfTest.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-9064) AsyncHTTPConduit doesn't close wrappedStream on close
Alexey Deryabin created CXF-9064: Summary: AsyncHTTPConduit doesn't close wrappedStream on close Key: CXF-9064 URL: https://issues.apache.org/jira/browse/CXF-9064 Project: CXF Issue Type: Bug Affects Versions: 3.6.4 Reporter: Alexey Deryabin I found that in org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit$AsyncWrappedOutputStream on close method the wrappedStream is not closed but reassigned to the new anonymous OutputStream in handleHeadersTrustCaching by setupWrappedStream. It is in cxf-rt-transports-http-hc module. My suggest to add out.close() on 426 line. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-9063) OpenTelemetry context leak with CXF async client
Matthew Robson created CXF-9063: --- Summary: OpenTelemetry context leak with CXF async client Key: CXF-9063 URL: https://issues.apache.org/jira/browse/CXF-9063 Project: CXF Issue Type: Bug Components: Core, Tracing Affects Versions: 4.0.5 Reporter: Matthew Robson There seems to be a Otel context leak when using a CXF producer in async mode. This causes different requests to have the same traceId. As a workaround, setting synchronous=true on the CXF producer resolves the issue. Unit test to reproduce added to camel: https://github.com/apache/camel/blob/7d83a62b8e442dc9ac6fd79b153192add940301e/components/camel-opentelemetry/src/test/java/org/apache/camel/opentelemetry/AsyncCxfTest.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9057) Chunked Stream is closed regularly when Exception is thrown
[
https://issues.apache.org/jira/browse/CXF-9057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886385#comment-17886385
]
Andriy Redko commented on CXF-9057:
---
Thank you!
> Chunked Stream is closed regularly when Exception is thrown
> ---
>
> Key: CXF-9057
> URL: https://issues.apache.org/jira/browse/CXF-9057
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.8
>Reporter: Johannes Herr
>Priority: Major
>
> In response to SOAP requests served by Apache CXF we send large datasets
> streamed directly from a database. Because of the size of the data, chunked
> encoding is used. Unfortunately when a database error occurs and an exception
> is thrown while data is sent, the client will receive a regular ending to the
> chunked data stream. That means he has no way to recognise that an error
> occurred and that he has only received a partial file.
> To be more specific the response looks somewhat like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Tue, 10 Sep 2024 16:17:45 GMT
> Content-Type: multipart/related; type="application/xop+xml";
> boundary="uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940";
> start=""; start-info="text/xml"
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8000
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID:
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>[...]
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type:
> Content-Transfer-Encoding: binary
> Content-ID: <03d4ea67-6e8b-4d1f-91b0-b63208989f9...@cxf.apache.org>
> [...]xxx
> 356
> xx
> 0
> {code}
> That means the response ends with the "0" entry, indicating that the transfer
> is complete.
> What should happen instead is that the response should be closed without
> sending the final 0 entry. ([https://stackoverflow.com/a/17203961/136247])
> For example when we use a Servlet to stream data to a client a throw an
> exception the result will look something like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Fri, 13 Sep 2024 09:31:48 GMT
> Content-Type: text/plain;charset=utf-8
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8
> Chunk 1
> 8
> Chunk 2
> 8
> Chunk 3
> 8
> Chunk 4
> 8
> Chunk 5
> {code}
> Here there is no closing 0 marker. As a result clients can recognise the
> error. (Curl will report "curl: (18) transfer closed with outstanding read
> data remaining", Chrome "Failed to load resource:
> net::ERR_INCOMPLETE_CHUNKED_ENCODING")
> CXF should do the same and not end the chunked stream regularly, when an
> exception is thrown.
> I have tested with Tomcat and Jetty. Both show the same behaviour.
> To provide some detail, Exceptions are caught by CXF here:
> org/apache/cxf/phase/PhaseInterceptorChain.java:328
> {code:java}
> } catch (RuntimeException ex) {
> if (!faultOccurred) {
> faultOccurred = true;
> wrapExceptionAsFault(message, ex);
> }
> state = State.ABORTED;
> }
> {code}
> The exception is logged, but not rethrown.
> If the exception would be thrown, for instance Tomcats ErrorReportValve would
> shut down the output and thereby prevent the end of the input and closing 0
> to be written.
> org/apache/catalina/valves/ErrorReportValve.java:112
> {code:java}
> // Now close immediately to signal to the client that
> // something went wrong
>
[jira] [Commented] (CXF-9057) Chunked Stream is closed regularly when Exception is thrown
[
https://issues.apache.org/jira/browse/CXF-9057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886376#comment-17886376
]
Johannes Herr commented on CXF-9057:
Hi Andriy, I will create a small project to demonstrate the problem. Might take
until next week though.
> Chunked Stream is closed regularly when Exception is thrown
> ---
>
> Key: CXF-9057
> URL: https://issues.apache.org/jira/browse/CXF-9057
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.8
>Reporter: Johannes Herr
>Priority: Major
>
> In response to SOAP requests served by Apache CXF we send large datasets
> streamed directly from a database. Because of the size of the data, chunked
> encoding is used. Unfortunately when a database error occurs and an exception
> is thrown while data is sent, the client will receive a regular ending to the
> chunked data stream. That means he has no way to recognise that an error
> occurred and that he has only received a partial file.
> To be more specific the response looks somewhat like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Tue, 10 Sep 2024 16:17:45 GMT
> Content-Type: multipart/related; type="application/xop+xml";
> boundary="uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940";
> start=""; start-info="text/xml"
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8000
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID:
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>[...]
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type:
> Content-Transfer-Encoding: binary
> Content-ID: <03d4ea67-6e8b-4d1f-91b0-b63208989f9...@cxf.apache.org>
> [...]xxx
> 356
> xx
> 0
> {code}
> That means the response ends with the "0" entry, indicating that the transfer
> is complete.
> What should happen instead is that the response should be closed without
> sending the final 0 entry. ([https://stackoverflow.com/a/17203961/136247])
> For example when we use a Servlet to stream data to a client a throw an
> exception the result will look something like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Fri, 13 Sep 2024 09:31:48 GMT
> Content-Type: text/plain;charset=utf-8
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8
> Chunk 1
> 8
> Chunk 2
> 8
> Chunk 3
> 8
> Chunk 4
> 8
> Chunk 5
> {code}
> Here there is no closing 0 marker. As a result clients can recognise the
> error. (Curl will report "curl: (18) transfer closed with outstanding read
> data remaining", Chrome "Failed to load resource:
> net::ERR_INCOMPLETE_CHUNKED_ENCODING")
> CXF should do the same and not end the chunked stream regularly, when an
> exception is thrown.
> I have tested with Tomcat and Jetty. Both show the same behaviour.
> To provide some detail, Exceptions are caught by CXF here:
> org/apache/cxf/phase/PhaseInterceptorChain.java:328
> {code:java}
> } catch (RuntimeException ex) {
> if (!faultOccurred) {
> faultOccurred = true;
> wrapExceptionAsFault(message, ex);
> }
> state = State.ABORTED;
> }
> {code}
> The exception is logged, but not rethrown.
> If the exception would be thrown, for instance Tomcats ErrorReportValve would
> shut down the output and thereby prevent the end of the input and closing 0
> to be written.
> org/apache/catalina/valves/ErrorReportValve.java:112
> {code:java}
> // Now close
[jira] [Commented] (CXF-9057) Chunked Stream is closed regularly when Exception is thrown
[
https://issues.apache.org/jira/browse/CXF-9057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886297#comment-17886297
]
Andriy Redko commented on CXF-9057:
---
Thanks [~johannes.herr], do you by any chance have a reproducible test case (or
application) for this issue? thank you
> Chunked Stream is closed regularly when Exception is thrown
> ---
>
> Key: CXF-9057
> URL: https://issues.apache.org/jira/browse/CXF-9057
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.8
>Reporter: Johannes Herr
>Priority: Major
>
> In response to SOAP requests served by Apache CXF we send large datasets
> streamed directly from a database. Because of the size of the data, chunked
> encoding is used. Unfortunately when a database error occurs and an exception
> is thrown while data is sent, the client will receive a regular ending to the
> chunked data stream. That means he has no way to recognise that an error
> occurred and that he has only received a partial file.
> To be more specific the response looks somewhat like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Tue, 10 Sep 2024 16:17:45 GMT
> Content-Type: multipart/related; type="application/xop+xml";
> boundary="uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940";
> start=""; start-info="text/xml"
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8000
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID:
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>[...]
> --uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
> Content-Type:
> Content-Transfer-Encoding: binary
> Content-ID: <03d4ea67-6e8b-4d1f-91b0-b63208989f9...@cxf.apache.org>
> [...]xxx
> 356
> xx
> 0
> {code}
> That means the response ends with the "0" entry, indicating that the transfer
> is complete.
> What should happen instead is that the response should be closed without
> sending the final 0 entry. ([https://stackoverflow.com/a/17203961/136247])
> For example when we use a Servlet to stream data to a client a throw an
> exception the result will look something like this:
> {code:java}
> HTTP/1.1 200 OK
> Date: Fri, 13 Sep 2024 09:31:48 GMT
> Content-Type: text/plain;charset=utf-8
> Transfer-Encoding: chunked
> Server: Jetty(10.0.21)
> 8
> Chunk 1
> 8
> Chunk 2
> 8
> Chunk 3
> 8
> Chunk 4
> 8
> Chunk 5
> {code}
> Here there is no closing 0 marker. As a result clients can recognise the
> error. (Curl will report "curl: (18) transfer closed with outstanding read
> data remaining", Chrome "Failed to load resource:
> net::ERR_INCOMPLETE_CHUNKED_ENCODING")
> CXF should do the same and not end the chunked stream regularly, when an
> exception is thrown.
> I have tested with Tomcat and Jetty. Both show the same behaviour.
> To provide some detail, Exceptions are caught by CXF here:
> org/apache/cxf/phase/PhaseInterceptorChain.java:328
> {code:java}
> } catch (RuntimeException ex) {
> if (!faultOccurred) {
> faultOccurred = true;
> wrapExceptionAsFault(message, ex);
> }
> state = State.ABORTED;
> }
> {code}
> The exception is logged, but not rethrown.
> If the exception would be thrown, for instance Tomcats ErrorReportValve would
> shut down the output and thereby prevent the end of the input and closing 0
> to be written.
> org/apache/catalina/valves/ErrorReportValve.java:112
> {code:java}
>
[jira] [Created] (CXF-9062) Be able to create AsyncHTTPConduit based on URLConnectionHTTPConduit
Freeman Yue Fang created CXF-9062: - Summary: Be able to create AsyncHTTPConduit based on URLConnectionHTTPConduit Key: CXF-9062 URL: https://issues.apache.org/jira/browse/CXF-9062 Project: CXF Issue Type: Improvement Reporter: Freeman Yue Fang When system property "org.apache.cxf.transport.http.forceURLConnection" is true, we should create AsyncHTTPConduit based on the original URLConnectionHTTPConduit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-9062) Be able to create AsyncHTTPConduit based on URLConnectionHTTPConduit
[ https://issues.apache.org/jira/browse/CXF-9062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang reassigned CXF-9062: - Assignee: Freeman Yue Fang > Be able to create AsyncHTTPConduit based on URLConnectionHTTPConduit > > > Key: CXF-9062 > URL: https://issues.apache.org/jira/browse/CXF-9062 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > > When system property "org.apache.cxf.transport.http.forceURLConnection" is > true, we should create AsyncHTTPConduit based on the original > URLConnectionHTTPConduit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9056) NTML Login ends up with Authorization loop detected after upgrading CXF from 3.5 to 3.6
[
https://issues.apache.org/jira/browse/CXF-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886093#comment-17886093
]
Alexander Suter commented on CXF-9056:
--
Hello [~ffang]
Thanks. Yes, you are right. By setting this property it works again.
The bad thing in my environment is that I've the hc (async) jar on my
classpath. Even if I disable ASYNC_HTTP the HTTPConduit will be created by the
hc jar
{code:java}
// HTTPTransportFactory
HTTPConduitFactory factory = findFactory(endpointInfo, bus);
HTTPConduit conduit = null;
if (factory != null) {
conduit = factory.createConduit(this, bus, endpointInfo, target);
}
if (conduit == null) {
if (forceURLConnectionConduit) {
conduit = new URLConnectionHTTPConduit(bus, endpointInfo, target);
} else {
conduit = new HttpClientHTTPConduit(bus, endpointInfo, target);
}
} {code}
> NTML Login ends up with Authorization loop detected after upgrading CXF from
> 3.5 to 3.6
> ---
>
> Key: CXF-9056
> URL: https://issues.apache.org/jira/browse/CXF-9056
> Project: CXF
> Issue Type: Bug
>Reporter: Alexander Suter
>Priority: Major
> Attachments: stacktrace.txt
>
>
> After upgrading cxf from 3.5 to 3.6 we can no longer authenticate with NTLM
> with CXF as web service client technology.
>
> We do support two modes in our product. With Challenge and without challenge.
> And the case without challenge (challenge = false) is no longer working
> whereas the authentication will be set on the httpConduit directly.
>
> {code:java}
> public class NTLMAuthenticationFeature implements WebServiceClientFeature {
>
> @Override
> public void initialize(WebServiceClientFeatureContext context) {
>BindingProvider bindingProvider = context.getBindingProvider();
>WsProps props = new WsProps(context.getProperties());
>Client proxy = ClientProxy.getClient(bindingProvider);
>
>boolean challenge =
> props.bool(Authentication.NTLM.CHALLENGE).orElse(Boolean.TRUE);
>proxy.getRequestContext().put(AsyncHTTPConduit.USE_ASYNC, challenge);
>var credentials = createNTCredentials(props);
>if (challenge) {
> proxy.getRequestContext().put(Credentials.class.getName(), credentials);
>}
> Conduit conduit = proxy.getConduit();
> if (conduit instanceof HTTPConduit httpConduit) {
> httpConduit.getClient().setAutoRedirect(true);
> }
> if (!challenge) {
>// this does no longer work
>httpConduit.getClient().setAllowChunking(false);
>setNtlmAuthHeader(credentials, httpConduit);
> }
> }
> private void setNtlmAuthHeader(NTCredentials credentials, HTTPConduit
> httpConduit) {
> var auth = httpConduit.getAuthorization();
> auth.setAuthorizationType("NTLM");
> auth.setUserName(credentials.getUserPrincipal().getName());
> auth.setPassword(credentials.getPassword());
> }
> private static NTCredentials createNTCredentials(WsProps properties) {
> var username = properties.string(Authentication.USERNAME);
> var password = properties.string(Authentication.PASSWORD);
> var workstation = properties.string(Authentication.NTLM.WORKSTATION);
> var domain = properties.string(Authentication.NTLM.DOMAIN);
> return new NTCredentials(username, password, workstation, domain);
> }
> private static record WsProps(Map props) {
>
> String string(String key) {
>
> return Optional.ofNullable(props.get(key))
> .map(String.class::cast)
> .orElse(null);
>
> Optional bool(String key) {
> return Optional.ofNullable(props.get(key))
> .map(String.class::cast)
> .filter(Predicate.not(String::isBlank))
> .map(Boolean::parseBoolean);
> }
> }
> } {code}
>
> See the error stack trace in the log.
> Do you have any hints for this problem?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8828) Support Jakarta EE 11
[ https://issues.apache.org/jira/browse/CXF-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8828: -- Description: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/09/04/hibernate-validator-9-0-0-Beta3/] [)|https://in.relation.to/2024/08/01/hibernate-validator-9-0-0-Beta2/)] - Hibernate 7 ([https://in.relation.to/2024/08/01/orm-70-beta1/]) - Hibernate Validator 9 (https://in.relation.to/2024/09/04/hibernate-validator-9-0-0-Beta3/) - MicroProfile OpenAPI 4.0 ([https://github.com/eclipse/microprofile-open-api/releases/tag/4.0.1), https://github.com/apache/cxf/pull/2078] - [MicroProfile Rest Client|https://download.eclipse.org/microprofile/microprofile-rest-client-4.0-RC1/microprofile-rest-client-spec-4.0-RC1.pdf] 4.0 ([https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0|https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0-RC1], [https://github.com/apache/cxf/pull/2028]) Of interests: - [https://microprofile.io/2024/08/22/microprofile-7-0-release/|https://microprofile.io/2024/08/22/microprofile-7-0-release/#sidebar] was: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld
[jira] [Updated] (CXF-8828) Support Jakarta EE 11
[ https://issues.apache.org/jira/browse/CXF-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8828: -- Description: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/09/04/hibernate-validator-9-0-0-Beta3/] [)|https://in.relation.to/2024/08/01/hibernate-validator-9-0-0-Beta2/)] - Hibernate 7 ([https://in.relation.to/2024/08/01/orm-70-beta1/]) - Hibernate Validator 9 (https://in.relation.to/2024/09/04/hibernate-validator-9-0-0-Beta3/) - MicroProfile OpenAPI 4.0 ([https://github.com/eclipse/microprofile-open-api/releases/tag/4.0.1), https://github.com/apache/cxf/pull/2078] - [MicroProfile Rest Client|https://download.eclipse.org/microprofile/microprofile-rest-client-4.0-RC1/microprofile-rest-client-spec-4.0-RC1.pdf] 4.0 ([https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0|https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0-RC1], [https://github.com/apache/cxf/pull/2028]) Of interests: - [https://microprofile.io/2024/08/22/microprofile-7-0-release/|https://microprofile.io/2024/08/22/microprofile-7-0-release/#sidebar] was: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld
[jira] [Commented] (CXF-9056) NTML Login ends up with Authorization loop detected after upgrading CXF from 3.5 to 3.6
[
https://issues.apache.org/jira/browse/CXF-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885955#comment-17885955
]
Freeman Yue Fang commented on CXF-9056:
---
Hi [~alexandersuter],
This is probably caused by the in-jdk http client used in HttpConduit
introduced by CXF 3.6.x.
Could you please test with java system property
"org.apache.cxf.transport.http.forceURLConnection" as "true" to switch back to
use old HttpConduit to see if this helps?
Best Regards
Freeman
> NTML Login ends up with Authorization loop detected after upgrading CXF from
> 3.5 to 3.6
> ---
>
> Key: CXF-9056
> URL: https://issues.apache.org/jira/browse/CXF-9056
> Project: CXF
> Issue Type: Bug
>Reporter: Alexander Suter
>Priority: Major
> Attachments: stacktrace.txt
>
>
> After upgrading cxf from 3.5 to 3.6 we can no longer authenticate with NTLM
> with CXF as web service client technology.
>
> We do support two modes in our product. With Challenge and without challenge.
> And the case without challenge (challenge = false) is no longer working
> whereas the authentication will be set on the httpConduit directly.
>
> {code:java}
> public class NTLMAuthenticationFeature implements WebServiceClientFeature {
>
> @Override
> public void initialize(WebServiceClientFeatureContext context) {
>BindingProvider bindingProvider = context.getBindingProvider();
>WsProps props = new WsProps(context.getProperties());
>Client proxy = ClientProxy.getClient(bindingProvider);
>
>boolean challenge =
> props.bool(Authentication.NTLM.CHALLENGE).orElse(Boolean.TRUE);
>proxy.getRequestContext().put(AsyncHTTPConduit.USE_ASYNC, challenge);
>var credentials = createNTCredentials(props);
>if (challenge) {
> proxy.getRequestContext().put(Credentials.class.getName(), credentials);
>}
> Conduit conduit = proxy.getConduit();
> if (conduit instanceof HTTPConduit httpConduit) {
> httpConduit.getClient().setAutoRedirect(true);
> }
> if (!challenge) {
>// this does no longer work
>httpConduit.getClient().setAllowChunking(false);
>setNtlmAuthHeader(credentials, httpConduit);
> }
> }
> private void setNtlmAuthHeader(NTCredentials credentials, HTTPConduit
> httpConduit) {
> var auth = httpConduit.getAuthorization();
> auth.setAuthorizationType("NTLM");
> auth.setUserName(credentials.getUserPrincipal().getName());
> auth.setPassword(credentials.getPassword());
> }
> private static NTCredentials createNTCredentials(WsProps properties) {
> var username = properties.string(Authentication.USERNAME);
> var password = properties.string(Authentication.PASSWORD);
> var workstation = properties.string(Authentication.NTLM.WORKSTATION);
> var domain = properties.string(Authentication.NTLM.DOMAIN);
> return new NTCredentials(username, password, workstation, domain);
> }
> private static record WsProps(Map props) {
>
> String string(String key) {
>
> return Optional.ofNullable(props.get(key))
> .map(String.class::cast)
> .orElse(null);
>
> Optional bool(String key) {
> return Optional.ofNullable(props.get(key))
> .map(String.class::cast)
> .filter(Predicate.not(String::isBlank))
> .map(Boolean::parseBoolean);
> }
> }
> } {code}
>
> See the error stack trace in the log.
> Do you have any hints for this problem?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9035) Fix java.util.ConcurrentModificationException at org.apache.cxf.message.MessageImpl.calcContextCache
[
https://issues.apache.org/jira/browse/CXF-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885876#comment-17885876
]
Christian Mattar commented on CXF-9035:
---
IMHO the correct fix would be to properly synchronize interceptor execution, so
that they behave the same as in the non-local transport case.
> Fix java.util.ConcurrentModificationException at
> org.apache.cxf.message.MessageImpl.calcContextCache
>
>
> Key: CXF-9035
> URL: https://issues.apache.org/jira/browse/CXF-9035
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.8, 3.6.3, 4.0.4
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.10, 3.6.5, 4.0.6
>
>
> {noformat}
> org.apache.cxf.jaxrs.client.logging.RESTLoggingTest.testBinary
> Failing for the past 1 build (Since
> #1182 )
> Took 22 ms.
> Error MessageProblem with reading the data, class java.io.InputStream,
> ContentType:
> application/octet-stream.Stacktracejakarta.ws.rs.client.ResponseProcessingException:
> Problem with reading the data, class java.io.InputStream, ContentType:
> application/octet-stream.
> at
> org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:553)
> at
> org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:495)
> at
> org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:566)
> at
> org.apache.cxf.jaxrs.client.WebClient.handleResponse(WebClient.java:1172)
> at org.apache.cxf.jaxrs.client.WebClient.doResponse(WebClient.java:1160)
> at
> org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:1086)
> at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:931)
> at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:900)
> at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:460)
> at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:640)
> at
> org.apache.cxf.jaxrs.client.logging.RESTLoggingTest.testBinary(RESTLoggingTest.java:70)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:316)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.util.ConcurrentModificationException
> at java.base/java.util.HashMap$HashIterator.nextNode(HashMap.java:1605)
> at java.base/java.
[jira] [Commented] (CXF-9035) Fix java.util.ConcurrentModificationException at org.apache.cxf.message.MessageImpl.calcContextCache
[
https://issues.apache.org/jira/browse/CXF-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885874#comment-17885874
]
Christian Mattar commented on CXF-9035:
---
The LoggingFeature is installing
{{org.apache.cxf.ext.logging.LoggingInInterceptor}}
which does this:
{noformat}
message.put(LIVE_LOGGING_PROP, Boolean.FALSE);{noformat}
The LocalConduit, which is used here, uses some kind of Multi-Threading setup
to run the Interceptors concurrently to normal message processing.
This leads to the exception you are seeing.
There's some explicit checking in LocalConduit to not run them using a
synchronous executor. Doing so deadlocks the message processing.
> Fix java.util.ConcurrentModificationException at
> org.apache.cxf.message.MessageImpl.calcContextCache
>
>
> Key: CXF-9035
> URL: https://issues.apache.org/jira/browse/CXF-9035
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.8, 3.6.3, 4.0.4
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.5.10, 3.6.5, 4.0.6
>
>
> {noformat}
> org.apache.cxf.jaxrs.client.logging.RESTLoggingTest.testBinary
> Failing for the past 1 build (Since
> #1182 )
> Took 22 ms.
> Error MessageProblem with reading the data, class java.io.InputStream,
> ContentType:
> application/octet-stream.Stacktracejakarta.ws.rs.client.ResponseProcessingException:
> Problem with reading the data, class java.io.InputStream, ContentType:
> application/octet-stream.
> at
> org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:553)
> at
> org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:495)
> at
> org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:566)
> at
> org.apache.cxf.jaxrs.client.WebClient.handleResponse(WebClient.java:1172)
> at org.apache.cxf.jaxrs.client.WebClient.doResponse(WebClient.java:1160)
> at
> org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:1086)
> at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:931)
> at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:900)
> at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:460)
> at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:640)
> at
> org.apache.cxf.jaxrs.client.logging.RESTLoggingTest.testBinary(RESTLoggingTest.java:70)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:316)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:
[jira] [Comment Edited] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885612#comment-17885612 ] Andriy Redko edited comment on CXF-7396 at 9/28/24 8:20 PM: In some edge cases, the CachedOutputStream instances may not be closed and, if backed by temporary files, may fill up the file system (it applies to servers and clients). *As a workaround,* the CachedOutputStreamCleaner bus extension could be used to provide the custom cleaning mechanism for such dangling cached streams (by default, the extension is implemented by DelayedCachedOutputStreamCleaner and run periodic cleanup set by bus.io.CachedOutputStreamCleaner.Delay bus property, which is set to 30 mins by default). Documentation: https://cwiki.apache.org/confluence/display/CXF20DOC/Securing+CXF+Services#SecuringCXFServices-Largedatastreamcaching was (Author: reta): In some edge cases, the CachedOutputStream instances may not be closed and, if backed by temporary files, may fill up the file system (it applies to servers and clients). *As a workaround,* the CachedOutputStreamCleaner bus extension could be used to provide the custom cleaning mechanism for such dangling cached streams (by default, the extension is implemented by DelayedCachedOutputStreamCleaner and run periodic cleanup set by bus.io.CachedOutputStreamCleaner.Delay bus property, 30 mins by default). Documentation: https://cwiki.apache.org/confluence/display/CXF20DOC/Securing+CXF+Services#SecuringCXFServices-Largedatastreamcaching > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.5.10, 3.6.5, 4.0.6 > > Attachments: HTTP Request.jmx, Screenshot 2020-05-05 at 10.09.43.png, > Screenshot 2020-05-12 at 12.42.11.png, image-2018-05-29-13-58-03-109.png, > image-2018-05-29-14-00-16-442.png, image-2018-05-29-14-00-54-215.png > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885612#comment-17885612 ] Andriy Redko commented on CXF-7396: --- In some edge cases, the CachedOutputStream instances may not be closed and, if backed by temporary files, may fill up the file system (it applies to servers and clients). *As a workaround,* the CachedOutputStreamCleaner bus extension could be used to provide the custom cleaning mechanism for such dangling cached streams (by default, the extension is implemented by DelayedCachedOutputStreamCleaner and run periodic cleanup set by bus.io.CachedOutputStreamCleaner.Delay bus property, 30 mins by default). Documentation: https://cwiki.apache.org/confluence/display/CXF20DOC/Securing+CXF+Services#SecuringCXFServices-Largedatastreamcaching > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.5.10, 3.6.5, 4.0.6 > > Attachments: HTTP Request.jmx, Screenshot 2020-05-05 at 10.09.43.png, > Screenshot 2020-05-12 at 12.42.11.png, image-2018-05-29-13-58-03-109.png, > image-2018-05-29-14-00-16-442.png, image-2018-05-29-14-00-54-215.png > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-7396. --- Resolution: Fixed > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.5.10, 3.6.5, 4.0.6 > > Attachments: HTTP Request.jmx, Screenshot 2020-05-05 at 10.09.43.png, > Screenshot 2020-05-12 at 12.42.11.png, image-2018-05-29-13-58-03-109.png, > image-2018-05-29-14-00-16-442.png, image-2018-05-29-14-00-54-215.png > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8828) Support Jakarta EE 11
[ https://issues.apache.org/jira/browse/CXF-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8828: -- Description: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/09/04/hibernate-validator-9-0-0-Beta3/] [)|https://in.relation.to/2024/08/01/hibernate-validator-9-0-0-Beta2/)] - Hibernate 7 ([https://in.relation.to/2024/08/01/orm-70-beta1/]) - MicroProfile OpenAPI 4.0 ([https://github.com/eclipse/microprofile-open-api/releases/tag/4.0.1), https://github.com/apache/cxf/pull/2078] - [MicroProfile Rest Client|https://download.eclipse.org/microprofile/microprofile-rest-client-4.0-RC1/microprofile-rest-client-spec-4.0-RC1.pdf] 4.0 ([https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0|https://github.com/eclipse/microprofile-rest-client/releases/tag/4.0-RC1], [https://github.com/apache/cxf/pull/2028]) Of interests: - [https://microprofile.io/2024/08/22/microprofile-7-0-release/|https://microprofile.io/2024/08/22/microprofile-7-0-release/#sidebar] was: Support Jakarta EE 11 ([https://jakarta.ee/specifications/platform/11/]) Minimum JDK requirement - JDK-17 Specs updates: * [Jakarta Validation 3.1 (|https://jakarta.ee/specifications/bean-validation/3.1/] [https://github.com/apache/cxf/pull/1889)] * Jakarta Persistence 3.2 ([https://github.com/apache/cxf/pull/1891, |https://github.com/apache/cxf/pull/1891] [https://jakarta.ee/specifications/persistence/3.2/)|https://jakarta.ee/specifications/persistence/3.2/] * Jakarta Annotations 3.0 ([https://jakarta.ee/specifications/annotations/3.0/)] * Jakarta Authorization 3.0 ([https://jakarta.ee/specifications/authorization/3.0/)] * Jakarta Contexts and Dependency Injection 4.1 ([https://jakarta.ee/specifications/cdi/4.1/)] * Jakarta Expression Language 6.0 ([https://jakarta.ee/specifications/expression-language/6.0/)] * Jakarta Interceptors 2.2 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta RESTful Web Services 4.0 ([https://jakarta.ee/specifications/restful-ws/4.0/)] * Jakarta Validation 3.1 ([https://jakarta.ee/specifications/bean-validation/3.1/]) * Jakarta WebSocket 2.2 ([https://jakarta.ee/specifications/websocket/2.2/]) * Jakarta Concurrency 3.1 ([https://jakarta.ee/specifications/concurrency/3.1/)] * Jakarta Data 1.0 ([https://jakarta.ee/specifications/data/1.0/)] * Jakarta Faces 4.1 ([https://jakarta.ee/specifications/faces/4.1/)] * Jakarta Pages 4.0 ([https://jakarta.ee/specifications/pages/4.0/)] * Jakarta Servlet 6.1 ([https://jakarta.ee/specifications/servlet/6.1/]) * Jakarta Authentication 3.0 ([https://jakarta.ee/specifications/authentication/3.1/]) * Jakarta Security 4.0 ([https://jakarta.ee/specifications/security/4.0/]) Updates required: - Tomcat 11 ([https://www.mail-archive.com/announce@apache.org/msg07789.html]) - Arquillian Weld Container 4.x ([https://github.com/apache/cxf/pull/1621]) - Apache ActiveMQ 6 ([https
[jira] [Commented] (CXF-8903) Too many open files error in HttpClientHTTPConduit
[
https://issues.apache.org/jira/browse/CXF-8903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883853#comment-17883853
]
Christian Habermehl commented on CXF-8903:
--
It should be this commit:
[https://github.com/apache/cxf/commit/3d70de80fb60b74040c0214fc6a28774362556e4]
> Too many open files error in HttpClientHTTPConduit
> --
>
> Key: CXF-8903
> URL: https://issues.apache.org/jira/browse/CXF-8903
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.2
>Reporter: Jim Ma
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.6.2, 4.0.3, 4.1.0
>
>
> It seems there is resource leak in HttpClientHTTPConduit. When upgrade CXF to
> 4.0.2, the "lsof" shows there are many files open since it is changed to use
> JDK's HTTPClient.
> {code:java}
> Caused by: java.lang.InternalError: java.io.IOException: Too many open files
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.(HttpClientImpl.java:311)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.create(HttpClientImpl.java:253)
> at
> java.net.http/jdk.internal.net.http.HttpClientBuilderImpl.build(HttpClientBuilderImpl.java:135)
> at
> org.apache.cxf.impl//org.apache.cxf.transport.http.HttpClientHTTPConduit.setupConnection(HttpClientHTTPConduit.java:231)
> at
> org.apache.cxf.impl//org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit.setupConnection(AsyncHTTPConduit.java:190)
> at
> org.apache.cxf.impl//org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:529)
> at
> org.apache.cxf@4.0.2//org.apache.cxf.transport.TransportURIResolver.resolve(TransportURIResolver.java:133)
> at
> org.apache.cxf@4.0.2//org.apache.cxf.catalog.CatalogXmlSchemaURIResolver.resolveEntity(CatalogXmlSchemaURIResolver.java:66)
> at
> org.apache.ws.xmlschema//org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:682)
> at
> org.apache.ws.xmlschema//org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:536)
> at
> org.apache.ws.xmlschema//org.apache.ws.commons.schema.SchemaBuilder.handleSchemaElementChild(SchemaBuilder.java:1524)
> at
> org.apache.ws.xmlschema//org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:656)
> at
> org.apache.ws.xmlschema//org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:551)
> at
> org.apache.cxf@4.0.2//org.apache.cxf.common.xmlschema.SchemaCollection.read(SchemaCollection.java:129)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.SchemaUtil.extractSchema(SchemaUtil.java:145)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.SchemaUtil.getSchemas(SchemaUtil.java:74)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.SchemaUtil.getSchemas(SchemaUtil.java:66)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.SchemaUtil.getSchemas(SchemaUtil.java:61)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.WSDLServiceBuilder.getSchemas(WSDLServiceBuilder.java:378)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:345)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:209)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.WSDLServiceFactory.create(WSDLServiceFactory.java:161)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:407)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> at
> org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> at
> org.apache.cxf.impl//org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:466)
> at
> org.jboss.ws.jaxws-client@7.0.0-SNAPSHOT//org.jboss.wsf.stack.cxf.client.ProviderImpl$JBossWSServiceImpl.createPort(ProviderImpl.java:580)
> at
> org.apache.cxf.impl//org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:342)
> at
> org.apache.cxf.impl//org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:337)
> at
> jakarta.xml.ws.api@1.0.0.Final//jakarta.xml.ws.Service.getPort(Servi
[jira] [Assigned] (CXF-9061) Update documentation to use Jakarta namespaces as well (where appropriate)
[ https://issues.apache.org/jira/browse/CXF-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reassigned CXF-9061: - Assignee: Andriy Redko > Update documentation to use Jakarta namespaces as well (where appropriate) > -- > > Key: CXF-9061 > URL: https://issues.apache.org/jira/browse/CXF-9061 > Project: CXF > Issue Type: Bug >Affects Versions: 4.0.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 4.0.6 > > > For 4.0.x release, most of XML namespaces have to be switched to Jakarta > equivalent ones but our documentation still refers to Java EE mostly > everywhere (see please https://issues.apache.org/jira/browse/CXF-9058). We > have to update the documentation to show off both options, see please an > example of recently fixed documentation here: > https://cwiki.apache.org/confluence/display/CXF20DOC/WSDL+to+Java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9061) Update documentation to use Jakarta namespaces as well (where appropriate)
[ https://issues.apache.org/jira/browse/CXF-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9061: -- Summary: Update documentation to use Jakarta namespaces as well (where appropriate) (was: Update documentation to use Jakarta namespaces where appropriate) > Update documentation to use Jakarta namespaces as well (where appropriate) > -- > > Key: CXF-9061 > URL: https://issues.apache.org/jira/browse/CXF-9061 > Project: CXF > Issue Type: Bug >Affects Versions: 4.0.5 >Reporter: Andriy Redko >Priority: Major > Fix For: 4.1.0, 4.0.6 > > > For 4.0.x release, most of XML namespaces have to be switched to Jakarta > equivalent ones but our documentation still refers to Java EE mostly > everywhere (see please https://issues.apache.org/jira/browse/CXF-9058). We > have to update the documentation to show off both options, see please an > example of recently fixed documentation here: > https://cwiki.apache.org/confluence/display/CXF20DOC/WSDL+to+Java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-9058) jaxws binding example in documentation no more work in v4.x because of jarkarta
[
https://issues.apache.org/jira/browse/CXF-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9058.
---
Resolution: Fixed
> jaxws binding example in documentation no more work in v4.x because of
> jarkarta
> ---
>
> Key: CXF-9058
> URL: https://issues.apache.org/jira/browse/CXF-9058
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5
>Reporter: Mathieu CARBONNEAUX
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> in cxf wsdl2java documentation :
> [https://cxf.apache.org/docs/wsdl-to-java.html]
>
> You have the ability to use JAXWS binding file to customise wsdl2java
> generation to enable enableWrapperStyle:
>
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://java.sun.com/xml/ns/jaxws"
>xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";>
>false
> {code}
>
> and i got this error :
> {noformat}
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace{noformat}
> but with v4.x cxf had upgraded to jakarta and now we need to change
> namespace:
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://jakarta.ee/xml/ns/jaxws"
>xmlns:jaxws="http://jakarta.ee/xml/ns/jaxws";>
>false
> {code}
> we need to change java.sun.com to jakarta.ee and add version="3.0".
>
> can you modify documentation to explain the difference between <4.x and >=4.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9061) Update documentation to use Jakarta namespaces where appropriate
[ https://issues.apache.org/jira/browse/CXF-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9061: -- Description: For 4.0.x release, most of XML namespaces have to be switched to Jakarta equivalent ones but our documentation still refers to Java EE mostly everywhere (see please https://issues.apache.org/jira/browse/CXF-9058). We have to update the documentation to show off both options, see please an example of recently fixed documentation here: https://cwiki.apache.org/confluence/display/CXF20DOC/WSDL+to+Java > Update documentation to use Jakarta namespaces where appropriate > > > Key: CXF-9061 > URL: https://issues.apache.org/jira/browse/CXF-9061 > Project: CXF > Issue Type: Bug >Affects Versions: 4.0.5 >Reporter: Andriy Redko >Priority: Major > Fix For: 4.1.0, 4.0.6 > > > For 4.0.x release, most of XML namespaces have to be switched to Jakarta > equivalent ones but our documentation still refers to Java EE mostly > everywhere (see please https://issues.apache.org/jira/browse/CXF-9058). We > have to update the documentation to show off both options, see please an > example of recently fixed documentation here: > https://cwiki.apache.org/confluence/display/CXF20DOC/WSDL+to+Java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9061) Update documentation to use Jakarta namespaces where appropriate
[ https://issues.apache.org/jira/browse/CXF-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9061: -- Fix Version/s: 4.1.0 4.0.6 > Update documentation to use Jakarta namespaces where appropriate > > > Key: CXF-9061 > URL: https://issues.apache.org/jira/browse/CXF-9061 > Project: CXF > Issue Type: Bug >Affects Versions: 4.0.5 >Reporter: Andriy Redko >Priority: Major > Fix For: 4.1.0, 4.0.6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9061) Update documentation to use Jakarta namespaces where appropriate
[ https://issues.apache.org/jira/browse/CXF-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9061: -- Affects Version/s: 4.0.5 > Update documentation to use Jakarta namespaces where appropriate > > > Key: CXF-9061 > URL: https://issues.apache.org/jira/browse/CXF-9061 > Project: CXF > Issue Type: Bug >Affects Versions: 4.0.5 >Reporter: Andriy Redko >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9058) jaxws binding example in documentation no more work in v4.x because of jarkarta
[
https://issues.apache.org/jira/browse/CXF-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883517#comment-17883517
]
Andriy Redko commented on CXF-9058:
---
Updated https://cwiki.apache.org/confluence/display/CXF20DOC/WSDL+to+Java with
3.6.x and 4.0.x variants
> jaxws binding example in documentation no more work in v4.x because of
> jarkarta
> ---
>
> Key: CXF-9058
> URL: https://issues.apache.org/jira/browse/CXF-9058
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5
>Reporter: Mathieu CARBONNEAUX
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> in cxf wsdl2java documentation :
> [https://cxf.apache.org/docs/wsdl-to-java.html]
>
> You have the ability to use JAXWS binding file to customise wsdl2java
> generation to enable enableWrapperStyle:
>
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://java.sun.com/xml/ns/jaxws"
>xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";>
>false
> {code}
>
> and i got this error :
> {noformat}
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace{noformat}
> but with v4.x cxf had upgraded to jakarta and now we need to change
> namespace:
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://jakarta.ee/xml/ns/jaxws"
>xmlns:jaxws="http://jakarta.ee/xml/ns/jaxws";>
>false
> {code}
> we need to change java.sun.com to jakarta.ee and add version="3.0".
>
> can you modify documentation to explain the difference between <4.x and >=4.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-9061) Update documentation to use Jakarta namespaces where appropriate
Andriy Redko created CXF-9061: - Summary: Update documentation to use Jakarta namespaces where appropriate Key: CXF-9061 URL: https://issues.apache.org/jira/browse/CXF-9061 Project: CXF Issue Type: Bug Reporter: Andriy Redko -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9059.
---
Resolution: Fixed
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.0.5, 3.6.4
>Reporter: Jamie Mark Goodyear
>Assignee: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0, 3.6.5, 4.0.6
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> The key issue being addressed here is ephemeral port usage. Once all
> available ports are in use, the clients are unable to send more messages.
> Controlling ephemeral port usage means the client can more often send
> messages to the server-side.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {. os.flush(); }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9060) WSDL2Java Service generation results in 'unused import' warnings
[
https://issues.apache.org/jira/browse/CXF-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9060.
---
Resolution: Fixed
> WSDL2Java Service generation results in 'unused import' warnings
>
>
> Key: CXF-9060
> URL: https://issues.apache.org/jira/browse/CXF-9060
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.5
>Reporter: Andrew Gibb
>Priority: Minor
> Fix For: 4.1.0, 3.6.5, 4.0.6
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> After the fix for CXF-9011 there are now "unused import" warnings for
> {{java.net.URI}} in some generated Services. This is because the
> {{URI.create(...).toUrl()}} is only used in some scenarios.
>
> There is already a conditional check in the {{service.vm}} template around
> the import for {{java.net.MalformedURLException}} which is used in the same
> scenario when creating the URL so I believe the import for {{java.net.URI}}
> belongs in there as well.
>
> I have tested the conditional import and will submit a pull request
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9060) WSDL2Java Service generation results in 'unused import' warnings
[
https://issues.apache.org/jira/browse/CXF-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9060:
--
Fix Version/s: 3.6.5
> WSDL2Java Service generation results in 'unused import' warnings
>
>
> Key: CXF-9060
> URL: https://issues.apache.org/jira/browse/CXF-9060
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.5
>Reporter: Andrew Gibb
>Priority: Minor
> Fix For: 4.1.0, 3.6.5, 4.0.6
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> After the fix for CXF-9011 there are now "unused import" warnings for
> {{java.net.URI}} in some generated Services. This is because the
> {{URI.create(...).toUrl()}} is only used in some scenarios.
>
> There is already a conditional check in the {{service.vm}} template around
> the import for {{java.net.MalformedURLException}} which is used in the same
> scenario when creating the URL so I believe the import for {{java.net.URI}}
> belongs in there as well.
>
> I have tested the conditional import and will submit a pull request
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-9059:
-
Assignee: Jamie Mark Goodyear
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.0.5, 3.6.4
>Reporter: Jamie Mark Goodyear
>Assignee: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0, 3.6.5, 4.0.6
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> The key issue being addressed here is ephemeral port usage. Once all
> available ports are in use, the clients are unable to send more messages.
> Controlling ephemeral port usage means the client can more often send
> messages to the server-side.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {. os.flush(); }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9059:
--
Fix Version/s: 3.6.5
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.0.5, 3.6.4
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0, 3.6.5, 4.0.6
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> The key issue being addressed here is ephemeral port usage. Once all
> available ports are in use, the clients are unable to send more messages.
> Controlling ephemeral port usage means the client can more often send
> messages to the server-side.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {. os.flush(); }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9059:
--
Fix Version/s: 4.0.6
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.1.0
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> The key issue being addressed here is ephemeral port usage. Once all
> available ports are in use, the clients are unable to send more messages.
> Controlling ephemeral port usage means the client can more often send
> messages to the server-side.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {. os.flush(); }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9059:
--
Affects Version/s: 3.6.4
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.0.5, 3.6.4
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> The key issue being addressed here is ephemeral port usage. Once all
> available ports are in use, the clients are unable to send more messages.
> Controlling ephemeral port usage means the client can more often send
> messages to the server-side.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {. os.flush(); }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9059:
--
Affects Version/s: 4.0.5
(was: 4.1.0)
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.0.5
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> The key issue being addressed here is ephemeral port usage. Once all
> available ports are in use, the clients are unable to send more messages.
> Controlling ephemeral port usage means the client can more often send
> messages to the server-side.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {. os.flush(); }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9060) WSDL2Java Service generation results in 'unused import' warnings
[
https://issues.apache.org/jira/browse/CXF-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9060:
--
Fix Version/s: 4.1.0
4.0.6
> WSDL2Java Service generation results in 'unused import' warnings
>
>
> Key: CXF-9060
> URL: https://issues.apache.org/jira/browse/CXF-9060
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.5
>Reporter: Andrew Gibb
>Priority: Minor
> Fix For: 4.1.0, 4.0.6
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> After the fix for CXF-9011 there are now "unused import" warnings for
> {{java.net.URI}} in some generated Services. This is because the
> {{URI.create(...).toUrl()}} is only used in some scenarios.
>
> There is already a conditional check in the {{service.vm}} template around
> the import for {{java.net.MalformedURLException}} which is used in the same
> scenario when creating the URL so I believe the import for {{java.net.URI}}
> belongs in there as well.
>
> I have tested the conditional import and will submit a pull request
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-9060) WSDL2Java Service generation results in 'unused import' warnings
Andrew Gibb created CXF-9060:
Summary: WSDL2Java Service generation results in 'unused import'
warnings
Key: CXF-9060
URL: https://issues.apache.org/jira/browse/CXF-9060
Project: CXF
Issue Type: Bug
Affects Versions: 4.0.5
Reporter: Andrew Gibb
After the fix for CXF-9011 there are now "unused import" warnings for
{{java.net.URI}} in some generated Services. This is because the
{{URI.create(...).toUrl()}} is only used in some scenarios.
There is already a conditional check in the {{service.vm}} template around the
import for {{java.net.MalformedURLException}} which is used in the same
scenario when creating the URL so I believe the import for {{java.net.URI}}
belongs in there as well.
I have tested the conditional import and will submit a pull request
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-9039) Run Jakarta RESTful Web Services 3.1 TCK
[ https://issues.apache.org/jira/browse/CXF-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883122#comment-17883122 ] Andriy Redko edited comment on CXF-9039 at 9/19/24 9:35 PM: Failing tests on initial run: * [ee.jakarta.tck.ws.rs.ee.rs.container.responsecontext.JAXRSClientIT.getEntityAnnotationsTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.container.responsecontext/JAXRSClientIT/getEntityAnnotationsTest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.response.JAXRSClientIT.responseCreatedRelativeURITest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.response/JAXRSClientIT/responseCreatedRelativeURITest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.responsebuilder.JAXRSClientIT.entityObjectTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.responsebuilder/JAXRSClientIT/entityObjectTest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo.JAXRSClientIT.getMatchedURIsTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo/JAXRSClientIT/getMatchedURIsTest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo.JAXRSClientIT.getMatchedURIsTest1|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo/JAXRSClientIT/getMatchedURIsTest1/] * [ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo.JAXRSClientIT.getMatchedURIsTest2|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo/JAXRSClientIT/getMatchedURIsTest2/] * [ee.jakarta.tck.ws.rs.ee.rs.ext.interceptor.containerwriter.interceptorcontext.JAXRSClientIT.getAnnotationsTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.ext.interceptor.containerwriter.interceptorcontext/JAXRSClientIT/getAnnotationsTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.ssebroadcaster.JAXRSClientIT.sseBroadcastTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.ssebroadcaster/JAXRSClientIT/sseBroadcastTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.stringTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/stringTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.streamingOutputTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/streamingOutputTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.fileTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/fileTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.closeTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/closeTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.inputstreamTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/inputstreamTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.readerTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/readerTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.transformSourceTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/transformSourceTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.multivaluedMapTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/multivaluedMapTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.jaxbElementTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/jaxbElementTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.sseStageCheckTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/sseStageCheckTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.doubleTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClie
[jira] [Commented] (CXF-9039) Run Jakarta RESTful Web Services 3.1 TCK
[ https://issues.apache.org/jira/browse/CXF-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883122#comment-17883122 ] Andriy Redko commented on CXF-9039: --- * [ee.jakarta.tck.ws.rs.ee.rs.container.responsecontext.JAXRSClientIT.getEntityAnnotationsTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.container.responsecontext/JAXRSClientIT/getEntityAnnotationsTest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.response.JAXRSClientIT.responseCreatedRelativeURITest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.response/JAXRSClientIT/responseCreatedRelativeURITest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.responsebuilder.JAXRSClientIT.entityObjectTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.responsebuilder/JAXRSClientIT/entityObjectTest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo.JAXRSClientIT.getMatchedURIsTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo/JAXRSClientIT/getMatchedURIsTest/] * [ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo.JAXRSClientIT.getMatchedURIsTest1|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo/JAXRSClientIT/getMatchedURIsTest1/] * [ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo.JAXRSClientIT.getMatchedURIsTest2|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.core.uriinfo/JAXRSClientIT/getMatchedURIsTest2/] * [ee.jakarta.tck.ws.rs.ee.rs.ext.interceptor.containerwriter.interceptorcontext.JAXRSClientIT.getAnnotationsTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.ee.rs.ext.interceptor.containerwriter.interceptorcontext/JAXRSClientIT/getAnnotationsTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.ssebroadcaster.JAXRSClientIT.sseBroadcastTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.ssebroadcaster/JAXRSClientIT/sseBroadcastTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.stringTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/stringTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.streamingOutputTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/streamingOutputTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.fileTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/fileTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.closeTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/closeTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.inputstreamTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/inputstreamTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.readerTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/readerTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.transformSourceTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/transformSourceTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.multivaluedMapTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/multivaluedMapTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.jaxbElementTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/jaxbElementTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.sseStageCheckTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/sseStageCheckTest/] * [ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink.JAXRSClientIT.doubleTest|https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/10/testReport/junit/ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.sseeventsink/JAXRSClientIT/doubleTest/] * [ee.jakarta.tck.ws.rs.jax
[jira] [Updated] (CXF-9038) Run Jakarta RESTful Web Services 3.0 TCK
[ https://issues.apache.org/jira/browse/CXF-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9038: -- Description: Run Jakarta RESTful Web Services 3.0 TCK (JakarteEE 9.1): https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.0-TCK Documentation: https://cwiki.apache.org/confluence/display/CXF20DOC/JakartaEE+TCKs#JakartaEETCKs-JakartaRESTfulWebServices3.0TCK was:Run Jakarta RESTful Web Services 3.0 TCK (JakarteEE 9.1): https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.0-TCK > Run Jakarta RESTful Web Services 3.0 TCK > > > Key: CXF-9038 > URL: https://issues.apache.org/jira/browse/CXF-9038 > Project: CXF > Issue Type: Improvement >Affects Versions: 4.0.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.6 > > > Run Jakarta RESTful Web Services 3.0 TCK (JakarteEE 9.1): > https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.0-TCK > Documentation: > https://cwiki.apache.org/confluence/display/CXF20DOC/JakartaEE+TCKs#JakartaEETCKs-JakartaRESTfulWebServices3.0TCK -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9039) Run Jakarta RESTful Web Services 3.1 TCK
[ https://issues.apache.org/jira/browse/CXF-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9039: -- Description: Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10). It seems like the Jakarta EE 10 jaxrs TCK is split between: - [https://github.com/jakartaee/rest/tree/3.1.0/jersey-tck] - [https://github.com/jakartaee/platform-tck/tree/10.0.5] Documentation: https://cwiki.apache.org/confluence/display/CXF20DOC/JakartaEE+TCKs#JakartaEETCKs-JakartaRESTfulWebServices3.1TCK was: Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10). It seems like the Jakarta EE 10 jaxrs TCK is split between: - [https://github.com/jakartaee/rest/tree/3.1.0/jersey-tck] - https://github.com/jakartaee/platform-tck/tree/10.0.5 > Run Jakarta RESTful Web Services 3.1 TCK > > > Key: CXF-9039 > URL: https://issues.apache.org/jira/browse/CXF-9039 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0 > > > Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10). > It seems like the Jakarta EE 10 jaxrs TCK is split between: > - [https://github.com/jakartaee/rest/tree/3.1.0/jersey-tck] > - [https://github.com/jakartaee/platform-tck/tree/10.0.5] > Documentation: > https://cwiki.apache.org/confluence/display/CXF20DOC/JakartaEE+TCKs#JakartaEETCKs-JakartaRESTfulWebServices3.1TCK -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9039) Run Jakarta RESTful Web Services 3.1 TCK
[ https://issues.apache.org/jira/browse/CXF-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883032#comment-17883032 ] Andriy Redko commented on CXF-9039: --- https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-3.1-TCK/ > Run Jakarta RESTful Web Services 3.1 TCK > > > Key: CXF-9039 > URL: https://issues.apache.org/jira/browse/CXF-9039 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0 > > > Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10). > It seems like the Jakarta EE 10 jaxrs TCK is split between: > - [https://github.com/jakartaee/rest/tree/3.1.0/jersey-tck] > - https://github.com/jakartaee/platform-tck/tree/10.0.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-9058) jaxws binding example in documentation no more work in v4.x because of jarkarta
[
https://issues.apache.org/jira/browse/CXF-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-9058:
-
Assignee: Andriy Redko
> jaxws binding example in documentation no more work in v4.x because of
> jarkarta
> ---
>
> Key: CXF-9058
> URL: https://issues.apache.org/jira/browse/CXF-9058
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5
>Reporter: Mathieu CARBONNEAUX
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> in cxf wsdl2java documentation :
> [https://cxf.apache.org/docs/wsdl-to-java.html]
>
> You have the ability to use JAXWS binding file to customise wsdl2java
> generation to enable enableWrapperStyle:
>
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://java.sun.com/xml/ns/jaxws"
>xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";>
>false
> {code}
>
> and i got this error :
> {noformat}
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace{noformat}
> but with v4.x cxf had upgraded to jakarta and now we need to change
> namespace:
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://jakarta.ee/xml/ns/jaxws"
>xmlns:jaxws="http://jakarta.ee/xml/ns/jaxws";>
>false
> {code}
> we need to change java.sun.com to jakarta.ee and add version="3.0".
>
> can you modify documentation to explain the difference between <4.x and >=4.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9058) jaxws binding example in documentation no more work in v4.x because of jarkarta
[
https://issues.apache.org/jira/browse/CXF-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-9058:
--
Fix Version/s: 4.1.0
4.0.6
> jaxws binding example in documentation no more work in v4.x because of
> jarkarta
> ---
>
> Key: CXF-9058
> URL: https://issues.apache.org/jira/browse/CXF-9058
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5
>Reporter: Mathieu CARBONNEAUX
>Priority: Major
> Fix For: 4.1.0, 4.0.6
>
>
> in cxf wsdl2java documentation :
> [https://cxf.apache.org/docs/wsdl-to-java.html]
>
> You have the ability to use JAXWS binding file to customise wsdl2java
> generation to enable enableWrapperStyle:
>
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://java.sun.com/xml/ns/jaxws"
>xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";>
>false
> {code}
>
> and i got this error :
> {noformat}
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace{noformat}
> but with v4.x cxf had upgraded to jakarta and now we need to change
> namespace:
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://jakarta.ee/xml/ns/jaxws"
>xmlns:jaxws="http://jakarta.ee/xml/ns/jaxws";>
>false
> {code}
> we need to change java.sun.com to jakarta.ee and add version="3.0".
>
> can you modify documentation to explain the difference between <4.x and >=4.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jamie Mark Goodyear updated CXF-9059:
-
Description:
HttpConduit should flush output stream ahead of closing connections when
HttpClient is autocloseable.
When running WebClient in a load test (single host) we'll observe low
throughput.
When we adjust the HttpConduit to flush output stream ahead of connection
close, we observe significant throughput improvement.
The key issue being addressed here is ephemeral port usage. Once all available
ports are in use, the clients are unable to send more messages.
Controlling ephemeral port usage means the client can more often send messages
to the server-side.
Given this appears to affect just autocloseable HttpClient, we select to flush
the output stead only when the JVM provides the autocloseable HttpClient
variety.
AbstractConduit:
finally {
OutputStream os = msg.getContent(OutputStream.class);
// Java 21 may hang on close, we flush stream to help close them out.
if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
{. os.flush(); }
super.close(msg);
}
was:
HttpConduit should flush output stream ahead of closing connections when
HttpClient is autocloseable.
When running WebClient in a load test (single host) we'll observe low
throughput.
When we adjust the HttpConduit to flush output stream ahead of connection
close, we observe significant throughput improvement.
Given this appears to affect just autocloseable HttpClient, we select to flush
the output stead only when the JVM provides the autocloseable HttpClient
variety.
AbstractConduit:
finally {
OutputStream os = msg.getContent(OutputStream.class);
// Java 21 may hang on close, we flush stream to help close them out.
if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
{.
os.flush();
}
super.close(msg);
}
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.1.0
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> The key issue being addressed here is ephemeral port usage. Once all
> available ports are in use, the clients are unable to send more messages.
> Controlling ephemeral port usage means the client can more often send
> messages to the server-side.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {. os.flush(); }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882445#comment-17882445
]
Jamie Mark Goodyear commented on CXF-9059:
--
Testing notes:
On linux systems, the ss -s command will provide you statistics on socket
usage.
We can observe when ephemeral port usage stabilizes.
On MacOS one can use netstat -an | grep IP_ADDRESS_OF_SERVER | wc -l
To get an idea of connection count.
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.1.0
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {.
> os.flush();
> }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882437#comment-17882437
]
Jamie Mark Goodyear commented on CXF-9059:
--
Windows 11 Pro, 16 clients for ten minutes on Java 17:
{{=Overall Test Result }}
{{Overall Throughput: get 1327.0985260828597 (invocations/sec) }}
{{Overall AVG. response time: 0.753523958739 (ms) }}
{{1.2743023E7 (invocations), running 9602.168 (sec) }}
{{}}
{{Windows 11 Pro, 16 clients for ten minutes on Java 21:}}
{{=Overall Test Result }}
{{Overall Throughput: get 1611.1071885223246 (invocations/sec) }}
{{Overall AVG. response time: 0.6206911663755781 (ms) }}
{{1.547066E7 (invocations), running 9602.502 (sec) }}
{{}}
The Java 21 runtime obtained higher throughput.
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.1.0
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {.
> os.flush();
> }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
[
https://issues.apache.org/jira/browse/CXF-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jamie Mark Goodyear updated CXF-9059:
-
Description:
HttpConduit should flush output stream ahead of closing connections when
HttpClient is autocloseable.
When running WebClient in a load test (single host) we'll observe low
throughput.
When we adjust the HttpConduit to flush output stream ahead of connection
close, we observe significant throughput improvement.
Given this appears to affect just autocloseable HttpClient, we select to flush
the output stead only when the JVM provides the autocloseable HttpClient
variety.
AbstractConduit:
finally {
OutputStream os = msg.getContent(OutputStream.class);
// Java 21 may hang on close, we flush stream to help close them out.
if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
{.
os.flush();
}
super.close(msg);
}
was:
HttpConduit should flush output stream ahead of closing connections when
HttpClient is autocloseable.
When running WebClient in a load test (single host) we'll observe low
throughput.
When we adjust the HttpConduit to flush output stream ahead of connection
close, we observe significant throughput improvement.
Given this appears to affect just autocloseable HttpClient, we select to flush
the output stead only when the JVM provides the autocloseable HttpClient
variety.
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable
>
>
> Key: CXF-9059
> URL: https://issues.apache.org/jira/browse/CXF-9059
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 4.1.0
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 4.1.0
>
>
> HttpConduit should flush output stream ahead of closing connections when
> HttpClient is autocloseable.
> When running WebClient in a load test (single host) we'll observe low
> throughput.
> When we adjust the HttpConduit to flush output stream ahead of connection
> close, we observe significant throughput improvement.
> Given this appears to affect just autocloseable HttpClient, we select to
> flush the output stead only when the JVM provides the autocloseable
> HttpClient variety.
>
> AbstractConduit:
> finally {
> OutputStream os = msg.getContent(OutputStream.class);
> // Java 21 may hang on close, we flush stream to help close them out.
> if (os != null && AutoCloseable.class.isAssignableFrom(HttpClient.class))
> {.
> os.flush();
> }
> super.close(msg);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-9059) HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable
Jamie Mark Goodyear created CXF-9059: Summary: HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable Key: CXF-9059 URL: https://issues.apache.org/jira/browse/CXF-9059 Project: CXF Issue Type: Improvement Components: JAX-RS Affects Versions: 4.1.0 Reporter: Jamie Mark Goodyear Fix For: 4.1.0 HttpConduit should flush output stream ahead of closing connections when HttpClient is autocloseable. When running WebClient in a load test (single host) we'll observe low throughput. When we adjust the HttpConduit to flush output stream ahead of connection close, we observe significant throughput improvement. Given this appears to affect just autocloseable HttpClient, we select to flush the output stead only when the JVM provides the autocloseable HttpClient variety. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9039) Run Jakarta RESTful Web Services 3.1 TCK
[ https://issues.apache.org/jira/browse/CXF-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9039: -- Description: Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10). It seems like the Jakarta EE 10 jaxrs TCK is split between: - [https://github.com/jakartaee/rest/tree/3.1.0/jersey-tck] - https://github.com/jakartaee/platform-tck/tree/10.0.5 was:Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10) > Run Jakarta RESTful Web Services 3.1 TCK > > > Key: CXF-9039 > URL: https://issues.apache.org/jira/browse/CXF-9039 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0 > > > Run Jakarta RESTful Web Services 3.1 TCK (JakarteEE 10). > It seems like the Jakarta EE 10 jaxrs TCK is split between: > - [https://github.com/jakartaee/rest/tree/3.1.0/jersey-tck] > - https://github.com/jakartaee/platform-tck/tree/10.0.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9058) jaxws binding example in documentation no more work in v4.x because of jarkarta
[
https://issues.apache.org/jira/browse/CXF-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathieu CARBONNEAUX updated CXF-9058:
-
Description:
in cxf wsdl2java documentation :
[https://cxf.apache.org/docs/wsdl-to-java.html]
You have the ability to use JAXWS binding file to customise wsdl2java
generation to enable enableWrapperStyle:
{code:java}
http://www.w3.org/2001/XMLSchema";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
wsdlLocation="your.wsdl"
xmlns="http://java.sun.com/xml/ns/jaxws"
xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";>
false
{code}
and i got this error :
{noformat}
org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
file, please check the namespace{noformat}
but with v4.x cxf had upgraded to jakarta and now we need to change
namespace:
{code:java}
http://www.w3.org/2001/XMLSchema";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
wsdlLocation="your.wsdl"
xmlns="http://jakarta.ee/xml/ns/jaxws"
xmlns:jaxws="http://jakarta.ee/xml/ns/jaxws";>
false
{code}
we need to change java.sun.com to jakarta.ee and add version="3.0".
can you modify documentation to explain the difference between <4.x and >=4.x.
was:
in cxf wsdl2java documentation :
[https://cxf.apache.org/docs/wsdl-to-java.html]
You have the ability to use JAXWS binding file to customise wsdl2java
generation to enable enableWrapperStyle:
{code:java}
http://www.w3.org/2001/XMLSchema";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
wsdlLocation="your.wsdl"
xmlns="http://java.sun.com/xml/ns/jaxws"
xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";>
false
{code}
and i got this error :
{noformat}
org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
file, please check the namespace{noformat}
but with v4.x cxf had upgraded to jakarta and now we need to change
namespace:
{code:java}
http://www.w3.org/2001/XMLSchema";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
wsdlLocation="your.wsdl"
xmlns="http://jakarta.ee/xml/ns/jaxws"
xmlns:jaxws="http://jakarta.ee/xml/ns/jaxws";>
false
{code}
we need to change java.sun.com to jakarta.ee and add version="3.0".
> jaxws binding example in documentation no more work in v4.x because of
> jarkarta
> ---
>
> Key: CXF-9058
> URL: https://issues.apache.org/jira/browse/CXF-9058
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5
>Reporter: Mathieu CARBONNEAUX
>Priority: Major
>
> in cxf wsdl2java documentation :
> [https://cxf.apache.org/docs/wsdl-to-java.html]
>
> You have the ability to use JAXWS binding file to customise wsdl2java
> generation to enable enableWrapperStyle:
>
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://java.sun.com/xml/ns/jaxws"
>xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";>
>false
> {code}
>
> and i got this error :
> {noformat}
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace{noformat}
> but with v4.x cxf had upgraded to jakarta and now we need to change
> namespace:
> {code:java}
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>wsdlLocation="your.wsdl"
>xmlns="http://jakarta.ee/xml/ns/jaxws"
>xmlns:jaxws="http://jakarta.ee/xml/ns/jaxws";>
>false
> {code}
> we need to change java.sun.com to jakarta.ee and add version="3.0".
>
> can you modify documentation to explain the difference between <4.x and >=4.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-9058) jaxws binding example in documentation no more work in v4.x because of jarkarta
Mathieu CARBONNEAUX created CXF-9058:
Summary: jaxws binding example in documentation no more work in
v4.x because of jarkarta
Key: CXF-9058
URL: https://issues.apache.org/jira/browse/CXF-9058
Project: CXF
Issue Type: Bug
Components: Tooling
Affects Versions: 4.0.5, 4.0.4, 4.0.3, 4.0.2, 4.0.1, 4.0.0
Reporter: Mathieu CARBONNEAUX
in cxf wsdl2java documentation :
[https://cxf.apache.org/docs/wsdl-to-java.html]
You have the ability to use JAXWS binding file to customise wsdl2java
generation to enable enableWrapperStyle:
{code:java}
http://www.w3.org/2001/XMLSchema";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
wsdlLocation="your.wsdl"
xmlns="http://java.sun.com/xml/ns/jaxws"
xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";>
false
{code}
and i got this error :
{noformat}
org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
file, please check the namespace{noformat}
but with v4.x cxf had upgraded to jakarta and now we need to change
namespace:
{code:java}
http://www.w3.org/2001/XMLSchema";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
wsdlLocation="your.wsdl"
xmlns="http://jakarta.ee/xml/ns/jaxws"
xmlns:jaxws="http://jakarta.ee/xml/ns/jaxws";>
false
{code}
we need to change java.sun.com to jakarta.ee and add version="3.0".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9034) IllegalAccessError: class org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine
[
https://issues.apache.org/jira/browse/CXF-9034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881980#comment-17881980
]
Joakim Erdfelt commented on CXF-9034:
-
The code at
[https://github.com/apache/cxf/blob/cxf-4.0.4/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPServerEngine.java#L596]
References a Jetty 11 class
`org.eclipse.jetty.server.handler.ContextHandlerCollection` which does exist in
Jetty 12.x, but is part of Jetty Core, which has all Servlet level dependencies
removed from it.
Keep in mind that Jetty 12 is now a Jetty Core (with no EE dependencies), and
Environments (ee11, ee10, ee9, ee8, etc) which has the EE dependencies, like
Servlet.
Looking at your JettyHTTPServerEngine you have a fair number of changes to
make, both due to the Jetty 12 version changes, and also due to Java changes
itself (eg: the SSLv3 code is moot now that you are on Java 17, as it is
disabled at the JVM level)
> IllegalAccessError: class
> org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine
> ---
>
> Key: CXF-9034
> URL: https://issues.apache.org/jira/browse/CXF-9034
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.4
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 4.1.0
>
>
> I have a complex and proprietary test that fails with
> {noformat}
> java.lang.IllegalAccessError: class
> org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine tried to access
> protected method 'void
> org.eclipse.jetty.server.Handler$AbstractContainer.()'
> (org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine and
> org.eclipse.jetty.server.Handler$AbstractContainer are in unnamed module of
> loader 'app')
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.initializeContexts(JettyHTTPServerEngine.java:596)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.addServant(JettyHTTPServerEngine.java:397)
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.activate(JettyHTTPDestination.java:184)
> at
> org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:53)
> at
> org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindingFactory.java:95)
> at
> org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:894)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:130)
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:364)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
> at
> org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:130)
> at jakarta.xml.ws.Endpoint.publish(Endpoint.java:224)
> at
> com.seagullsw.appinterface.server.backend.soap.LS38925ClientOperationsTest.beforeClass(LS38925ClientOperationsTest.java:91)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:93)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:40)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
[jira] [Updated] (CXF-9055) Follow OpenTelemetry semantic conventions for trace span and its attributes
[ https://issues.apache.org/jira/browse/CXF-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9055: -- Fix Version/s: 3.5.10 > Follow OpenTelemetry semantic conventions for trace span and its attributes > --- > > Key: CXF-9055 > URL: https://issues.apache.org/jira/browse/CXF-9055 > Project: CXF > Issue Type: Improvement > Components: Tracing >Affects Versions: 3.5.9 >Reporter: Emile de Weerd >Priority: Minor > Fix For: 4.1.0, 3.5.10, 3.6.5, 4.0.6 > > > OpenTelemetry put in place some recommendations around names of the spans and > names of their span attributes and their value. All recapped under the > semconv project: > [https://opentelemetry.io/docs/specs/semconv/general/trace/] > For HTTP exchanges, there are dedicated conventions: > [https://opentelemetry.io/docs/specs/semconv/http/http-spans/] > Issue is CXF, since the OpenTelemetry feature, is not following those > conventions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9055) Follow OpenTelemetry semantic conventions for trace span and its attributes
[ https://issues.apache.org/jira/browse/CXF-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9055: -- Fix Version/s: 3.6.5 > Follow OpenTelemetry semantic conventions for trace span and its attributes > --- > > Key: CXF-9055 > URL: https://issues.apache.org/jira/browse/CXF-9055 > Project: CXF > Issue Type: Improvement > Components: Tracing >Affects Versions: 3.5.9 >Reporter: Emile de Weerd >Priority: Minor > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > OpenTelemetry put in place some recommendations around names of the spans and > names of their span attributes and their value. All recapped under the > semconv project: > [https://opentelemetry.io/docs/specs/semconv/general/trace/] > For HTTP exchanges, there are dedicated conventions: > [https://opentelemetry.io/docs/specs/semconv/http/http-spans/] > Issue is CXF, since the OpenTelemetry feature, is not following those > conventions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-9055) Follow OpenTelemetry semantic conventions for trace span and its attributes
[ https://issues.apache.org/jira/browse/CXF-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-9055. --- Resolution: Fixed > Follow OpenTelemetry semantic conventions for trace span and its attributes > --- > > Key: CXF-9055 > URL: https://issues.apache.org/jira/browse/CXF-9055 > Project: CXF > Issue Type: Improvement > Components: Tracing >Affects Versions: 3.5.9 >Reporter: Emile de Weerd >Priority: Minor > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > OpenTelemetry put in place some recommendations around names of the spans and > names of their span attributes and their value. All recapped under the > semconv project: > [https://opentelemetry.io/docs/specs/semconv/general/trace/] > For HTTP exchanges, there are dedicated conventions: > [https://opentelemetry.io/docs/specs/semconv/http/http-spans/] > Issue is CXF, since the OpenTelemetry feature, is not following those > conventions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9055) Follow OpenTelemetry semantic conventions for trace span and its attributes
[ https://issues.apache.org/jira/browse/CXF-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9055: -- Fix Version/s: 4.0.6 > Follow OpenTelemetry semantic conventions for trace span and its attributes > --- > > Key: CXF-9055 > URL: https://issues.apache.org/jira/browse/CXF-9055 > Project: CXF > Issue Type: Improvement > Components: Tracing >Affects Versions: 3.5.9 >Reporter: Emile de Weerd >Priority: Minor > Fix For: 4.1.0, 4.0.6 > > > OpenTelemetry put in place some recommendations around names of the spans and > names of their span attributes and their value. All recapped under the > semconv project: > [https://opentelemetry.io/docs/specs/semconv/general/trace/] > For HTTP exchanges, there are dedicated conventions: > [https://opentelemetry.io/docs/specs/semconv/http/http-spans/] > Issue is CXF, since the OpenTelemetry feature, is not following those > conventions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-9057) Chunked Stream is closed regularly when Exception is thrown
Johannes Herr created CXF-9057:
--
Summary: Chunked Stream is closed regularly when Exception is
thrown
Key: CXF-9057
URL: https://issues.apache.org/jira/browse/CXF-9057
Project: CXF
Issue Type: Bug
Affects Versions: 3.5.8
Reporter: Johannes Herr
In response to SOAP requests served by Apache CXF we send large datasets
streamed directly from a database. Because of the size of the data, chunked
encoding is used. Unfortunately when a database error occurs and an exception
is thrown while data is sent, the client will receive a regular ending to the
chunked data stream. That means he has no way to recognise that an error
occurred and that he has only received a partial file.
To be more specific the response looks somewhat like this:
{code:java}
HTTP/1.1 200 OK
Date: Tue, 10 Sep 2024 16:17:45 GMT
Content-Type: multipart/related; type="application/xop+xml";
boundary="uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940";
start=""; start-info="text/xml"
Transfer-Encoding: chunked
Server: Jetty(10.0.21)
8000
--uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID:
http://schemas.xmlsoap.org/soap/envelope/";>[...]
--uuid:49aa53f9-ec29-4f1a-bc07-a21256c2f940
Content-Type:
Content-Transfer-Encoding: binary
Content-ID: <03d4ea67-6e8b-4d1f-91b0-b63208989f9...@cxf.apache.org>
[...]xxx
356
xx
0
{code}
That means the response ends with the "0" entry, indicating that the transfer
is complete.
What should happen instead is that the response should be closed without
sending the final 0 entry. ([https://stackoverflow.com/a/17203961/136247])
For example when we use a Servlet to stream data to a client a throw an
exception the result will look something like this:
{code:java}
HTTP/1.1 200 OK
Date: Fri, 13 Sep 2024 09:31:48 GMT
Content-Type: text/plain;charset=utf-8
Transfer-Encoding: chunked
Server: Jetty(10.0.21)
8
Chunk 1
8
Chunk 2
8
Chunk 3
8
Chunk 4
8
Chunk 5
{code}
Here there is no closing 0 marker. As a result clients can recognise the error.
(Curl will report "curl: (18) transfer closed with outstanding read data
remaining", Chrome "Failed to load resource:
net::ERR_INCOMPLETE_CHUNKED_ENCODING")
CXF should do the same and not end the chunked stream regularly, when an
exception is thrown.
I have tested with Tomcat and Jetty. Both show the same behaviour.
To provide some detail, Exceptions are caught by CXF here:
org/apache/cxf/phase/PhaseInterceptorChain.java:328
{code:java}
} catch (RuntimeException ex) {
if (!faultOccurred) {
faultOccurred = true;
wrapExceptionAsFault(message, ex);
}
state = State.ABORTED;
}
{code}
The exception is logged, but not rethrown.
If the exception would be thrown, for instance Tomcats ErrorReportValve would
shut down the output and thereby prevent the end of the input and closing 0 to
be written.
org/apache/catalina/valves/ErrorReportValve.java:112
{code:java}
// Now close immediately to signal to the client that
// something went wrong
response.getCoyoteResponse().action(ActionCode.CLOSE_NOW,
request.getAttribute(RequestDispatcher.ERROR_EXCEPTION));
{code}
Without an exception to prevent this, a regular end of the stream will be
written by
org/apache/catalina/connector/CoyoteAdapter.java:371
response.finishResponse();
In Summary: CXF ends a chunked encoded stream in a regular way in spite of
exceptions occurring, which makes it impossible for clients to recognise that
they have downloaded partial and therefore corrupt data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXFXJC-49) cxf-xjc-dv should not generate deprecated code
[
https://issues.apache.org/jira/browse/CXFXJC-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXFXJC-49.
Resolution: Fixed
> cxf-xjc-dv should not generate deprecated code
> ---
>
> Key: CXFXJC-49
> URL: https://issues.apache.org/jira/browse/CXFXJC-49
> Project: CXF XJC Utils
> Issue Type: Improvement
> Components: DV Plugin
>Affects Versions: 3.3.4, 4.0.2
>Reporter: Dries Van Autreve
>Priority: Minor
> Fix For: 4.1.0, 4.0.3, 3.3.5
>
>
> Given the XMLSchema:
> {code:xml}
>
> {code}
> the plugin generates:
> {code:java}
> public Integer getMyInt() {
> if (null == myInt) {
> return new Integer(1);
> }
> return myInt;
> }
> {code}
> which is deprecated.
> For example compiling with Java 21 gives following warning:
> {noformat}
> Integer(int) in java.lang.Integer has been deprecated and marked for removal
> {noformat}
> The plugin should instead generate:
> {code:java}
> Integer.valueOf(1);
> {code}
> The same goes for Long, Double, ...
> I'll try to provide a PR to change this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXFXJC-49) cxf-xjc-dv should not generate deprecated code
[
https://issues.apache.org/jira/browse/CXFXJC-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXFXJC-49:
---
Fix Version/s: 4.1.0
> cxf-xjc-dv should not generate deprecated code
> ---
>
> Key: CXFXJC-49
> URL: https://issues.apache.org/jira/browse/CXFXJC-49
> Project: CXF XJC Utils
> Issue Type: Improvement
> Components: DV Plugin
>Affects Versions: 3.3.4, 4.0.2
>Reporter: Dries Van Autreve
>Priority: Minor
> Fix For: 4.1.0, 4.0.3, 3.3.5
>
>
> Given the XMLSchema:
> {code:xml}
>
> {code}
> the plugin generates:
> {code:java}
> public Integer getMyInt() {
> if (null == myInt) {
> return new Integer(1);
> }
> return myInt;
> }
> {code}
> which is deprecated.
> For example compiling with Java 21 gives following warning:
> {noformat}
> Integer(int) in java.lang.Integer has been deprecated and marked for removal
> {noformat}
> The plugin should instead generate:
> {code:java}
> Integer.valueOf(1);
> {code}
> The same goes for Long, Double, ...
> I'll try to provide a PR to change this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXFXJC-49) cxf-xjc-dv should not generate deprecated code
[
https://issues.apache.org/jira/browse/CXFXJC-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXFXJC-49:
---
Fix Version/s: 4.0.3
> cxf-xjc-dv should not generate deprecated code
> ---
>
> Key: CXFXJC-49
> URL: https://issues.apache.org/jira/browse/CXFXJC-49
> Project: CXF XJC Utils
> Issue Type: Improvement
> Components: DV Plugin
>Affects Versions: 4.0.2
>Reporter: Dries Van Autreve
>Priority: Minor
> Fix For: 4.0.3
>
>
> Given the XMLSchema:
> {code:xml}
>
> {code}
> the plugin generates:
> {code:java}
> public Integer getMyInt() {
> if (null == myInt) {
> return new Integer(1);
> }
> return myInt;
> }
> {code}
> which is deprecated.
> For example compiling with Java 21 gives following warning:
> {noformat}
> Integer(int) in java.lang.Integer has been deprecated and marked for removal
> {noformat}
> The plugin should instead generate:
> {code:java}
> Integer.valueOf(1);
> {code}
> The same goes for Long, Double, ...
> I'll try to provide a PR to change this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXFXJC-49) cxf-xjc-dv should not generate deprecated code
[
https://issues.apache.org/jira/browse/CXFXJC-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXFXJC-49:
---
Affects Version/s: 3.3.4
> cxf-xjc-dv should not generate deprecated code
> ---
>
> Key: CXFXJC-49
> URL: https://issues.apache.org/jira/browse/CXFXJC-49
> Project: CXF XJC Utils
> Issue Type: Improvement
> Components: DV Plugin
>Affects Versions: 3.3.4, 4.0.2
>Reporter: Dries Van Autreve
>Priority: Minor
> Fix For: 4.0.3
>
>
> Given the XMLSchema:
> {code:xml}
>
> {code}
> the plugin generates:
> {code:java}
> public Integer getMyInt() {
> if (null == myInt) {
> return new Integer(1);
> }
> return myInt;
> }
> {code}
> which is deprecated.
> For example compiling with Java 21 gives following warning:
> {noformat}
> Integer(int) in java.lang.Integer has been deprecated and marked for removal
> {noformat}
> The plugin should instead generate:
> {code:java}
> Integer.valueOf(1);
> {code}
> The same goes for Long, Double, ...
> I'll try to provide a PR to change this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXFXJC-49) cxf-xjc-dv should not generate deprecated code
[
https://issues.apache.org/jira/browse/CXFXJC-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXFXJC-49:
---
Fix Version/s: 3.3.5
> cxf-xjc-dv should not generate deprecated code
> ---
>
> Key: CXFXJC-49
> URL: https://issues.apache.org/jira/browse/CXFXJC-49
> Project: CXF XJC Utils
> Issue Type: Improvement
> Components: DV Plugin
>Affects Versions: 3.3.4, 4.0.2
>Reporter: Dries Van Autreve
>Priority: Minor
> Fix For: 4.0.3, 3.3.5
>
>
> Given the XMLSchema:
> {code:xml}
>
> {code}
> the plugin generates:
> {code:java}
> public Integer getMyInt() {
> if (null == myInt) {
> return new Integer(1);
> }
> return myInt;
> }
> {code}
> which is deprecated.
> For example compiling with Java 21 gives following warning:
> {noformat}
> Integer(int) in java.lang.Integer has been deprecated and marked for removal
> {noformat}
> The plugin should instead generate:
> {code:java}
> Integer.valueOf(1);
> {code}
> The same goes for Long, Double, ...
> I'll try to provide a PR to change this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXFXJC-49) cxf-xjc-dv should not generate deprecated code
Dries Van Autreve created CXFXJC-49:
---
Summary: cxf-xjc-dv should not generate deprecated code
Key: CXFXJC-49
URL: https://issues.apache.org/jira/browse/CXFXJC-49
Project: CXF XJC Utils
Issue Type: Improvement
Components: DV Plugin
Affects Versions: 4.0.2
Reporter: Dries Van Autreve
Given the XMLSchema:
{code:xml}
{code}
the plugin generates:
{code:java}
public Integer getMyInt() {
if (null == myInt) {
return new Integer(1);
}
return myInt;
}
{code}
which is deprecated.
For example compiling with Java 21 gives following warning:
{noformat}
Integer(int) in java.lang.Integer has been deprecated and marked for removal
{noformat}
The plugin should instead generate:
{code:java}
Integer.valueOf(1);
{code}
The same goes for Long, Double, ...
I'll try to provide a PR to change this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9056) NTML Login ends up with Authorization loop detected after upgrading CXF from 3.5 to 3.6
[
https://issues.apache.org/jira/browse/CXF-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Suter updated CXF-9056:
-
Description:
After upgrading cxf from 3.5 to 3.6 we can no longer authenticate with NTLM
with CXF as web service client technology.
We do support two modes in our product. With Challenge and without challenge.
And the case without challenge (challenge = false) is no longer working whereas
the authentication will be set on the httpConduit directly.
{code:java}
public class NTLMAuthenticationFeature implements WebServiceClientFeature {
@Override
public void initialize(WebServiceClientFeatureContext context) {
BindingProvider bindingProvider = context.getBindingProvider();
WsProps props = new WsProps(context.getProperties());
Client proxy = ClientProxy.getClient(bindingProvider);
boolean challenge =
props.bool(Authentication.NTLM.CHALLENGE).orElse(Boolean.TRUE);
proxy.getRequestContext().put(AsyncHTTPConduit.USE_ASYNC, challenge);
var credentials = createNTCredentials(props);
if (challenge) {
proxy.getRequestContext().put(Credentials.class.getName(), credentials);
}
Conduit conduit = proxy.getConduit();
if (conduit instanceof HTTPConduit httpConduit) {
httpConduit.getClient().setAutoRedirect(true);
}
if (!challenge) {
// this does no longer work
httpConduit.getClient().setAllowChunking(false);
setNtlmAuthHeader(credentials, httpConduit);
}
}
private void setNtlmAuthHeader(NTCredentials credentials, HTTPConduit
httpConduit) {
var auth = httpConduit.getAuthorization();
auth.setAuthorizationType("NTLM");
auth.setUserName(credentials.getUserPrincipal().getName());
auth.setPassword(credentials.getPassword());
}
private static NTCredentials createNTCredentials(WsProps properties) {
var username = properties.string(Authentication.USERNAME);
var password = properties.string(Authentication.PASSWORD);
var workstation = properties.string(Authentication.NTLM.WORKSTATION);
var domain = properties.string(Authentication.NTLM.DOMAIN);
return new NTCredentials(username, password, workstation, domain);
}
private static record WsProps(Map props) {
String string(String key) {
return Optional.ofNullable(props.get(key))
.map(String.class::cast)
.orElse(null);
Optional bool(String key) {
return Optional.ofNullable(props.get(key))
.map(String.class::cast)
.filter(Predicate.not(String::isBlank))
.map(Boolean::parseBoolean);
}
}
} {code}
See the error stack trace in the log.
Do you have any hints for this problem?
was:
After upgrading cxf from 3.5 to 3.6 we can no longer authenticate with NTLM
with CXF as web service client technology.
We do support two modes in our product. With Challenge and without challenge.
And the case without challenge (challenge = false) is no longer working whereas
the authentication will be set on the httpConduit directly.
{color:#cc6c1d}public{color}{color:#d9e8f7}
{color}{color:#cc6c1d}class{color}{color:#d9e8f7}
{color}{color:#1290c3}NTLMAuthenticationFeature{color}{color:#d9e8f7}
{color}{color:#cc6c1d}implements{color}{color:#d9e8f7}
{color}{color:#80f2f6}WebServiceClientFeature{color}{color:#d9e8f7}
{color}{color:#f9faf4}{{color}
{color:#d9e8f7} {color}{color:#a0a0a0}@Override{color}
{color:#d9e8f7} {color}{color:#cc6c1d}public{color}{color:#d9e8f7}
{color}{color:#cc6c1d}void{color}{color:#d9e8f7}
{color}{color:#1eb540}initialize{color}{color:#f9faf4}({color}{color:#1290c3}WebServiceClientFeatureContext{color}{color:#d9e8f7}
{color}{color:#79abff}context{color}{color:#f9faf4}){color}{color:#d9e8f7}
{color}{color:#f9faf4}{{color}
{color:#d9e8f7} {color}{color:#80f2f6}BindingProvider{color}{color:#d9e8f7}
{color}{color:#f2f200}bindingProvider{color}{color:#d9e8f7}
{color}{color:#e6e6fa}={color}{color:#d9e8f7}
{color}{color:#79abff}context{color}{color:#e6e6fa}.{color}{color:#a7ec21}getBindingProvider{color}{color:#f9faf4}(){color}{color:#e6e6fa};{color}
{color:#d9e8f7} {color}{color:#1290c3}WsProps{color}{color:#d9e8f7}
{color}{color:#f2f200}props{color}{color:#d9e8f7}
{color}{color:#e6e6fa}={color}{color:#d9e8f7}
{color}{color:#cc6c1d}new{color}{color:#d9e8f7}
{color}{color:#a7ec21}WsProps{color}{color:#f9faf4}({color}{color:#79abff}context{color}{color:#e6e6fa}.{color}{color:#a7ec21}getProperties{color}{color:#f9faf4}()){color}{color:#e6e6fa};{color}
{color:#d9e8f7} {color}{color:#80f2f6}Client{color}{color:#d9e8f7}
{color}{color:#f2f200}proxy{color}{color:#d9e8f7}
{color}{color:#e6e6fa}={color}{color:#d9e8f7}
{color}{color:#1290c3}ClientProxy{color}{color:#e6e6fa}.{color}{color:#96ec3f}getClient{color}{color:#f9faf4}({color}{color:#f3ec79}bindingProvider{color}{color:#f9faf4}){color}{color:#e6e6fa};{color}
{color:#d9e8f7} {color}{color:#cc6c1d}boolean{color}{color:#d9e8f7}
{color}{color:#f2f200}challenge{color}{color:#d9e8f
[jira] [Created] (CXF-9056) NTML Login ends up with Authorization loop detected after upgrading CXF from 3.5 to 3.6
Alexander Suter created CXF-9056:
Summary: NTML Login ends up with Authorization loop detected after
upgrading CXF from 3.5 to 3.6
Key: CXF-9056
URL: https://issues.apache.org/jira/browse/CXF-9056
Project: CXF
Issue Type: Bug
Reporter: Alexander Suter
Attachments: stacktrace.txt
After upgrading cxf from 3.5 to 3.6 we can no longer authenticate with NTLM
with CXF as web service client technology.
We do support two modes in our product. With Challenge and without challenge.
And the case without challenge (challenge = false) is no longer working whereas
the authentication will be set on the httpConduit directly.
{color:#cc6c1d}public{color}{color:#d9e8f7}
{color}{color:#cc6c1d}class{color}{color:#d9e8f7}
{color}{color:#1290c3}NTLMAuthenticationFeature{color}{color:#d9e8f7}
{color}{color:#cc6c1d}implements{color}{color:#d9e8f7}
{color}{color:#80f2f6}WebServiceClientFeature{color}{color:#d9e8f7}
{color}{color:#f9faf4}{{color}
{color:#d9e8f7} {color}{color:#a0a0a0}@Override{color}
{color:#d9e8f7} {color}{color:#cc6c1d}public{color}{color:#d9e8f7}
{color}{color:#cc6c1d}void{color}{color:#d9e8f7}
{color}{color:#1eb540}initialize{color}{color:#f9faf4}({color}{color:#1290c3}WebServiceClientFeatureContext{color}{color:#d9e8f7}
{color}{color:#79abff}context{color}{color:#f9faf4}){color}{color:#d9e8f7}
{color}{color:#f9faf4}{{color}
{color:#d9e8f7} {color}{color:#80f2f6}BindingProvider{color}{color:#d9e8f7}
{color}{color:#f2f200}bindingProvider{color}{color:#d9e8f7}
{color}{color:#e6e6fa}={color}{color:#d9e8f7}
{color}{color:#79abff}context{color}{color:#e6e6fa}.{color}{color:#a7ec21}getBindingProvider{color}{color:#f9faf4}(){color}{color:#e6e6fa};{color}
{color:#d9e8f7} {color}{color:#1290c3}WsProps{color}{color:#d9e8f7}
{color}{color:#f2f200}props{color}{color:#d9e8f7}
{color}{color:#e6e6fa}={color}{color:#d9e8f7}
{color}{color:#cc6c1d}new{color}{color:#d9e8f7}
{color}{color:#a7ec21}WsProps{color}{color:#f9faf4}({color}{color:#79abff}context{color}{color:#e6e6fa}.{color}{color:#a7ec21}getProperties{color}{color:#f9faf4}()){color}{color:#e6e6fa};{color}
{color:#d9e8f7} {color}{color:#80f2f6}Client{color}{color:#d9e8f7}
{color}{color:#f2f200}proxy{color}{color:#d9e8f7}
{color}{color:#e6e6fa}={color}{color:#d9e8f7}
{color}{color:#1290c3}ClientProxy{color}{color:#e6e6fa}.{color}{color:#96ec3f}getClient{color}{color:#f9faf4}({color}{color:#f3ec79}bindingProvider{color}{color:#f9faf4}){color}{color:#e6e6fa};{color}
{color:#d9e8f7} {color}{color:#cc6c1d}boolean{color}{color:#d9e8f7}
{color}{color:#f2f200}challenge{color}{color:#d9e8f7}
{color}{color:#e6e6fa}={color}{color:#d9e8f7}
{color}{color:#f3ec79}props{color}{color:#e6e6fa}.{color}{color:#a7ec21}bool{color}{color:#f9faf4}({color}{color:#80f2f6}Authentication{color}{color:#e6e6fa}.{color}{color:#80f2f6}NTLM{color}{color:#e6e6fa}.{color}{color:#8ddaf8}CHALLENGE{color}{color:#f9faf4}){color}{color:#e6e6fa}.{color}{color:#a7ec21}orElse{color}{color:#f9faf4}({color}{color:#1290c3}Boolean{color}{color:#e6e6fa}.{color}{color:#8ddaf8}TRUE{color}{color:#f9faf4}){color}{color:#e6e6fa};{color}
{color:#d9e8f7}
{color}{color:#f3ec79}proxy{color}{color:#e6e6fa}.{color}{color:#80f6a7}getRequestContext{color}{color:#f9faf4}(){color}{color:#e6e6fa}.{color}{color:#80f6a7}put{color}{color:#f9faf4}({color}{color:#1290c3}AsyncHTTPConduit{color}{color:#e6e6fa}.{color}{color:#8ddaf8}USE_ASYNC{color}{color:#e6e6fa},{color}{color:#d9e8f7}
{color}{color:#f3ec79}challenge{color}{color:#f9faf4}){color}{color:#e6e6fa};{color}
{color:#d9e8f7} {color}{color:#cc6c1d}var{color}{color:#d9e8f7}
{color}{color:#f2f200}credentials{color}{color:#d9e8f7}
{color}{color:#e6e6fa}={color}{color:#d9e8f7}
{color}{color:#96ec3f}createNTCredentials{color}{color:#f9faf4}({color}{color:#f3ec79}props{color}{color:#f9faf4}){color}{color:#e6e6fa};{color}
{color:#d9e8f7} {color}{color:#cc6c1d}if{color}{color:#d9e8f7}
{color}{color:#f9faf4}({color}{color:#f3ec79}challenge{color}{color:#f9faf4}){color}{color:#d9e8f7}
{color}{color:#f9faf4}{{color}
{color:#d9e8f7}
{color}{color:#f3ec79}proxy{color}{color:#e6e6fa}.{color}{color:#80f6a7}getRequestContext{color}{color:#f9faf4}(){color}{color:#e6e6fa}.{color}{color:#80f6a7}put{color}{color:#f9faf4}({color}{color:#80f2f6}Credentials{color}{color:#e6e6fa}.{color}{color:#cc6c1d}class{color}{color:#e6e6fa}.{color}{color:#a7ec21}getName{color}{color:#f9faf4}(){color}{color:#e6e6fa},{color}{color:#d9e8f7}
{color}{color:#f3ec79}credentials{color}{color:#f9faf4}){color}{color:#e6e6fa};{color}
{color:#d9e8f7} {color}{color:#f9faf4}}{color}
{color:#d9e8f7} {color}{color:#80f2f6}Conduit{color}{color:#d9e8f7}
{color}{color:#f2f200}conduit{color}{color:#d9e8f7}
{color}{color:#e6e6fa}={color}{color:#d9e8f7}
{color}{color:#f3ec79}proxy{color}{color:#e6e6fa}.{color}{color:#80f6a7}getConduit
[jira] [Created] (CXF-9055) Follow OpenTelemetry semantic conventions for trace span and its attributes
Emile de Weerd created CXF-9055: --- Summary: Follow OpenTelemetry semantic conventions for trace span and its attributes Key: CXF-9055 URL: https://issues.apache.org/jira/browse/CXF-9055 Project: CXF Issue Type: Improvement Components: Tracing Affects Versions: 3.5.9 Reporter: Emile de Weerd Fix For: 4.1.0 OpenTelemetry put in place some recommendations around names of the spans and names of their span attributes and their value. All recapped under the semconv project: [https://opentelemetry.io/docs/specs/semconv/general/trace/] For HTTP exchanges, there are dedicated conventions: [https://opentelemetry.io/docs/specs/semconv/http/http-spans/] Issue is CXF, since the OpenTelemetry feature, is not following those conventions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9053) NullPointer in JaxWsServiceFactoryBean.generatedWrapperBeanClass() when deploying application
[
https://issues.apache.org/jira/browse/CXF-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880627#comment-17880627
]
Andriy Redko commented on CXF-9053:
---
[~davidbp] I don't think that Bazel produces a valid self-contained, deployable
JAR, please check [1], [2], per my understanding the META-INF/* entries are
not processed properly, hence you run into issues:
[1] [https://github.com/bazelbuild/bazel/issues/7330]
[2] https://github.com/bazelbuild/bazel/issues/21722
> NullPointer in JaxWsServiceFactoryBean.generatedWrapperBeanClass() when
> deploying application
> -
>
> Key: CXF-9053
> URL: https://issues.apache.org/jira/browse/CXF-9053
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.1
>Reporter: David Butragueno Palomar
>Priority: Minor
>
> I am using Apache CXF in a Java application built with Bazel to make requests
> to an external web service. When deploying the microservice locally, for
> example, using IntelliJ IDEA, the application deploys successfully and works
> as expected. However, when deploying the application within a Docker
> container, the microservice fails to deploy due to the following error:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:158)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
> ~[service_deploy.jar:?] {code}
>
> *Apache CXF dependencies*
> org.apache.cxf:cxf-rt-ws-security
> org.apache.cxf:cxf-rt-frontend-jaxws
> org.apache.cxf:cxf-rt-transports-http
>
>
> *JVM options*
>
> -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
> -Dlog4j2.configurationFile=/resources/log4j2.xml
> -Dlog4j2.debug=true
>
> *Technical specifications*
> Apache CXF version: 3.5.1
> Java versión: 11.0.4
> Bazel version: 6.3.2
> Docker version: 20.10.12
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9053) NullPointer in JaxWsServiceFactoryBean.generatedWrapperBeanClass() when deploying application
[
https://issues.apache.org/jira/browse/CXF-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880442#comment-17880442
]
Andriy Redko commented on CXF-9053:
---
[~davidbp] the problem is very likely related to the way you package your
application inside the container (fat jar? ...), more details would help here,
thank you.
> NullPointer in JaxWsServiceFactoryBean.generatedWrapperBeanClass() when
> deploying application
> -
>
> Key: CXF-9053
> URL: https://issues.apache.org/jira/browse/CXF-9053
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.1
>Reporter: David Butragueno Palomar
>Priority: Minor
>
> I am using Apache CXF in a Java application built with Bazel to make requests
> to an external web service. When deploying the microservice locally, for
> example, using IntelliJ IDEA, the application deploys successfully and works
> as expected. However, when deploying the application within a Docker
> container, the microservice fails to deploy due to the following error:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:158)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
> ~[service_deploy.jar:?] {code}
>
> *Apache CXF dependencies*
> org.apache.cxf:cxf-rt-ws-security
> org.apache.cxf:cxf-rt-frontend-jaxws
> org.apache.cxf:cxf-rt-transports-http
>
>
> *JVM options*
>
> -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
> -Dlog4j2.configurationFile=/resources/log4j2.xml
> -Dlog4j2.debug=true
>
> *Technical specifications*
> Apache CXF version: 3.5.1
> Java versión: 11.0.4
> Bazel version: 6.3.2
> Docker version: 20.10.12
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9053) NullPointer in JaxWsServiceFactoryBean.generatedWrapperBeanClass() when deploying application
[
https://issues.apache.org/jira/browse/CXF-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Butragueno Palomar updated CXF-9053:
--
Description:
I am using Apache CXF in a Java application built with Bazel to make requests
to an external web service. When deploying the microservice locally, for
example, using IntelliJ IDEA, the application deploys successfully and works as
expected. However, when deploying the application within a Docker container,
the microservice fails to deploy due to the following error:
{code:java}
java.lang.NullPointerException: null
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:158)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
~[service_deploy.jar:?] {code}
*Apache CXF dependencies*
org.apache.cxf:cxf-rt-ws-security
org.apache.cxf:cxf-rt-frontend-jaxws
org.apache.cxf:cxf-rt-transports-http
*JVM options*
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
-Dlog4j2.configurationFile=/resources/log4j2.xml
-Dlog4j2.debug=true
*Technical specifications*
Apache CXF version: 3.5.1
Java versión: 11.0.4
Bazel version: 6.3.2
Docker version: 20.10.12
was:
I am utilizing Apache CXF in a Java application built with Bazel to make
requests to an external web service. When deploying the microservice locally,
for example, using IntelliJ IDEA, the application deploys successfully and
functions as expected. However, when deploying the application within a Docker
container, the microservice fails to deploy due to the following error:
{code:java}
java.lang.NullPointerException: null
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:158)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
~[service_deploy.jar:?] {code}
*Apache-cxf dependencies*
org.apache.cxf:cxf-rt-ws-security
org.apache.cxf:cxf-rt-frontend-jaxws
org.apache.cxf:cxf-rt-transports-http
*JVM options*
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
-Dlog4j2.configurationFile=/resources/log4j2.xml
-Dlog4j2.debug=true
*Technical specifications*
Apache CXF version: 3.5.1
Java versión: 11.0.4
Bazel version: 6.3.2
Docker version: 20.10.12
> NullPointer
[jira] [Updated] (CXF-9053) NullPointer in JaxWsServiceFactoryBean.generatedWrapperBeanClass() when deploying application
[
https://issues.apache.org/jira/browse/CXF-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Butragueno Palomar updated CXF-9053:
--
Priority: Critical (was: Major)
> NullPointer in JaxWsServiceFactoryBean.generatedWrapperBeanClass() when
> deploying application
> -
>
> Key: CXF-9053
> URL: https://issues.apache.org/jira/browse/CXF-9053
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.1
>Reporter: David Butragueno Palomar
>Priority: Critical
>
> I am utilizing Apache CXF in a Java application built with Bazel to make
> requests to an external web service. When deploying the microservice locally,
> for example, using IntelliJ IDEA, the application deploys successfully and
> functions as expected. However, when deploying the application within a
> Docker container, the microservice fails to deploy due to the following error:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:158)
> ~[service_deploy.jar:?]
> at
> org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
> ~[service_deploy.jar:?] {code}
>
> *Apache-cxf dependencies*
> org.apache.cxf:cxf-rt-ws-security
> org.apache.cxf:cxf-rt-frontend-jaxws
> org.apache.cxf:cxf-rt-transports-http
>
>
> *JVM options*
>
> -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
> -Dlog4j2.configurationFile=/resources/log4j2.xml
> -Dlog4j2.debug=true
>
> *Technical specifications*
> Apache CXF version: 3.5.1
> Java versión: 11.0.4
> Bazel version: 6.3.2
> Docker version: 20.10.12
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9053) NullPointer in JaxWsServiceFactoryBean.java when deploying application
[
https://issues.apache.org/jira/browse/CXF-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Butragueno Palomar updated CXF-9053:
--
Description:
I am utilizing Apache CXF in a Java application built with Bazel to make
requests to an external web service. When deploying the microservice locally,
for example, using IntelliJ IDEA, the application deploys successfully and
functions as expected. However, when deploying the application within a Docker
container, the microservice fails to deploy due to the following error:
{code:java}
java.lang.NullPointerException: null
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:158)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
~[service_deploy.jar:?] {code}
*Apache-cxf dependencies*
org.apache.cxf:cxf-rt-ws-security
org.apache.cxf:cxf-rt-frontend-jaxws
org.apache.cxf:cxf-rt-transports-http
*JVM options*
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
-Dlog4j2.configurationFile=/resources/log4j2.xm
-Dlog4j2.debug=true
**
*Technical specifications*
Apache CXF version: 3.5.1
Java versión: 11.0.4
Bazel version: 6.3.2
Docker version: 20.10.12
was:
I am utilizing Apache CXF in a Java application built with Bazel to make
requests to an external web service. When deploying the microservice locally,
for example, using IntelliJ IDEA, the application deploys successfully and
functions as expected. However, when deploying the application within a Docker
container, the microservice fails to deploy due to the following error:
{code:java}
java.lang.NullPointerException: null
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:158)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
~[service_deploy.jar:?] {code}
*Apache-cxf dependencies*
org.apache.cxf:cxf-rt-ws-security
org.apache.cxf:cxf-rt-frontend-jaxws
org.apache.cxf:cxf-rt-transports-http
*JVM options*
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
-Dlog4j2.configurationFile=/resources/log4j2.xm
-Dlog4j2.debug=true
*Technical specifications*
Apache CXF version: 3.5.1
Java versión: 11.0.4
Bazel version: 6.3.2
Docker version: 20.10.12
> NullPointer
[jira] [Updated] (CXF-9053) NullPointer in JaxWsServiceFactoryBean.java when deploying application
[
https://issues.apache.org/jira/browse/CXF-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Butragueno Palomar updated CXF-9053:
--
Description:
I am utilizing Apache CXF in a Java application built with Bazel to make
requests to an external web service. When deploying the microservice locally,
for example, using IntelliJ IDEA, the application deploys successfully and
functions as expected. However, when deploying the application within a Docker
container, the microservice fails to deploy due to the following error:
{code:java}
java.lang.NullPointerException: null
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:158)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
~[service_deploy.jar:?] {code}
*Apache-cxf dependencies*
org.apache.cxf:cxf-rt-ws-security
org.apache.cxf:cxf-rt-frontend-jaxws
org.apache.cxf:cxf-rt-transports-http
*JVM options*
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
-Dlog4j2.configurationFile=/resources/log4j2.xml
-Dlog4j2.debug=true
*Technical specifications*
Apache CXF version: 3.5.1
Java versión: 11.0.4
Bazel version: 6.3.2
Docker version: 20.10.12
was:
I am utilizing Apache CXF in a Java application built with Bazel to make
requests to an external web service. When deploying the microservice locally,
for example, using IntelliJ IDEA, the application deploys successfully and
functions as expected. However, when deploying the application within a Docker
container, the microservice fails to deploy due to the following error:
{code:java}
java.lang.NullPointerException: null
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:158)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
~[service_deploy.jar:?] {code}
*Apache-cxf dependencies*
org.apache.cxf:cxf-rt-ws-security
org.apache.cxf:cxf-rt-frontend-jaxws
org.apache.cxf:cxf-rt-transports-http
*JVM options*
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
-Dlog4j2.configurationFile=/resources/log4j2.xm
-Dlog4j2.debug=true
*Technical specifications*
Apache CXF version: 3.5.1
Java versión: 11.0.4
Bazel version: 6.3.2
Docker version: 20.10.12
> NullPointer
[jira] [Created] (CXF-9053) NullPointer in JaxWsServiceFactoryBean.java when deploying application
David Butragueno Palomar created CXF-9053:
-
Summary: NullPointer in JaxWsServiceFactoryBean.java when
deploying application
Key: CXF-9053
URL: https://issues.apache.org/jira/browse/CXF-9053
Project: CXF
Issue Type: Bug
Reporter: David Butragueno Palomar
I am utilizing Apache CXF in a Java application built with Bazel to make
requests to an external web service. When deploying the microservice locally,
for example, using IntelliJ IDEA, the application deploys successfully and
functions as expected. However, when deploying the application within a Docker
container, the microservice fails to deploy due to the following error:
{code:java}
java.lang.NullPointerException: null
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
~[service_deploy.jar:?]
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
~[service_deploy.jar:?]
at
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:158)
~[service_deploy.jar:?]
at
org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
~[service_deploy.jar:?] {code}
*Apache-cxf dependencies*
org.apache.cxf:cxf-rt-ws-security
org.apache.cxf:cxf-rt-frontend-jaxws
org.apache.cxf:cxf-rt-transports-http
*JVM options*
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
-Dlog4j2.configurationFile=/resources/log4j2.xm
-Dlog4j2.debug=true
*Technical specifications*
Apache CXF version: 3.5.1
Java versión: 11.0.4
Bazel version: 6.3.2
Docker version: 20.10.12
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8624) CXF Extension @QueryParam("") does not parse correctly LocalDate in the bean
[
https://issues.apache.org/jira/browse/CXF-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880173#comment-17880173
]
Andriy Redko commented on CXF-8624:
---
The JAXB spec [1] is a best place to have the support for JSR 310, the
[threeten-jaxb|https://github.com/threeten-jaxb/threeten-jaxb] seems to be
filling this gap at the moment.
[1] https://github.com/eclipse-ee4j/jaxb-ri/issues/1174
> CXF Extension @QueryParam("") does not parse correctly LocalDate in the bean
>
>
> Key: CXF-8624
> URL: https://issues.apache.org/jira/browse/CXF-8624
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.3.12, 3.4.5
>Reporter: Anthony Durussel
>Assignee: Andriy Redko
>Priority: Major
>
> If you use the @QueryParam("") extension on a method parameter:
> {code:java}
> public void foo(@QueryParam("") Bar bar);
> {code}
> with Bar class equals to :
> {code:java}
> public class Bar {
> private LocalDate date;
> } {code}
> The URL generate from the following method parse the localDate as a standard
> object instead of singleValue as it's done for standard java.util.date
> {code:java}
> org.apache.cxf.jaxrs.utils.InjectionUtils.fillInValuesFromBean(Object,
> String, MultivaluedMap)
> {code}
> {code:java}
> if (isPrimitive(value.getClass()) ||
> Date.class.isAssignableFrom(value.getClass())) {
> values.putSingle(propertyName, value);
> } else if (value.getClass().isEnum()) {
> values.putSingle(propertyName, value.toString());
> } else if (isSupportedCollectionOrArray(value.getClass())) {
> final List theValues;
> if (value.getClass().isArray()) {
> theValues = Arrays.asList((Object[])value);
> } else if (value instanceof Set) {
> theValues = new ArrayList<>((Set)value);
> } else {
> theValues = CastUtils.cast((List)value);
> }
> values.put(propertyName, theValues);
> } else if (Map.class.isAssignableFrom(value.getClass())) {
> if (isSupportedMap(m.getGenericReturnType())) {
> Map map = CastUtils.cast((Map)value);
> for (Map.Entry entry : map.entrySet()) {
> values.add(propertyName + '.' + entry.getKey().toString(),
> entry.getValue().toString());
> }
> }
> } else {
> fillInValuesFromBean(value, propertyName, values);
> }{code}
> Ideally, we should add the LocalDate in the first "if condition" to handle it
> correctly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-8624) CXF Extension @QueryParam("") does not parse correctly LocalDate in the bean
[
https://issues.apache.org/jira/browse/CXF-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880173#comment-17880173
]
Andriy Redko edited comment on CXF-8624 at 9/8/24 6:57 PM:
---
The JAXB spec [1] is the best place to have the support for JSR 310, the
[threeten-jaxb|https://github.com/threeten-jaxb/threeten-jaxb] seems to be
filling this gap at the moment.
[1] [https://github.com/eclipse-ee4j/jaxb-ri/issues/1174]
was (Author: reta):
The JAXB spec [1] is a best place to have the support for JSR 310, the
[threeten-jaxb|https://github.com/threeten-jaxb/threeten-jaxb] seems to be
filling this gap at the moment.
[1] https://github.com/eclipse-ee4j/jaxb-ri/issues/1174
> CXF Extension @QueryParam("") does not parse correctly LocalDate in the bean
>
>
> Key: CXF-8624
> URL: https://issues.apache.org/jira/browse/CXF-8624
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.3.12, 3.4.5
>Reporter: Anthony Durussel
>Assignee: Andriy Redko
>Priority: Major
>
> If you use the @QueryParam("") extension on a method parameter:
> {code:java}
> public void foo(@QueryParam("") Bar bar);
> {code}
> with Bar class equals to :
> {code:java}
> public class Bar {
> private LocalDate date;
> } {code}
> The URL generate from the following method parse the localDate as a standard
> object instead of singleValue as it's done for standard java.util.date
> {code:java}
> org.apache.cxf.jaxrs.utils.InjectionUtils.fillInValuesFromBean(Object,
> String, MultivaluedMap)
> {code}
> {code:java}
> if (isPrimitive(value.getClass()) ||
> Date.class.isAssignableFrom(value.getClass())) {
> values.putSingle(propertyName, value);
> } else if (value.getClass().isEnum()) {
> values.putSingle(propertyName, value.toString());
> } else if (isSupportedCollectionOrArray(value.getClass())) {
> final List theValues;
> if (value.getClass().isArray()) {
> theValues = Arrays.asList((Object[])value);
> } else if (value instanceof Set) {
> theValues = new ArrayList<>((Set)value);
> } else {
> theValues = CastUtils.cast((List)value);
> }
> values.put(propertyName, theValues);
> } else if (Map.class.isAssignableFrom(value.getClass())) {
> if (isSupportedMap(m.getGenericReturnType())) {
> Map map = CastUtils.cast((Map)value);
> for (Map.Entry entry : map.entrySet()) {
> values.add(propertyName + '.' + entry.getKey().toString(),
> entry.getValue().toString());
> }
> }
> } else {
> fillInValuesFromBean(value, propertyName, values);
> }{code}
> Ideally, we should add the LocalDate in the first "if condition" to handle it
> correctly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9052) LoadDistributorFeature not comaptible with JAX-RS subresources
[
https://issues.apache.org/jira/browse/CXF-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Beilin updated CXF-9052:
--
Description:
LoadDistributorTargetSelector seems to be confused by subresources.
I'm attaching a test that demonstrates it below.
When no clustering features or FailoverFeature is applied, the client tries to
invoke 'http://localhost:1234/sub/name', as expected. -- `noClustering` and
`failover` pass.
When LoadDistributorFeature is applied, the request is to
'http://localhost:1234/name' (path segment contributed by the root resource is
lost) -- `loadDistributor` fails.
---
{code}
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import java.util.List;
import org.apache.cxf.clustering.FailoverFeature;
import org.apache.cxf.clustering.LoadDistributorFeature;
import org.apache.cxf.clustering.SequentialStrategy;
import org.apache.cxf.feature.Feature;
import org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean;
import org.junit.Assert;
import org.junit.Test;
public class ShowBug {
@Test
public void noClustering() {
makeRequest(List.of());
}
@Test
public void failover() {
var failover = new FailoverFeature();
failover.setStrategy(makeStrategy());
makeRequest(List.of(failover));
}
@Test
public void loadDistributor() {
var distro = new LoadDistributorFeature();
distro.setStrategy(makeStrategy());
makeRequest(List.of(distro));
}
private static SequentialStrategy makeStrategy() {
var s = new SequentialStrategy();
s.setAlternateAddresses(List.of("http://localhost:1234";));
return s;
}
private static void makeRequest(List features) {
var fct = new JAXRSClientFactoryBean();
fct.setFeatures(features);
fct.setServiceClass(Root.class);
fct.setAddress("http://localhost:1234";);
try {
fct.create(Root.class).sub().name();
} catch (Exception e) {
Assert.assertTrue(e.getMessage(),
e.getMessage().contains("/sub/name"));
}
}
interface Root {
@Path("/sub") Sub sub();
}
interface Sub {
@GET @Path("/name") String name();
}
}
{code}
was:
LoadDistributorTargetSelector seems to be confused by subresources.
I'm attaching a test that demonstrates it below.
When no clustering features or FailoverFeature is applied, the client tries to
invoke 'http://localhost:1234/sub/name', as expected. -- `noClustering` and
`failover` pass.
When LoadDistributorFeature is applied, the request is to
'http://localhost:1234/name' (path segment contributed by the root resource is
lost) -- `loadDistributor` fails.
---
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import java.util.List;
import org.apache.cxf.clustering.FailoverFeature;
import org.apache.cxf.clustering.LoadDistributorFeature;
import org.apache.cxf.clustering.SequentialStrategy;
import org.apache.cxf.feature.Feature;
import org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean;
import org.junit.Assert;
import org.junit.Test;
public class ShowBug {
@Test
public void noClustering() {
makeRequest(List.of());
}
@Test
public void failover() {
var failover = new FailoverFeature();
failover.setStrategy(makeStrategy());
makeRequest(List.of(failover));
}
@Test
public void loadDistributor() {
var distro = new LoadDistributorFeature();
distro.setStrategy(makeStrategy());
makeRequest(List.of(distro));
}
private static SequentialStrategy makeStrategy() {
var s = new SequentialStrategy();
s.setAlternateAddresses(List.of("http://localhost:1234";));
return s;
}
private static void makeRequest(List features) {
var fct = new JAXRSClientFactoryBean();
fct.setFeatures(features);
fct.setServiceClass(Root.class);
fct.setAddress("http://localhost:1234";);
try {
fct.create(Root.class).sub().name();
} catch (Exception e) {
Assert.assertTrue(e.getMessage(),
e.getMessage().contains("/sub/name"));
}
}
interface Root {
@Path("/sub") Sub sub();
}
interface Sub {
@GET @Path("/name") String name();
}
}
> LoadDistributorFeature not comaptible with JAX-RS subresources
> --
>
> Key: CXF-9052
> URL: https://issues.apache.org/jira/browse/CXF-9052
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>
[jira] [Created] (CXF-9052) LoadDistributorFeature not comaptible with JAX-RS subresources
Vadim Beilin created CXF-9052:
-
Summary: LoadDistributorFeature not comaptible with JAX-RS
subresources
Key: CXF-9052
URL: https://issues.apache.org/jira/browse/CXF-9052
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.6.4, 4.0.5, 3.5.9
Reporter: Vadim Beilin
LoadDistributorTargetSelector seems to be confused by subresources.
I'm attaching a test that demonstrates it below.
When no clustering features or FailoverFeature is applied, the client tries to
invoke 'http://localhost:1234/sub/name', as expected. -- `noClustering` and
`failover` pass.
When LoadDistributorFeature is applied, the request is to
'http://localhost:1234/name' (path segment contributed by the root resource is
lost) -- `loadDistributor` fails.
---
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import java.util.List;
import org.apache.cxf.clustering.FailoverFeature;
import org.apache.cxf.clustering.LoadDistributorFeature;
import org.apache.cxf.clustering.SequentialStrategy;
import org.apache.cxf.feature.Feature;
import org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean;
import org.junit.Assert;
import org.junit.Test;
public class ShowBug {
@Test
public void noClustering() {
makeRequest(List.of());
}
@Test
public void failover() {
var failover = new FailoverFeature();
failover.setStrategy(makeStrategy());
makeRequest(List.of(failover));
}
@Test
public void loadDistributor() {
var distro = new LoadDistributorFeature();
distro.setStrategy(makeStrategy());
makeRequest(List.of(distro));
}
private static SequentialStrategy makeStrategy() {
var s = new SequentialStrategy();
s.setAlternateAddresses(List.of("http://localhost:1234";));
return s;
}
private static void makeRequest(List features) {
var fct = new JAXRSClientFactoryBean();
fct.setFeatures(features);
fct.setServiceClass(Root.class);
fct.setAddress("http://localhost:1234";);
try {
fct.create(Root.class).sub().name();
} catch (Exception e) {
Assert.assertTrue(e.getMessage(),
e.getMessage().contains("/sub/name"));
}
}
interface Root {
@Path("/sub") Sub sub();
}
interface Sub {
@GET @Path("/name") String name();
}
}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8624) CXF Extension @QueryParam("") does not parse correctly LocalDate in the bean
[
https://issues.apache.org/jira/browse/CXF-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879974#comment-17879974
]
Andriy Redko commented on CXF-8624:
---
[~Didier Loiseau] the {{JavaTimeTypesParamConverterProvider }}is a regular
JAX-RS {color:#00}{color:#00}ParamConverterProvider{color}{color} (see
please
[https://docs.oracle.com/javaee/7/api/javax/ws/rs/ext/ParamConverterProvider.html])
which converts from String to Java 8 JSR 310 Date Time API. I don't think we
have dedicated documentation for it at the moment.
> Is there a convenient way to generate classes using {{java.time}} without
> rolling your own adapters and bindings file?
What kind of generator you are using? cxf-wadl2java-plugin or something else?
> CXF Extension @QueryParam("") does not parse correctly LocalDate in the bean
>
>
> Key: CXF-8624
> URL: https://issues.apache.org/jira/browse/CXF-8624
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.3.12, 3.4.5
>Reporter: Anthony Durussel
>Assignee: Andriy Redko
>Priority: Major
>
> If you use the @QueryParam("") extension on a method parameter:
> {code:java}
> public void foo(@QueryParam("") Bar bar);
> {code}
> with Bar class equals to :
> {code:java}
> public class Bar {
> private LocalDate date;
> } {code}
> The URL generate from the following method parse the localDate as a standard
> object instead of singleValue as it's done for standard java.util.date
> {code:java}
> org.apache.cxf.jaxrs.utils.InjectionUtils.fillInValuesFromBean(Object,
> String, MultivaluedMap)
> {code}
> {code:java}
> if (isPrimitive(value.getClass()) ||
> Date.class.isAssignableFrom(value.getClass())) {
> values.putSingle(propertyName, value);
> } else if (value.getClass().isEnum()) {
> values.putSingle(propertyName, value.toString());
> } else if (isSupportedCollectionOrArray(value.getClass())) {
> final List theValues;
> if (value.getClass().isArray()) {
> theValues = Arrays.asList((Object[])value);
> } else if (value instanceof Set) {
> theValues = new ArrayList<>((Set)value);
> } else {
> theValues = CastUtils.cast((List)value);
> }
> values.put(propertyName, theValues);
> } else if (Map.class.isAssignableFrom(value.getClass())) {
> if (isSupportedMap(m.getGenericReturnType())) {
> Map map = CastUtils.cast((Map)value);
> for (Map.Entry entry : map.entrySet()) {
> values.add(propertyName + '.' + entry.getKey().toString(),
> entry.getValue().toString());
> }
> }
> } else {
> fillInValuesFromBean(value, propertyName, values);
> }{code}
> Ideally, we should add the LocalDate in the first "if condition" to handle it
> correctly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9051) SwaggerUI broken after migrate from description-swagger to description-openapi-v3
[
https://issues.apache.org/jira/browse/CXF-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry updated CXF-9051:
Description:
I'm upgrading spring boot in my project from 2.7 to 3.0.0
So changed
cxf-rt-rs-service-description-swagger ->
cxf-rt-rs-service-description-openapi-v3
After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
doesn't show my controllers and models anymore("No operations defined in spec").
Manual creating of cxf.endpoint.Server bean also didnt help me.
What I do wrong?
*Code of the problem:*
https://github.com/romanov93/cxf-migtaion/tree/master
Spring Boot 2.7.18 and Swagger2Feature:
!image-2024-09-06-16-59-13-761.png!
Spring Boot 3.0.0 and OpenApiFeature:
!image-2024-09-06-17-01-05-729.png!
Sorry for the stupid question, I don't know where else I can get help with
that. Thank!
-
@Configuration
public class SwaggerConfiguration {
@Bean
public OpenApiFeature swaggerFeature()
{ OpenApiFeature swagger = new OpenApiFeature(); swagger.setVersion("1.0.0");
//swagger.setBasePath("/"); swagger.setPrettyPrint(true);
//swagger.setSchemes(new String[]
{"https", "http"}
);
swagger.setContactEmail("exam...@mail.ru");
swagger.setDescription("Swagger cxf app");
swagger.setTitle("Title");
swagger.setSupportSwaggerUi(true);
swagger.setSwaggerUiConfig(new SwaggerUiConfig().configUrl("/openapi.json"));
//swagger.setHost("localhost:8080");
System.out.println("http://localhost:8080/api-docs?url=/openapi.json";);
return swagger;
}
}
was:
I'm upgrading spring boot in my project from 2.7 to 3.0.0
So changed
cxf-rt-rs-service-description-swagger ->
cxf-rt-rs-service-description-openapi-v3
After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
doesn't show my controllers and models anymore("No operations defined in spec").
Manual creating of cxf.endpoint.Server bean also didnt help me.
What I do wrong?
*Code of the problem:*
[https://github.com/romanov93/cxf-migtaion/tree/master|https://github.com/romanov93/cxf-migtaion/tree/master+]
Spring Boot 2.7.18 and Swagger2Feature:
!image-2024-09-06-16-59-13-761.png!
Spring Boot 3.0.0 and OpenApiFeature:
!image-2024-09-06-17-01-05-729.png!
Sorry for the stupid question, I don't know where else I can get help with
that. Thank!
-
@Configuration
public class SwaggerConfiguration {
@Bean
public OpenApiFeature swaggerFeature()
{ OpenApiFeature swagger = new OpenApiFeature(); swagger.setVersion("1.0.0");
//swagger.setBasePath("/"); swagger.setPrettyPrint(true);
//swagger.setSchemes(new String[]
{"https", "http"}
);
swagger.setContactEmail("exam...@mail.ru");
swagger.setDescription("Swagger cxf app");
swagger.setTitle("Title");
swagger.setSupportSwaggerUi(true);
swagger.setSwaggerUiConfig(new SwaggerUiConfig().configUrl("/openapi.json"));
//swagger.setHost("localhost:8080");
System.out.println("http://localhost:8080/api-docs?url=/openapi.json";);
return swagger;
}
}
> SwaggerUI broken after migrate from description-swagger to
> description-openapi-v3
> -
>
> Key: CXF-9051
> URL: https://issues.apache.org/jira/browse/CXF-9051
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.5
>Reporter: Dmitry
>Priority: Major
> Attachments: image-2024-09-06-16-59-13-761.png,
> image-2024-09-06-17-01-05-729.png
>
>
> I'm upgrading spring boot in my project from 2.7 to 3.0.0
> So changed
> cxf-rt-rs-service-description-swagger ->
> cxf-rt-rs-service-description-openapi-v3
> After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
> doesn't show my controllers and models anymore("No operations defined in
> spec").
> Manual creating of cxf.endpoint.Server bean also didnt help me.
> What I do wrong?
> *Code of the problem:*
> https://github.com/romanov93/cxf-migtaion/tree/master
> Spring Boot 2.7.18 and Swagger2Feature:
> !image-2024-09-06-16-59-13-761.png!
> Spring Boot 3.0.0 and OpenApiFeature:
> !image-2024-09-06-17-01-05-729.png!
> Sorry for the stupid question, I don't know where else I can get help with
> that. Thank!
> -
> @Configuration
> public class SwaggerConfiguration {
> @Bean
>
[jira] [Updated] (CXF-9051) SwaggerUI broken after migrate from description-swagger to description-openapi-v3
[
https://issues.apache.org/jira/browse/CXF-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry updated CXF-9051:
Description:
I'm upgrading spring boot in my project from 2.7 to 3.0.0
So changed
cxf-rt-rs-service-description-swagger ->
cxf-rt-rs-service-description-openapi-v3
After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
doesn't show my controllers and models anymore("No operations defined in spec").
Manual creating of cxf.endpoint.Server bean also didnt help me.
What I do wrong?
*Code of the problem:*
[https://github.com/romanov93/cxf-migtaion/tree/master|https://github.com/romanov93/cxf-migtaion/tree/master+]
Spring Boot 2.7.18 and Swagger2Feature:
!image-2024-09-06-16-59-13-761.png!
Spring Boot 3.0.0 and OpenApiFeature:
!image-2024-09-06-17-01-05-729.png!
Sorry for the stupid question, I don't know where else I can get help with
that. Thank!
-
@Configuration
public class SwaggerConfiguration {
@Bean
public OpenApiFeature swaggerFeature()
{ OpenApiFeature swagger = new OpenApiFeature(); swagger.setVersion("1.0.0");
//swagger.setBasePath("/"); swagger.setPrettyPrint(true);
//swagger.setSchemes(new String[]
{"https", "http"}
);
swagger.setContactEmail("exam...@mail.ru");
swagger.setDescription("Swagger cxf app");
swagger.setTitle("Title");
swagger.setSupportSwaggerUi(true);
swagger.setSwaggerUiConfig(new SwaggerUiConfig().configUrl("/openapi.json"));
//swagger.setHost("localhost:8080");
System.out.println("http://localhost:8080/api-docs?url=/openapi.json";);
return swagger;
}
}
was:
I'm upgrading spring boot in my project from 2.7 to 3.0.0
So changed
cxf-rt-rs-service-description-swagger ->
cxf-rt-rs-service-description-openapi-v3
After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
doesn't show my controllers and models anymore("No operations defined in spec").
Manual creating of cxf.endpoint.Server bean also didnt help me.
What I do wrong?
*Code of the problem:*
+[https://github.com/romanov93/cxf-migtaion/tree/master+]
Spring Boot 2.7.18 and Swagger2Feature:
!image-2024-09-06-16-59-13-761.png!
Spring Boot 3.0.0 and OpenApiFeature:
!image-2024-09-06-17-01-05-729.png!
Sorry for the stupid question, I don't know where else I can get help with
that. Thank!
-
@Configuration
public class SwaggerConfiguration {
@Bean
public OpenApiFeature swaggerFeature()
{ OpenApiFeature swagger = new OpenApiFeature(); swagger.setVersion("1.0.0");
//swagger.setBasePath("/"); swagger.setPrettyPrint(true);
//swagger.setSchemes(new String[]
{"https", "http"}
);
swagger.setContactEmail("exam...@mail.ru");
swagger.setDescription("Swagger cxf app");
swagger.setTitle("Title");
swagger.setSupportSwaggerUi(true);
swagger.setSwaggerUiConfig(new SwaggerUiConfig().configUrl("/openapi.json"));
//swagger.setHost("localhost:8080");
System.out.println("http://localhost:8080/api-docs?url=/openapi.json";);
return swagger;
}
}
> SwaggerUI broken after migrate from description-swagger to
> description-openapi-v3
> -
>
> Key: CXF-9051
> URL: https://issues.apache.org/jira/browse/CXF-9051
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.5
>Reporter: Dmitry
>Priority: Major
> Attachments: image-2024-09-06-16-59-13-761.png,
> image-2024-09-06-17-01-05-729.png
>
>
> I'm upgrading spring boot in my project from 2.7 to 3.0.0
> So changed
> cxf-rt-rs-service-description-swagger ->
> cxf-rt-rs-service-description-openapi-v3
> After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
> doesn't show my controllers and models anymore("No operations defined in
> spec").
> Manual creating of cxf.endpoint.Server bean also didnt help me.
> What I do wrong?
> *Code of the problem:*
> [https://github.com/romanov93/cxf-migtaion/tree/master|https://github.com/romanov93/cxf-migtaion/tree/master+]
> Spring Boot 2.7.18 and Swagger2Feature:
> !image-2024-09-06-16-59-13-761.png!
> Spring Boot 3.0.0 and OpenApiFeature:
> !image-2024-09-06-17-01-05-729.png!
> Sorry for the stupid question, I don't know where else I can get help with
> that. Thank!
> -
> @Configuration
> public class
[jira] [Updated] (CXF-9051) SwaggerUI broken after migrate from description-swagger to description-openapi-v3
[
https://issues.apache.org/jira/browse/CXF-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry updated CXF-9051:
Description:
I'm upgrading spring boot in my project from 2.7 to 3.0.0
So changed
cxf-rt-rs-service-description-swagger ->
cxf-rt-rs-service-description-openapi-v3
After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
doesn't show my controllers and models anymore("No operations defined in spec").
Manual creating of cxf.endpoint.Server bean also didnt help me.
What I do wrong?
*Code of the problem:*
+[https://github.com/romanov93/cxf-migtaion/tree/master+]
Spring Boot 2.7.18 and Swagger2Feature:
!image-2024-09-06-16-59-13-761.png!
Spring Boot 3.0.0 and OpenApiFeature:
!image-2024-09-06-17-01-05-729.png!
Sorry for the stupid question, I don't know where else I can get help with
that. Thank!
-
@Configuration
public class SwaggerConfiguration {
@Bean
public OpenApiFeature swaggerFeature()
{ OpenApiFeature swagger = new OpenApiFeature(); swagger.setVersion("1.0.0");
//swagger.setBasePath("/"); swagger.setPrettyPrint(true);
//swagger.setSchemes(new String[]
{"https", "http"}
);
swagger.setContactEmail("exam...@mail.ru");
swagger.setDescription("Swagger cxf app");
swagger.setTitle("Title");
swagger.setSupportSwaggerUi(true);
swagger.setSwaggerUiConfig(new SwaggerUiConfig().configUrl("/openapi.json"));
//swagger.setHost("localhost:8080");
System.out.println("http://localhost:8080/api-docs?url=/openapi.json";);
return swagger;
}
}
was:
I'm upgrading spring boot in my project from 2.7 to 3.0.0
So changed
cxf-rt-rs-service-description-swagger ->
cxf-rt-rs-service-description-openapi-v3
After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
doesn't show my controllers and models anymore("No operations defined in spec").
Manual creating of cxf.endpoint.Server bean also didnt help me.
What I do wrong?
*Code of the problem:*
+[https://github.com/romanov93/cxf-migtaion/tree/master+]
Spring Boot 2.7.18 and Swagger2Feature:
!image-2024-09-06-16-59-13-761.png!
Spring Boot 3.0.0 and OpenApiFeature:
!image-2024-09-06-17-01-05-729.png!
Sorry for the stupid question, I don't know where else I can get help with
that. Thank!
-
@Configuration
public class SwaggerConfiguration {
@Bean
public OpenApiFeature swaggerFeature()
{ OpenApiFeature swagger = new OpenApiFeature(); swagger.setVersion("1.0.0");
//swagger.setBasePath("/"); swagger.setPrettyPrint(true);
//swagger.setSchemes(new String[]
{"https", "http"}
);
swagger.setContactEmail("exam...@mail.ru");
swagger.setDescription("Swagger cxf app");
swagger.setTitle("Title");
swagger.setSupportSwaggerUi(true);
swagger.setSwaggerUiConfig(new SwaggerUiConfig().configUrl("/openapi.json"));
//swagger.setHost("localhost:8080");
System.out.println("http://localhost:8080/api-docs?url=/openapi.json";);
return swagger;
}
// @Bean
// public Server jaxRsServer(Bus bus, UserController userController){
// final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
// factory.setServiceBean(userController);
// factory.setProvider(new JacksonJsonProvider());
// factory.setFeatures(Arrays.asList(swaggerFeature()));
// factory.setBus(bus); // factory.setAddress("/");
// return factory.create();
// }
}
> SwaggerUI broken after migrate from description-swagger to
> description-openapi-v3
> -
>
> Key: CXF-9051
> URL: https://issues.apache.org/jira/browse/CXF-9051
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.5
>Reporter: Dmitry
>Priority: Major
> Attachments: image-2024-09-06-16-59-13-761.png,
> image-2024-09-06-17-01-05-729.png
>
>
> I'm upgrading spring boot in my project from 2.7 to 3.0.0
> So changed
> cxf-rt-rs-service-description-swagger ->
> cxf-rt-rs-service-description-openapi-v3
> After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
> doesn't show my controllers and models anymore("No operations defined in
> spec").
> Manual creating of cxf.endpoint.Server bean also didnt help me.
> What I do wrong?
> *Code of the problem:*
> +[https://github.com/romanov93/cxf-migtaion/tree/master+]
> Spring Boot 2.7.18 and Swagger2Feature:
> !image-2024-09-06-16-59-13-761.png!
> Sp
[jira] [Updated] (CXF-9051) SwaggerUI broken after migrate from description-swagger to description-openapi-v3
[
https://issues.apache.org/jira/browse/CXF-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry updated CXF-9051:
Description:
I'm upgrading spring boot in my project from 2.7 to 3.0.0
So changed
cxf-rt-rs-service-description-swagger ->
cxf-rt-rs-service-description-openapi-v3
After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
doesn't show my controllers and models anymore("No operations defined in spec").
Manual creating of cxf.endpoint.Server bean also didnt help me.
What I do wrong?
*Code of the problem:*
+[https://github.com/romanov93/cxf-migtaion/tree/master+]
Spring Boot 2.7.18 and Swagger2Feature:
!image-2024-09-06-16-59-13-761.png!
Spring Boot 3.0.0 and OpenApiFeature:
!image-2024-09-06-17-01-05-729.png!
Sorry for the stupid question, I don't know where else I can get help with
that. Thank!
-
@Configuration
public class SwaggerConfiguration {
@Bean
public OpenApiFeature swaggerFeature()
{ OpenApiFeature swagger = new OpenApiFeature(); swagger.setVersion("1.0.0");
//swagger.setBasePath("/"); swagger.setPrettyPrint(true);
//swagger.setSchemes(new String[]\\{"https", "http"}
);
swagger.setContactEmail("exam...@mail.ru");
swagger.setDescription("Swagger cxf app");
swagger.setTitle("Title");
swagger.setSupportSwaggerUi(true);
swagger.setSwaggerUiConfig(new SwaggerUiConfig().configUrl("/openapi.json"));
//swagger.setHost("localhost:8080");
System.out.println("http://localhost:8080/api-docs?url=/openapi.json";);
return swagger;
}
// @Bean
// public Server jaxRsServer(Bus bus, UserController userController)
{ // final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean(); // //
factory.setServiceBean(userController); // factory.setProvider(new
JacksonJsonProvider()); //
factory.setFeatures(Arrays.asList(swaggerFeature())); // factory.setBus(bus);
// factory.setAddress("/"); // return factory.create(); // }
}
was:
I'm upgrading spring boot in my project from 2.7 to 3.0.0
So changed
cxf-rt-rs-service-description-swagger ->
cxf-rt-rs-service-description-openapi-v3
After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
doesn't show my controllers and models anymore("No operations defined in spec").
Manual creating of cxf.endpoint.Server bean also didnt help me.
What I do wrong?
*Code of the problem:*
+https://github.com/romanov93/cxf-migtaion/tree/master+
Spring Boot 2.7.18 and Swagger2Feature:
!image-2024-09-06-16-59-13-761.png!
Spring Boot 3.0.0 and OpenApiFeature:
!image-2024-09-06-17-01-05-729.png!
Sorry for the stupid question, I don't know where else I can get help with
that. Thank!
> SwaggerUI broken after migrate from description-swagger to
> description-openapi-v3
> -
>
> Key: CXF-9051
> URL: https://issues.apache.org/jira/browse/CXF-9051
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.5
>Reporter: Dmitry
>Priority: Major
> Attachments: image-2024-09-06-16-59-13-761.png,
> image-2024-09-06-17-01-05-729.png
>
>
> I'm upgrading spring boot in my project from 2.7 to 3.0.0
> So changed
> cxf-rt-rs-service-description-swagger ->
> cxf-rt-rs-service-description-openapi-v3
> After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
> doesn't show my controllers and models anymore("No operations defined in
> spec").
> Manual creating of cxf.endpoint.Server bean also didnt help me.
> What I do wrong?
> *Code of the problem:*
> +[https://github.com/romanov93/cxf-migtaion/tree/master+]
> Spring Boot 2.7.18 and Swagger2Feature:
> !image-2024-09-06-16-59-13-761.png!
> Spring Boot 3.0.0 and OpenApiFeature:
> !image-2024-09-06-17-01-05-729.png!
> Sorry for the stupid question, I don't know where else I can get help with
> that. Thank!
> -
> @Configuration
> public class SwaggerConfiguration {
> @Bean
> public OpenApiFeature swaggerFeature()
> { OpenApiFeature swagger = new OpenApiFeature(); swagger.setVersion("1.0.0");
> //swagger.setBasePath("/"); swagger.setPrettyPrint(true);
> //swagger.setSchemes(new String[]\\{"https", "http"}
> );
> swagger.setContactEmail("exam...@mail.ru");
> swagger.setDescription("Swagger cxf app");
> swagger.setTitle("Title");
> swa
[jira] [Updated] (CXF-9051) SwaggerUI broken after migrate from
[
https://issues.apache.org/jira/browse/CXF-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry updated CXF-9051:
Description:
I'm upgrading spring boot in my project from 2.7 to 3.0.0
So changed
cxf-rt-rs-service-description-swagger ->
cxf-rt-rs-service-description-openapi-v3
After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
doesn't show my controllers and models anymore("No operations defined in spec").
Manual creating of cxf.endpoint.Server bean also didnt help me.
What I do wrong?
*Code of the problem:*
[https://github.com/romanov93/cxf-migtaion/blob/master/src/main/java/com/example/cxfmigration/SwaggerConfiguration.java]
Spring Boot 2.7.18 and Swagger2Feature:
!image-2024-09-06-16-59-13-761.png!
Spring Boot 3.0.0 and OpenApiFeature:
!image-2024-09-06-17-01-05-729.png!
Sorry for the stupid question, I don't know where else I can get help with
that. Thank!
was:
I'm upgrading spring boot in my project from 2.7 to 3.0.0
So changed
cxf-rt-rs-service-description-swagger ->
cxf-rt-rs-service-description-openapi-v3
After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
doesn't show my controllers and models anymore("No operations defined in spec").
Manual creating of cxf.endpoint.Server bean also didnt help me.
What I do wrong?
[https://github.com/romanov93/cxf-migtaion/blob/master/src/main/java/com/example/cxfmigration/SwaggerConfiguration.java]
Spring Boot 2.7.18 and Swagger2Feature:
!image-2024-09-06-16-59-13-761.png!
Spring Boot 3.0.0 and OpenApiFeature:
!image-2024-09-06-17-01-05-729.png!
> SwaggerUI broken after migrate from
>
>
> Key: CXF-9051
> URL: https://issues.apache.org/jira/browse/CXF-9051
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.5
> Environment: @Configuration
> public class SwaggerConfiguration {
> @Bean
> public OpenApiFeature swaggerFeature() {
> OpenApiFeature swagger = new OpenApiFeature();
> swagger.setVersion("1.0.0");
> //swagger.setBasePath("/");
> swagger.setPrettyPrint(true);
> //swagger.setSchemes(new String[]\{"https", "http"});
> swagger.setContactEmail("exam...@mail.ru");
> swagger.setDescription("Swagger cxf app");
> swagger.setTitle("Title");
> swagger.setSupportSwaggerUi(true);
> swagger.setSwaggerUiConfig(new SwaggerUiConfig().configUrl("/openapi.json"));
> //swagger.setHost("localhost:8080");
> System.out.println("http://localhost:8080/api-docs?url=/openapi.json";);
> return swagger;
> }
> // @Bean
> // public Server jaxRsServer(Bus bus, UserController userController) {
> // final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
> //
> // factory.setServiceBean(userController);
> // factory.setProvider(new JacksonJsonProvider());
> // factory.setFeatures(Arrays.asList(swaggerFeature()));
> // factory.setBus(bus);
> // factory.setAddress("/");
> // return factory.create();
> // }
> }
>Reporter: Dmitry
>Priority: Major
> Attachments: image-2024-09-06-16-59-13-761.png,
> image-2024-09-06-17-01-05-729.png
>
>
> I'm upgrading spring boot in my project from 2.7 to 3.0.0
> So changed
> cxf-rt-rs-service-description-swagger ->
> cxf-rt-rs-service-description-openapi-v3
> After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
> doesn't show my controllers and models anymore("No operations defined in
> spec").
> Manual creating of cxf.endpoint.Server bean also didnt help me.
> What I do wrong?
> *Code of the problem:*
> [https://github.com/romanov93/cxf-migtaion/blob/master/src/main/java/com/example/cxfmigration/SwaggerConfiguration.java]
> Spring Boot 2.7.18 and Swagger2Feature:
> !image-2024-09-06-16-59-13-761.png!
> Spring Boot 3.0.0 and OpenApiFeature:
> !image-2024-09-06-17-01-05-729.png!
> Sorry for the stupid question, I don't know where else I can get help with
> that. Thank!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-9051) SwaggerUI broken after migrate from
Dmitry created CXF-9051:
---
Summary: SwaggerUI broken after migrate from
Key: CXF-9051
URL: https://issues.apache.org/jira/browse/CXF-9051
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 4.0.5
Environment: @Configuration
public class SwaggerConfiguration {
@Bean
public OpenApiFeature swaggerFeature() {
OpenApiFeature swagger = new OpenApiFeature();
swagger.setVersion("1.0.0");
//swagger.setBasePath("/");
swagger.setPrettyPrint(true);
//swagger.setSchemes(new String[]\{"https", "http"});
swagger.setContactEmail("exam...@mail.ru");
swagger.setDescription("Swagger cxf app");
swagger.setTitle("Title");
swagger.setSupportSwaggerUi(true);
swagger.setSwaggerUiConfig(new SwaggerUiConfig().configUrl("/openapi.json"));
//swagger.setHost("localhost:8080");
System.out.println("http://localhost:8080/api-docs?url=/openapi.json";);
return swagger;
}
// @Bean
// public Server jaxRsServer(Bus bus, UserController userController) {
// final JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
//
// factory.setServiceBean(userController);
// factory.setProvider(new JacksonJsonProvider());
// factory.setFeatures(Arrays.asList(swaggerFeature()));
// factory.setBus(bus);
// factory.setAddress("/");
// return factory.create();
// }
}
Reporter: Dmitry
Attachments: image-2024-09-06-16-59-13-761.png,
image-2024-09-06-17-01-05-729.png
I'm upgrading spring boot in my project from 2.7 to 3.0.0
So changed
cxf-rt-rs-service-description-swagger ->
cxf-rt-rs-service-description-openapi-v3
After that I try just replace Swagger2Feature to OpenApiFuture and swagger-ui
doesn't show my controllers and models anymore("No operations defined in spec").
Manual creating of cxf.endpoint.Server bean also didnt help me.
What I do wrong?
[https://github.com/romanov93/cxf-migtaion/blob/master/src/main/java/com/example/cxfmigration/SwaggerConfiguration.java]
Spring Boot 2.7.18 and Swagger2Feature:
!image-2024-09-06-16-59-13-761.png!
Spring Boot 3.0.0 and OpenApiFeature:
!image-2024-09-06-17-01-05-729.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CXF-9050) Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
[
https://issues.apache.org/jira/browse/CXF-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko closed CXF-9050.
-
Resolution: Won't Fix
> Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
>
>
> Key: CXF-9050
> URL: https://issues.apache.org/jira/browse/CXF-9050
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.6.4
>Reporter: Dmitry
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> cxf-rt-rs-service-description-swagger depends on jakarta.ws.rs.core
> But *DefaultApplicationFactory.class* have {*}javax{*}.ws.rs.core.Application
> import instead of jakarta.
> As a result, an error occurs when
> org.apache.cxf.jaxrs.spring.SpringComponentScanServer.class try to call
> .createServer() method:
> """
> Error creating bean with name 'jaxRsServer' defined in class path resource
> [org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class]: Failed to
> instantiate [org.apache.cxf.endpoint.Server]: *Factory method 'jaxRsServer'
> threw exception with message: javax/ws/rs/core/Application*
> """
> _Thank Apache team for your work and support!_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-9050) Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
[
https://issues.apache.org/jira/browse/CXF-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878357#comment-17878357
]
Andriy Redko edited comment on CXF-9050 at 8/31/24 3:38 PM:
[~this.romanov] Apache CXF 3.6.x branch uses 'javax.' ** namespaces (moreover,
Swagger Core 1.6.x only works with 'javax.'), please check your dependencies.
was (Author: reta):
[~this.romanov] Apache CXF 3.6.x branch uses `javax.*` namespaces (moreover,
Swagger Core 1.6.x only works with `javax.*`), please check your dependencies.
> Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
>
>
> Key: CXF-9050
> URL: https://issues.apache.org/jira/browse/CXF-9050
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.6.4
>Reporter: Dmitry
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> cxf-rt-rs-service-description-swagger depends on jakarta.ws.rs.core
> But *DefaultApplicationFactory.class* have {*}javax{*}.ws.rs.core.Application
> import instead of jakarta.
> As a result, an error occurs when
> org.apache.cxf.jaxrs.spring.SpringComponentScanServer.class try to call
> .createServer() method:
> """
> Error creating bean with name 'jaxRsServer' defined in class path resource
> [org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class]: Failed to
> instantiate [org.apache.cxf.endpoint.Server]: *Factory method 'jaxRsServer'
> threw exception with message: javax/ws/rs/core/Application*
> """
> _Thank Apache team for your work and support!_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9050) Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
[
https://issues.apache.org/jira/browse/CXF-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878357#comment-17878357
]
Andriy Redko commented on CXF-9050:
---
[~this.romanov] Apache CXF 3.6.x branch uses `javax.*` namespaces (moreover,
Swagger Core 1.6.x only works with `javax.*`), please check your dependencies.
> Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
>
>
> Key: CXF-9050
> URL: https://issues.apache.org/jira/browse/CXF-9050
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.6.4
>Reporter: Dmitry
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> cxf-rt-rs-service-description-swagger depends on jakarta.ws.rs.core
> But *DefaultApplicationFactory.class* have {*}javax{*}.ws.rs.core.Application
> import instead of jakarta.
> As a result, an error occurs when
> org.apache.cxf.jaxrs.spring.SpringComponentScanServer.class try to call
> .createServer() method:
> """
> Error creating bean with name 'jaxRsServer' defined in class path resource
> [org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class]: Failed to
> instantiate [org.apache.cxf.endpoint.Server]: *Factory method 'jaxRsServer'
> threw exception with message: javax/ws/rs/core/Application*
> """
> _Thank Apache team for your work and support!_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9050) Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
[
https://issues.apache.org/jira/browse/CXF-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry updated CXF-9050:
Description:
cxf-rt-rs-service-description-swagger depends on jakarta.ws.rs.core
But *DefaultApplicationFactory.class* have {*}javax{*}.ws.rs.core.Application
import instead of jakarta.
As a result, an error occurs when
org.apache.cxf.jaxrs.spring.SpringComponentScanServer.class try to call
.createServer() method:
"""
Error creating bean with name 'jaxRsServer' defined in class path resource
[org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class]: Failed to
instantiate [org.apache.cxf.endpoint.Server]: *Factory method 'jaxRsServer'
threw exception with message: javax/ws/rs/core/Application*
"""
_Thank Apache team for your work and support!_
was:
cxf-rt-rs-service-description-swagger depends on jakarta.ws.rs.core
But DefaultApplicationFactory.class have {*}javax{*}.ws.rs.core.Application
import instead of jakarta.
As a result, an error occurs when
org.apache.cxf.jaxrs.spring.SpringComponentScanServer.class try to call
.createServer() method:
"""
Error creating bean with name 'jaxRsServer' defined in class path resource
[org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class]: Failed to
instantiate [org.apache.cxf.endpoint.Server]: Factory method 'jaxRsServer'
threw exception with message: javax/ws/rs/core/Application
"""
_Thank Apache team for your work and support!_
> Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
> ----
>
> Key: CXF-9050
> URL: https://issues.apache.org/jira/browse/CXF-9050
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.6.4
>Reporter: Dmitry
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> cxf-rt-rs-service-description-swagger depends on jakarta.ws.rs.core
> But *DefaultApplicationFactory.class* have {*}javax{*}.ws.rs.core.Application
> import instead of jakarta.
> As a result, an error occurs when
> org.apache.cxf.jaxrs.spring.SpringComponentScanServer.class try to call
> .createServer() method:
> """
> Error creating bean with name 'jaxRsServer' defined in class path resource
> [org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class]: Failed to
> instantiate [org.apache.cxf.endpoint.Server]: *Factory method 'jaxRsServer'
> threw exception with message: javax/ws/rs/core/Application*
> """
> _Thank Apache team for your work and support!_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9050) Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
[
https://issues.apache.org/jira/browse/CXF-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry updated CXF-9050:
Priority: Major (was: Minor)
> Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
>
>
> Key: CXF-9050
> URL: https://issues.apache.org/jira/browse/CXF-9050
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.6.4
>Reporter: Dmitry
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> cxf-rt-rs-service-description-swagger depends on jakarta.ws.rs.core
> But *DefaultApplicationFactory.class* have {*}javax{*}.ws.rs.core.Application
> import instead of jakarta.
> As a result, an error occurs when
> org.apache.cxf.jaxrs.spring.SpringComponentScanServer.class try to call
> .createServer() method:
> """
> Error creating bean with name 'jaxRsServer' defined in class path resource
> [org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class]: Failed to
> instantiate [org.apache.cxf.endpoint.Server]: *Factory method 'jaxRsServer'
> threw exception with message: javax/ws/rs/core/Application*
> """
> _Thank Apache team for your work and support!_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9050) Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
[ https://issues.apache.org/jira/browse/CXF-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry updated CXF-9050: Description: cxf-rt-rs-service-description-swagger depends on jakarta.ws.rs.core But DefaultApplicationFactory.class have javax.ws.rs.core.Application import instead of javax. As a result, an error occurs when org.apache.cxf.jaxrs.spring.SpringComponentScanServer.class try to call .createServer() method: """ Error creating bean with name 'jaxRsServer' defined in class path resource [org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class]: Failed to instantiate [org.apache.cxf.endpoint.Server]: Factory method 'jaxRsServer' threw exception with message: javax/ws/rs/core/Application """ _Thank Apache team for your work and support!_ was: cxf-rt-rs-service-description-swagger imports jakarta.ws.rs.core But DefaultApplicationFactory.class have javax.ws.rs.core.Application import instead of javax. As a result, an error occurs when org.apache.cxf.jaxrs.spring.SpringComponentScanServer.class try to call .createServer() method: """ Error creating bean with name 'jaxRsServer' defined in class path resource [org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class]: Failed to instantiate [org.apache.cxf.endpoint.Server]: Factory method 'jaxRsServer' threw exception with message: javax/ws/rs/core/Application """ _Thank Apache team for your work and support!_ > Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import > ---- > > Key: CXF-9050 > URL: https://issues.apache.org/jira/browse/CXF-9050 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.6.4 >Reporter: Dmitry >Priority: Minor > Original Estimate: 1h > Remaining Estimate: 1h > > cxf-rt-rs-service-description-swagger depends on jakarta.ws.rs.core > But DefaultApplicationFactory.class have javax.ws.rs.core.Application import > instead of javax. > As a result, an error occurs when > org.apache.cxf.jaxrs.spring.SpringComponentScanServer.class try to call > .createServer() method: > """ > Error creating bean with name 'jaxRsServer' defined in class path resource > [org/apache/cxf/jaxrs/spring/SpringComponentScanServer.class]: Failed to > instantiate [org.apache.cxf.endpoint.Server]: Factory method 'jaxRsServer' > threw exception with message: javax/ws/rs/core/Application > """ > _Thank Apache team for your work and support!_ -- This message was sent by Atlassian Jira (v8.20.10#820010)
