[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)
[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 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 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 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!_ 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 SpringComponentScanServer 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 > 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 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!_ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-9050) Apache CXF JAX RS Service Description Swagger » 3.6.4 | Wrong import
Dmitry created CXF-9050: --- Summary: 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 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 SpringComponentScanServer 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 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878252#comment-17878252 ] Andriy Redko commented on CXF-8931: --- Hi [~bodhione] , yes > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878204#comment-17878204 ] John Tal commented on CXF-8931: --- Hi [~reta] - are we still thinking these versions for solution release/packaging? -> [4.1.0|https://issues.apache.org/jira/issues/?jql=project+%3D+CXF+AND+fixVersion+%3D+4.1.0], [3.6.5|https://issues.apache.org/jira/issues/?jql=project+%3D+CXF+AND+fixVersion+%3D+3.6.5], [4.0.6|https://issues.apache.org/jira/issues/?jql=project+%3D+CXF+AND+fixVersion+%3D+4.0.6] > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-9049) JAXRSUtils: Logging Improvements
Kai Zander created CXF-9049:
---
Summary: JAXRSUtils: Logging Improvements
Key: CXF-9049
URL: https://issues.apache.org/jira/browse/CXF-9049
Project: CXF
Issue Type: Wish
Components: JAX-RS
Affects Versions: 4.0.5
Reporter: Kai Zander
Currently, during a write error _of any kind_, {{JAXRSUtils}} logs ERRORs like
this:
{code:none}
JAXRSUtils - Problem with writing the data, class com.acme.MyResponseType,
ContentType: application/json
{code}
We have the following issues with this:
# Because there's no stack trace, this error doesn't help us in identifying
what went wrong.
# The log level is always ERROR, even for errors that aren't actionable, like
when the client aborts the request before the server could send the response.
This issue is related to CXF-7389, with the distinction of that issue being
about log levels for API responses with HTTP error status codes. But here, I'd
like to request a similar improvement but for response handling errors. This
could allow us to maybe configure a property {{IOException.class.getName() +
".log.level"}} to reduce the log level for exceptions of our choosing.
The logic that checks for these properties should then have to consider the
type hierarchy to properly deal with subclasses of {{IOException}}, something
like this snippet:
{code:java}
Level determineLogLevel(Exception ex, Message m) {
Class exType = ex.getClass();
do {
String key = exType.getName() + ".log.level";
if (m.containsKey(key)) {
return Level.parseLevel(m.get(key).toString());
}
exType = exType.getSuperClass();
} while (exType != Object.class);
return someDefaultLevelPossiblyError;
}
{code}
--
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/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-RC4)] - [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/#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://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/08/01/hibernate-validator-9-0-0-Beta2/)] - Hibernate 7 ([https://in.relation.to/2024
[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/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-RC4)] - [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://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([https://in.relation.to/2024/08/01/hibernate
[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/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-RC4)] - [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) 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://activemq.apache.org/activemq-600-release]) - Hibernate Validator 9 ([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
[jira] [Commented] (CXF-8629) AsyncHTTPConduit (hc5) should support chunked request / response
[ https://issues.apache.org/jira/browse/CXF-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876439#comment-17876439 ] Andriy Redko commented on CXF-8629: --- [~bocamel] I have working on this issue but I cannot reproduce this double logging (for response) problem you've been running into. Would you be able to supply a reproducer (project or test case, whatever is easier for you). Thank you. > AsyncHTTPConduit (hc5) should support chunked request / response > > > Key: CXF-8629 > URL: https://issues.apache.org/jira/browse/CXF-8629 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.0, 3.4.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.5.10, 3.6.5, 4.0.6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9048) Failed integration tests with upcomming santuario and wss4j library
[ https://issues.apache.org/jira/browse/CXF-9048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-9048: -- Affects Version/s: (was: 4.1.0) > Failed integration tests with upcomming santuario and wss4j library > --- > > Key: CXF-9048 > URL: https://issues.apache.org/jira/browse/CXF-9048 > Project: CXF > Issue Type: Test > Components: WS-* Components >Reporter: Joze Rihtarsic >Priority: Major > Fix For: 4.1.0 > > > The latest release of the Santuario library (version 3.0.5) and WSS4j > (version 3.0.4) introduces support for the HKDF derivation function, which is > now the default for encryption key derivation when using the Key Agreement > method. However, the integration tests currently default to the older > ConcatKDF. This ticket aims to align the integration tests with the updated > default behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876294#comment-17876294 ] Andriy Redko commented on CXF-8931: --- Thanks for looking [~bodhione] . Right, the `reset()` is not needed since the stream is buffered and consumed only once, thanks! > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9048) Failed integration tests with upcomming santuario and wss4j library
[ https://issues.apache.org/jira/browse/CXF-9048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876295#comment-17876295 ] Andriy Redko commented on CXF-9048: --- Thanks [~jrihtarsic] (I just cleared 4.1.0 affected version since it is not released yet) > Failed integration tests with upcomming santuario and wss4j library > --- > > Key: CXF-9048 > URL: https://issues.apache.org/jira/browse/CXF-9048 > Project: CXF > Issue Type: Test > Components: WS-* Components >Reporter: Joze Rihtarsic >Priority: Major > Fix For: 4.1.0 > > > The latest release of the Santuario library (version 3.0.5) and WSS4j > (version 3.0.4) introduces support for the HKDF derivation function, which is > now the default for encryption key derivation when using the Key Agreement > method. However, the integration tests currently default to the older > ConcatKDF. This ticket aims to align the integration tests with the updated > default behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876282#comment-17876282 ] John Tal commented on CXF-8931: --- [~reta] - Hi, I looked in reta CXF-8931, in HttpClientHTTPConduit does the method public long contentLength() need a .reset method on the stream? Also, whether or not the stream supports reset is in https://docs.oracle.com/javase/8/docs/api/java/io/InputStream.html#markSupported–, but, it seems you are getting the length on CloseableByteArrayOutputStream, so you are likely using a smarter method. If you TCs support/show HTTP headers as chunked, an then when setting chunked(false) not having chunked, then from what I can see, you are probably good here. Other eyes may be needed. thanks! > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9048) Failed integration tests with upcomming santuario and wss4j library
[ https://issues.apache.org/jira/browse/CXF-9048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joze Rihtarsic updated CXF-9048: Description: The latest release of the Santuario library (version 3.0.5) and WSS4j (version 3.0.4) introduces support for the HKDF derivation function, which is now the default for encryption key derivation when using the Key Agreement method. However, the integration tests currently default to the older ConcatKDF. This ticket aims to align the integration tests with the updated default behavior. (was: New version of the santuario library has a supports HKDF derivation function, which is set as default when Key Agreement method is used for encryption key derivation. The integration tests still expect old ConcatKDF as default. The purpose of this ticket is to synchronize the tests with expected behavior.) > Failed integration tests with upcomming santuario and wss4j library > --- > > Key: CXF-9048 > URL: https://issues.apache.org/jira/browse/CXF-9048 > Project: CXF > Issue Type: Test > Components: WS-* Components >Affects Versions: 4.1.0 >Reporter: Joze Rihtarsic >Priority: Major > Fix For: 4.1.0 > > > The latest release of the Santuario library (version 3.0.5) and WSS4j > (version 3.0.4) introduces support for the HKDF derivation function, which is > now the default for encryption key derivation when using the Key Agreement > method. However, the integration tests currently default to the older > ConcatKDF. This ticket aims to align the integration tests with the updated > default behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-9048) Failed integration tests with upcomming santuario and wss4j library
Joze Rihtarsic created CXF-9048: --- Summary: Failed integration tests with upcomming santuario and wss4j library Key: CXF-9048 URL: https://issues.apache.org/jira/browse/CXF-9048 Project: CXF Issue Type: Test Components: WS-* Components Affects Versions: 4.1.0 Reporter: Joze Rihtarsic Fix For: 4.1.0 New version of the santuario library has a supports HKDF derivation function, which is set as default when Key Agreement method is used for encryption key derivation. The integration tests still expect old ConcatKDF as default. The purpose of this ticket is to synchronize the tests with expected behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876042#comment-17876042 ] Andriy Redko commented on CXF-8931: --- [~bodhione] could you please give [https://github.com/apache/cxf/pull/2018] a try? Thank you. > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876022#comment-17876022 ] John Tal edited comment on CXF-8931 at 8/22/24 4:11 PM: [~reta] FYI - cxf 3.5.8 works (supports chunking correctly). If you really want to know what changed before doing the fix, can you check the diffs/commits between 3.5.8 and 3.6.3 ? was (Author: JIRAUSER303766): [~reta] FYI - cxf 3.5.8 works (supports). If you really want to know what changed before doing the fix, can you check the diffs/commits between 3.5.8 and 3.6.3 ? > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876022#comment-17876022 ] John Tal commented on CXF-8931: --- [~reta] FYI - cxf 3.5.8 works (supports). If you really want to know what changed before doing the fix, can you check the diffs/commits between 3.5.8 and 3.6.3 ? > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8931) HttpClientHTTPConduit can't disable the http chunk mode
[ https://issues.apache.org/jira/browse/CXF-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876019#comment-17876019 ] John Tal commented on CXF-8931: --- [~reta] - Hi, checking on whether you are planning to move foreward with a fix I had outlined? > HttpClientHTTPConduit can't disable the http chunk mode > --- > > Key: CXF-8931 > URL: https://issues.apache.org/jira/browse/CXF-8931 > Project: CXF > Issue Type: Bug >Reporter: Jim Ma >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.6.5, 4.0.6 > > > This works with URLConnectionHttpConduit, but this doesn't work with the new > HttpClientHTTPConduit. When set the HttpClientPolicy.setAllowChunking(false) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8629) AsyncHTTPConduit (hc5) should support chunked request / response
[ https://issues.apache.org/jira/browse/CXF-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8629: -- Fix Version/s: 4.1.0 > AsyncHTTPConduit (hc5) should support chunked request / response > > > Key: CXF-8629 > URL: https://issues.apache.org/jira/browse/CXF-8629 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.0, 3.4.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0, 3.5.10, 3.6.5, 4.0.6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXFXJC-47) XJC DefaultValue plugin uses JAXBElement that does not have a default constructor
[
https://issues.apache.org/jira/browse/CXFXJC-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXFXJC-47:
---
Fix Version/s: 4.0.2
(was: 4.0.1)
> XJC DefaultValue plugin uses JAXBElement that does not have a default
> constructor
> -
>
> Key: CXFXJC-47
> URL: https://issues.apache.org/jira/browse/CXFXJC-47
> Project: CXF XJC Utils
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.1.0, 3.3.4, 4.0.2
>
>
> As reported by the user (see please
> https://github.com/apache/cxf-xjc-utils/pull/129):
> We've found a minor bug when using extensions and substitiongroups.
> The defaultvalue-plugin generates a {{new JAXBElement}} expression, which
> isn't valid java code, as JAXBElement does not have a default constructor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9047) http-undertow transport: enable to specify CipherSuites
[ https://issues.apache.org/jira/browse/CXF-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang resolved CXF-9047. --- Resolution: Fixed > http-undertow transport: enable to specify CipherSuites > --- > > Key: CXF-9047 > URL: https://issues.apache.org/jira/browse/CXF-9047 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 4.1.0, 3.5.10, 3.6.5, 4.0.6 > > > To make it the same behavior as http-jetty transport -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9047) http-undertow transport: enable to specify CipherSuites
[ https://issues.apache.org/jira/browse/CXF-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang updated CXF-9047: -- Fix Version/s: 4.1.0 3.5.10 3.6.5 4.0.6 > http-undertow transport: enable to specify CipherSuites > --- > > Key: CXF-9047 > URL: https://issues.apache.org/jira/browse/CXF-9047 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 4.1.0, 3.5.10, 3.6.5, 4.0.6 > > > To make it the same behavior as http-jetty transport -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-9047) http-undertow transport: enable to specify CipherSuites
Freeman Yue Fang created CXF-9047: - Summary: http-undertow transport: enable to specify CipherSuites Key: CXF-9047 URL: https://issues.apache.org/jira/browse/CXF-9047 Project: CXF Issue Type: Improvement Components: Transports Reporter: Freeman Yue Fang To make it the same behavior as http-jetty transport -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-9047) http-undertow transport: enable to specify CipherSuites
[ https://issues.apache.org/jira/browse/CXF-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang reassigned CXF-9047: - Assignee: Freeman Yue Fang > http-undertow transport: enable to specify CipherSuites > --- > > Key: CXF-9047 > URL: https://issues.apache.org/jira/browse/CXF-9047 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > > To make it the same behavior as http-jetty transport -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8840) Introduce HTTP/2 Transport: client-side support using JDK's HttpClient
[ https://issues.apache.org/jira/browse/CXF-8840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873749#comment-17873749 ] Andriy Redko commented on CXF-8840: --- [~dmiro] Please check https://github.com/apache/cxf/commit/9b36a4bc996615e0ed02795c74167586a2bb11df > Introduce HTTP/2 Transport: client-side support using JDK's HttpClient > --- > > Key: CXF-8840 > URL: https://issues.apache.org/jira/browse/CXF-8840 > Project: CXF > Issue Type: Sub-task >Affects Versions: 4.0.0 >Reporter: Andriy Redko >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.6.0, 4.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8840) Introduce HTTP/2 Transport: client-side support using JDK's HttpClient
[ https://issues.apache.org/jira/browse/CXF-8840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8840: -- Affects Version/s: (was: 3.6.0) > Introduce HTTP/2 Transport: client-side support using JDK's HttpClient > --- > > Key: CXF-8840 > URL: https://issues.apache.org/jira/browse/CXF-8840 > Project: CXF > Issue Type: Sub-task >Affects Versions: 4.0.0 >Reporter: Andriy Redko >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.6.0, 4.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
