[jira] [Resolved] (CXF-9014) org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH OpenJDK
[ https://issues.apache.org/jira/browse/CXF-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang resolved CXF-9014. --- Fix Version/s: 4.1.0 Resolution: Fixed > org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH > OpenJDK > > > Key: CXF-9014 > URL: https://issues.apache.org/jira/browse/CXF-9014 > Project: CXF > Issue Type: Test >Affects Versions: 4.0.4 >Reporter: Jamie Mark Goodyear >Assignee: Freeman Yue Fang >Priority: Minor > Fix For: 4.1.0 > > Attachments: bob-modified.jks, request-with-comment.xml, > request-with-trailing-whitespace.xml > > > org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH > OpenJDK. > In a full build of CXF 4.1.x (main) the SignatureWhitespaceTest suite will > fail when built on RH OpenJDK. > Likely due to certs/algorithms supported by RH (see CXF-9006). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9014) org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH OpenJDK
[ https://issues.apache.org/jira/browse/CXF-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846667#comment-17846667 ] Freeman Yue Fang commented on CXF-9014: --- PR is https://github.com/apache/cxf/pull/1875 > org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH > OpenJDK > > > Key: CXF-9014 > URL: https://issues.apache.org/jira/browse/CXF-9014 > Project: CXF > Issue Type: Test >Affects Versions: 4.0.4 >Reporter: Jamie Mark Goodyear >Assignee: Freeman Yue Fang >Priority: Minor > Attachments: bob-modified.jks, request-with-comment.xml, > request-with-trailing-whitespace.xml > > > org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH > OpenJDK. > In a full build of CXF 4.1.x (main) the SignatureWhitespaceTest suite will > fail when built on RH OpenJDK. > Likely due to certs/algorithms supported by RH (see CXF-9006). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-9014) org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH OpenJDK
[ https://issues.apache.org/jira/browse/CXF-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang reassigned CXF-9014: - Assignee: Freeman Yue Fang > org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH > OpenJDK > > > Key: CXF-9014 > URL: https://issues.apache.org/jira/browse/CXF-9014 > Project: CXF > Issue Type: Test >Affects Versions: 4.0.4 >Reporter: Jamie Mark Goodyear >Assignee: Freeman Yue Fang >Priority: Minor > Attachments: bob-modified.jks, request-with-comment.xml, > request-with-trailing-whitespace.xml > > > org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH > OpenJDK. > In a full build of CXF 4.1.x (main) the SignatureWhitespaceTest suite will > fail when built on RH OpenJDK. > Likely due to certs/algorithms supported by RH (see CXF-9006). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9014) org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH OpenJDK
[ https://issues.apache.org/jira/browse/CXF-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846625#comment-17846625 ] Freeman Yue Fang commented on CXF-9014: --- Thanks [~jgoodyear] for the confirmation, I will send PR soon Freeman > org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH > OpenJDK > > > Key: CXF-9014 > URL: https://issues.apache.org/jira/browse/CXF-9014 > Project: CXF > Issue Type: Test >Affects Versions: 4.0.4 >Reporter: Jamie Mark Goodyear >Priority: Minor > Attachments: bob-modified.jks, request-with-comment.xml, > request-with-trailing-whitespace.xml > > > org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH > OpenJDK. > In a full build of CXF 4.1.x (main) the SignatureWhitespaceTest suite will > fail when built on RH OpenJDK. > Likely due to certs/algorithms supported by RH (see CXF-9006). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-9014) org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH OpenJDK
[ https://issues.apache.org/jira/browse/CXF-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang updated CXF-9014: -- Attachment: bob-modified.jks request-with-comment.xml request-with-trailing-whitespace.xml > org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH > OpenJDK > > > Key: CXF-9014 > URL: https://issues.apache.org/jira/browse/CXF-9014 > Project: CXF > Issue Type: Test >Affects Versions: 4.0.4 >Reporter: Jamie Mark Goodyear >Priority: Minor > Attachments: bob-modified.jks, request-with-comment.xml, > request-with-trailing-whitespace.xml > > > org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH > OpenJDK. > In a full build of CXF 4.1.x (main) the SignatureWhitespaceTest suite will > fail when built on RH OpenJDK. > Likely due to certs/algorithms supported by RH (see CXF-9006). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9014) org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH OpenJDK
[ https://issues.apache.org/jira/browse/CXF-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846455#comment-17846455 ] Freeman Yue Fang commented on CXF-9014: --- Hi [~jgoodyear], Thanks for reporting this, I believe this is because in bob-modified.jks(used in SignatureWhitespaceTest) it use Subject Public Key Algorithm: 1024-bit RSA key (weak) and isn't allowed in modern JDK versions. So I regenerated bob-modified.jks with with RSA 2048/sha256. Please see attached affected files, could you please override the those in systests/ws-security/src/test/resources/org/apache/cxf/systest/ws/action folder and retest it? Thanks! Freeman > org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH > OpenJDK > > > Key: CXF-9014 > URL: https://issues.apache.org/jira/browse/CXF-9014 > Project: CXF > Issue Type: Test >Affects Versions: 4.0.4 >Reporter: Jamie Mark Goodyear >Priority: Minor > Attachments: bob-modified.jks, request-with-comment.xml, > request-with-trailing-whitespace.xml > > > org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH > OpenJDK. > In a full build of CXF 4.1.x (main) the SignatureWhitespaceTest suite will > fail when built on RH OpenJDK. > Likely due to certs/algorithms supported by RH (see CXF-9006). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9011) WSDLTo JAXWS Frontend service.vm Velocity template uses deprecated URL constructor
[
https://issues.apache.org/jira/browse/CXF-9011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844771#comment-17844771
]
Freeman Yue Fang commented on CXF-9011:
---
Hi [~fjmateo],
Thanks for reporting this! A patch is welcome to address it!
Freeman
> WSDLTo JAXWS Frontend service.vm Velocity template uses deprecated URL
> constructor
> --
>
> Key: CXF-9011
> URL: https://issues.apache.org/jira/browse/CXF-9011
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 4.0.4
>Reporter: Francisco Mateo
>Priority: Minor
>
> The URL constructors were deprecated in Java 20
> [https://bugs.openjdk.org/browse/JDK-8294241].
> The template uses the deprecated constructor:
> [https://github.com/apache/cxf/blob/cxf-4.0.4/tools/wsdlto/frontend/jaxws/src/main/java/org/apache/cxf/tools/wsdlto/frontend/jaxws/template/service.vm#L123]
> This becomes an issue when applications compile with warnings enabled, for
> example {{-Xlint:all -Werror}}
> Seems we could just switch to using {{URI.create(...).toURL()}} in the
> template since that has been available since Java 1.4
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE
[
https://issues.apache.org/jira/browse/CXF-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-9006.
---
Fix Version/s: 4.1.0
Resolution: Fixed
> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
> Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family:
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Fix For: 4.1.0
>
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using
> Red Hat OpenJDK 17. The error revealed when using
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid
> certification path to the requested target -- note: this unit test works on
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
> at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
> at
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
> at
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE
[
https://issues.apache.org/jira/browse/CXF-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844311#comment-17844311
]
Freeman Yue Fang commented on CXF-9006:
---
No, I dropped my PR
https://github.com/apache/cxf/pull/1842
without merging it as I realized your PR has it, anyway, I just merged your PR
https://github.com/apache/cxf/pull/1836
Please try it again. Sorry for the confusion.
Freeman
> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
> Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family:
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using
> Red Hat OpenJDK 17. The error revealed when using
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid
> certification path to the requested target -- note: this unit test works on
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
> at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
> at
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
> at
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE
[
https://issues.apache.org/jira/browse/CXF-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844307#comment-17844307
]
Freeman Yue Fang commented on CXF-9006:
---
Hi [~jgoodyear],
It's wired, the attached cer validity is until 2034
{code}
Not After : Mar 11 22:46:11 2034 GMT
{code}
Probably somehow you still use the old certificates? I noticed that your PR
https://github.com/apache/cxf/pull/1836
not merged yet.
Freeman
> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
> Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family:
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using
> Red Hat OpenJDK 17. The error revealed when using
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid
> certification path to the requested target -- note: this unit test works on
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
> at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
> at
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
> at
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-9008) FIPS support
Freeman Yue Fang created CXF-9008: - Summary: FIPS support Key: CXF-9008 URL: https://issues.apache.org/jira/browse/CXF-9008 Project: CXF Issue Type: New Feature Reporter: Freeman Yue Fang The goal of this ticket is to ensure we can run CXF with FIPS compliant security algorithm on FIPS enabled machines. We should ensure all security related tests(unless those tests specifically test algos which are not allowed in FIPS mode) can also pass in FIPS mode -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-9008) FIPS support
[ https://issues.apache.org/jira/browse/CXF-9008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang reassigned CXF-9008: - Assignee: Freeman Yue Fang > FIPS support > > > Key: CXF-9008 > URL: https://issues.apache.org/jira/browse/CXF-9008 > Project: CXF > Issue Type: New Feature >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > > The goal of this ticket is to ensure we can run CXF with FIPS compliant > security algorithm on FIPS enabled machines. > We should ensure all security related tests(unless those tests specifically > test algos which are not allowed in FIPS mode) can also pass in FIPS mode -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE
[ https://issues.apache.org/jira/browse/CXF-9006 ]
Freeman Yue Fang deleted comment on CXF-9006:
---
was (Author: ffang):
Send PR to upgrade the cer files
https://github.com/apache/cxf/pull/1842
> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
> Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family:
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using
> Red Hat OpenJDK 17. The error revealed when using
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid
> certification path to the requested target -- note: this unit test works on
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
> at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
> at
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
> at
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE
[
https://issues.apache.org/jira/browse/CXF-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842138#comment-17842138
]
Freeman Yue Fang commented on CXF-9006:
---
Send PR to upgrade the cer files
https://github.com/apache/cxf/pull/1842
> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
> Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family:
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using
> Red Hat OpenJDK 17. The error revealed when using
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid
> certification path to the requested target -- note: this unit test works on
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
> at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
> at
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
> at
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE
[
https://issues.apache.org/jira/browse/CXF-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842022#comment-17842022
]
Freeman Yue Fang commented on CXF-9006:
---
Hi [~jgoodyear],
Could you please copy the cer files I attached here to
services/xkms/xkms-x509-handlers/src/test/resources/trustedAuthorityValidator/
folder to override the old ones and rerun the test against the JDKs you are
testing?
These new cer files are RSA2048 instead the previous DSA1024.
Thanks
Freeman
> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
> Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family:
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using
> Red Hat OpenJDK 17. The error revealed when using
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid
> certification path to the requested target -- note: this unit test works on
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
> at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
> at
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
> at
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE
[
https://issues.apache.org/jira/browse/CXF-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang updated CXF-9006:
--
Attachment: wss40.cer
wss40CA.cer
wss40CACRL.cer
wss40rev.cer
> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
> Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family:
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using
> Red Hat OpenJDK 17. The error revealed when using
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid
> certification path to the requested target -- note: this unit test works on
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
> at
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
> at
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
> at
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-9004) Jetty12 : always use pre-saved HTTP_REQUEST from InMessage to populate SecurityContext
[ https://issues.apache.org/jira/browse/CXF-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang resolved CXF-9004. --- Resolution: Fixed > Jetty12 : always use pre-saved HTTP_REQUEST from InMessage to populate > SecurityContext > -- > > Key: CXF-9004 > URL: https://issues.apache.org/jira/browse/CXF-9004 > Project: CXF > Issue Type: Bug > Components: Transports >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 4.1.0 > > > Ensure we use HttpServletRequest from the one saved in inMessage as this > could be the cachedInput one in oneway and ReplyTo is specified when > ws-addressing is used, which means we need to switch thread context and > underlying transport might discard any data on the original stream. > So always retrieve the pre-saved HTTP_REQUEST from InMessage, so this could > be the original HttpServletRequest or the Cached HttpServletRequest when it's > necessary -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-9004) Jetty12 : always use pre-saved HTTP_REQUEST from InMessage to populate SecurityContext
Freeman Yue Fang created CXF-9004: - Summary: Jetty12 : always use pre-saved HTTP_REQUEST from InMessage to populate SecurityContext Key: CXF-9004 URL: https://issues.apache.org/jira/browse/CXF-9004 Project: CXF Issue Type: Bug Components: Transports Reporter: Freeman Yue Fang Assignee: Freeman Yue Fang Fix For: 4.1.0 Ensure we use HttpServletRequest from the one saved in inMessage as this could be the cachedInput one in oneway and ReplyTo is specified when ws-addressing is used, which means we need to switch thread context and underlying transport might discard any data on the original stream. So always retrieve the pre-saved HTTP_REQUEST from InMessage, so this could be the original HttpServletRequest or the Cached HttpServletRequest when it's necessary -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8987) Java 21 - HttpClientHTTPConduit thread locked during shutdown
[
https://issues.apache.org/jira/browse/CXF-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834027#comment-17834027
]
Freeman Yue Fang commented on CXF-8987:
---
Hi [~carnevalegiacomo],
Is it possible that you append a reproducer project so that we can reproduce
this behaviour easily?
Thanks!
Freeman
> Java 21 - HttpClientHTTPConduit thread locked during shutdown
> --
>
> Key: CXF-8987
> URL: https://issues.apache.org/jira/browse/CXF-8987
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3, 4.0.4
> Environment: [^thdump2]
> *OpenJDK 21.0.2*
> *Apache CXF 4.0.4*
> *Apache Camel 4.4.1*
>Reporter: Giacomo Carnevale
>Priority: Blocker
> Attachments: thdump2
>
>
> Hi,
> I am using Apache CXF client via the Apache Camel CXF connector.
> After I updated frm OpenJDK 17.x to OpenJDK 21.0.2, during application
> shutdown, the following lock occurs:
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2072)*
> *- locked <0x00061cd2ab80> (a
> jdk.internal.net.http.HttpClientImpl$SelectorManager)*
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2200)*
> *at
> jdk.internal.net.http.HttpClientImpl.awaitTermination(java.net.http@21.0.2/HttpClientImpl.java:628)*
> *at
> java.net.http.HttpClient.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClient.java:900)*
> *at
> jdk.internal.net.http.HttpClientFacade.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClientFacade.java:192)*
> *at
> org.apache.cxf.transport.http.HttpClientHTTPConduit.{color:#de350b}close{color}(HttpClientHTTPConduit.java:125)*
> HttpClientHTTPConduit.close
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> ((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
>
> java.net.HttpClient.close
>
> {code:java}
> public void close() {
> boolean terminated = isTerminated();
> if (!terminated) {
> shutdown();
> boolean interrupted = false;
> while (!terminated) {
> try {
> terminated = awaitTermination(Duration.ofDays(1L));
> } catch (InterruptedException e) {
> if (!interrupted) {
> interrupted = true;
> shutdownNow();
> if (isTerminated()) break;
> }
> }
> }
> if (interrupted) {
> Thread.currentThread().interrupt();
> }
> }
> } {code}
> My workaround
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> client.shutdownNow();
> //((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8998) cxf-codegen-plugin - debug output velocity
[
https://issues.apache.org/jira/browse/CXF-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833655#comment-17833655
]
Freeman Yue Fang commented on CXF-8998:
---
Hi [~khmarbaise],
I just quick tested samples/wsdl_first shipped with CXF 4.0.4 kit, but I can't
see the DEBUG org.apache.velocity output there.
Any chance you can append a reproducer project so that we can take a closer
look?
Thanks!
Freeman
> cxf-codegen-plugin - debug output velocity
> --
>
> Key: CXF-8998
> URL: https://issues.apache.org/jira/browse/CXF-8998
> Project: CXF
> Issue Type: Improvement
> Components: Configuration
>Affects Versions: 4.0.4
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Currently we are using {{cxf-codegen-plugin}}, which produces allways
> debugging output of velocity, on the console
> {code}
> 15:59:45 [INFO]
> 15:59:45 [INFO] --- cxf-codegen:4.0.4:wsdl2java (default) @ wsdls ---
> 15:59:45 [INFO] Running code generation in fork mode...
> 15:59:45 [INFO] bin/java
> 15:59:45 [INFO] Building jar: /tmp/cxf-tmp-7/cxf-codegen.jar
> 15:59:45 [WARNING] Picked up JAVA_TOOL_OPTIONS: .
> 15:59:46 [INFO] 15:59:46.356 [main] DEBUG org.apache.velocity --
> Initializing Velocity, Calling init()...
> 15:59:46 [INFO] 15:59:46.360 [main] DEBUG org.apache.velocity -- Starting
> Apache Velocity v2.3
> 15:59:46 [INFO] 15:59:46.362 [main] DEBUG org.apache.velocity -- Default
> Properties resource: org/apache/velocity/runtime/defaults/velocity.properties
> 15:59:53 [INFO]
> {code}
> Is there an easy way to suppress the debug output for the execution of the
> plugin?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8990) Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1
[
https://issues.apache.org/jira/browse/CXF-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829981#comment-17829981
]
Freeman Yue Fang commented on CXF-8990:
---
You are very welcome Claus!
> Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1
> ---
>
> Key: CXF-8990
> URL: https://issues.apache.org/jira/browse/CXF-8990
> Project: CXF
> Issue Type: Bug
>Reporter: Jiri Ondrusek
>Assignee: Freeman Yue Fang
>Priority: Major
>
> I was building Camel right after the upgrade of plugins (cxf-codegen to 4.0.4
> and cxf-xjc to 4.0.1) See
> [https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b]
>
> The build failed with:
> {code:java}
> [INFO] < org.apache.camel:camel-itest
> >
> [INFO] Building Camel :: Integration Tests 4.5.0-SNAPSHOT
> [557/559]
> [INFO] from tests/camel-itest/pom.xml
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- clean:3.3.2:clean (default-clean) @ camel-itest ---
> [INFO] Deleting /home/jondruse/git/community/camel/tests/camel-itest/target
> [INFO]
> [INFO] --- cxf-codegen:4.0.4:wsdl2java (generate-test-sources) @ camel-itest
> ---
> [INFO] Running code generation in fork mode...
> [INFO] The java executable is
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> [INFO] Building jar:
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> [WARNING] Exception in thread "main"
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace
> {code}
> {code:java}
> ...
> ERROR] Failed to execute goal
> org.apache.cxf:cxf-codegen-plugin:4.0.4:wsdl2java (generate-test-sources) on
> project camel-itest:
> [ERROR] Exit code: 1
> [ERROR] Command line was:
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED
> --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED
> --add-opens java.base/java.security=ALL-UNNAMED --add-opens
> java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED
> --add-opens java.base/java.util=ALL-UNNAMED --add-opens
> java.base/java.util.concurrent=ALL-UNNAMED -jar
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> /tmp/cxf-tmp-14372731791450387841/cxf-w2j15211708284601236974args
> {code}
> Issue can be simulated by building of Camel from this commit:
> https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-8990) Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1
[
https://issues.apache.org/jira/browse/CXF-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang reassigned CXF-8990:
-
Assignee: Freeman Yue Fang
> Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1
> ---
>
> Key: CXF-8990
> URL: https://issues.apache.org/jira/browse/CXF-8990
> Project: CXF
> Issue Type: Bug
>Reporter: Jiri Ondrusek
>Assignee: Freeman Yue Fang
>Priority: Major
>
> I was building Camel right after the upgrade of plugins (cxf-codegen to 4.0.4
> and cxf-xjc to 4.0.1) See
> [https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b]
>
> The build failed with:
> {code:java}
> [INFO] < org.apache.camel:camel-itest
> >
> [INFO] Building Camel :: Integration Tests 4.5.0-SNAPSHOT
> [557/559]
> [INFO] from tests/camel-itest/pom.xml
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- clean:3.3.2:clean (default-clean) @ camel-itest ---
> [INFO] Deleting /home/jondruse/git/community/camel/tests/camel-itest/target
> [INFO]
> [INFO] --- cxf-codegen:4.0.4:wsdl2java (generate-test-sources) @ camel-itest
> ---
> [INFO] Running code generation in fork mode...
> [INFO] The java executable is
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> [INFO] Building jar:
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> [WARNING] Exception in thread "main"
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace
> {code}
> {code:java}
> ...
> ERROR] Failed to execute goal
> org.apache.cxf:cxf-codegen-plugin:4.0.4:wsdl2java (generate-test-sources) on
> project camel-itest:
> [ERROR] Exit code: 1
> [ERROR] Command line was:
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED
> --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED
> --add-opens java.base/java.security=ALL-UNNAMED --add-opens
> java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED
> --add-opens java.base/java.util=ALL-UNNAMED --add-opens
> java.base/java.util.concurrent=ALL-UNNAMED -jar
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> /tmp/cxf-tmp-14372731791450387841/cxf-w2j15211708284601236974args
> {code}
> Issue can be simulated by building of Camel from this commit:
> https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8990) Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1
[
https://issues.apache.org/jira/browse/CXF-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829920#comment-17829920
]
Freeman Yue Fang commented on CXF-8990:
---
Hi [~jondruse],
I just pushed the fix on camel side.
https://github.com/apache/camel/commit/c2f719109610538374003e66049a83b6f5d5b323
Freeman
> Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1
> ---
>
> Key: CXF-8990
> URL: https://issues.apache.org/jira/browse/CXF-8990
> Project: CXF
> Issue Type: Bug
>Reporter: Jiri Ondrusek
>Priority: Major
>
> I was building Camel right after the upgrade of plugins (cxf-codegen to 4.0.4
> and cxf-xjc to 4.0.1) See
> [https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b]
>
> The build failed with:
> {code:java}
> [INFO] < org.apache.camel:camel-itest
> >
> [INFO] Building Camel :: Integration Tests 4.5.0-SNAPSHOT
> [557/559]
> [INFO] from tests/camel-itest/pom.xml
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- clean:3.3.2:clean (default-clean) @ camel-itest ---
> [INFO] Deleting /home/jondruse/git/community/camel/tests/camel-itest/target
> [INFO]
> [INFO] --- cxf-codegen:4.0.4:wsdl2java (generate-test-sources) @ camel-itest
> ---
> [INFO] Running code generation in fork mode...
> [INFO] The java executable is
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> [INFO] Building jar:
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> [WARNING] Exception in thread "main"
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace
> {code}
> {code:java}
> ...
> ERROR] Failed to execute goal
> org.apache.cxf:cxf-codegen-plugin:4.0.4:wsdl2java (generate-test-sources) on
> project camel-itest:
> [ERROR] Exit code: 1
> [ERROR] Command line was:
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED
> --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED
> --add-opens java.base/java.security=ALL-UNNAMED --add-opens
> java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED
> --add-opens java.base/java.util=ALL-UNNAMED --add-opens
> java.base/java.util.concurrent=ALL-UNNAMED -jar
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> /tmp/cxf-tmp-14372731791450387841/cxf-w2j15211708284601236974args
> {code}
> Issue can be simulated by building of Camel from this commit:
> https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8990) Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1
[
https://issues.apache.org/jira/browse/CXF-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-8990.
---
Resolution: Not A Bug
> Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1
> ---
>
> Key: CXF-8990
> URL: https://issues.apache.org/jira/browse/CXF-8990
> Project: CXF
> Issue Type: Bug
>Reporter: Jiri Ondrusek
>Assignee: Freeman Yue Fang
>Priority: Major
>
> I was building Camel right after the upgrade of plugins (cxf-codegen to 4.0.4
> and cxf-xjc to 4.0.1) See
> [https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b]
>
> The build failed with:
> {code:java}
> [INFO] < org.apache.camel:camel-itest
> >
> [INFO] Building Camel :: Integration Tests 4.5.0-SNAPSHOT
> [557/559]
> [INFO] from tests/camel-itest/pom.xml
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- clean:3.3.2:clean (default-clean) @ camel-itest ---
> [INFO] Deleting /home/jondruse/git/community/camel/tests/camel-itest/target
> [INFO]
> [INFO] --- cxf-codegen:4.0.4:wsdl2java (generate-test-sources) @ camel-itest
> ---
> [INFO] Running code generation in fork mode...
> [INFO] The java executable is
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> [INFO] Building jar:
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> [WARNING] Exception in thread "main"
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace
> {code}
> {code:java}
> ...
> ERROR] Failed to execute goal
> org.apache.cxf:cxf-codegen-plugin:4.0.4:wsdl2java (generate-test-sources) on
> project camel-itest:
> [ERROR] Exit code: 1
> [ERROR] Command line was:
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED
> --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED
> --add-opens java.base/java.security=ALL-UNNAMED --add-opens
> java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED
> --add-opens java.base/java.util=ALL-UNNAMED --add-opens
> java.base/java.util.concurrent=ALL-UNNAMED -jar
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> /tmp/cxf-tmp-14372731791450387841/cxf-w2j15211708284601236974args
> {code}
> Issue can be simulated by building of Camel from this commit:
> https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8990) Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1
[
https://issues.apache.org/jira/browse/CXF-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829916#comment-17829916
]
Freeman Yue Fang commented on CXF-8990:
---
Hi [~jondruse],
Please notice this warning in your build
{code}
[WARNING] Exception in thread "main" org.apache.cxf.tools.common.ToolException:
Not a valid jaxb or jaxws binding file, please check the namespace
{code}
This means the namespace in the jaxb or jaxws binding file of your build isn't
correctly. More specifically, you should use something like (JEE9+ jakarta
namespace)
{code}
xmlns:jaxws="https://jakarta.ee/xml/ns/jaxws;
xmlns:jxb="https://jakarta.ee/xml/ns/jaxb;
{code}
instead of
{code}
xmlns:jaxws="https://java.sun.com/xml/ns/jaxws;
xmlns:jxb="https://java.sun.com/xml/ns/jaxb;
{code}
Cheers
Freeman
> Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1
> ---
>
> Key: CXF-8990
> URL: https://issues.apache.org/jira/browse/CXF-8990
> Project: CXF
> Issue Type: Bug
>Reporter: Jiri Ondrusek
>Priority: Major
>
> I was building Camel right after the upgrade of plugins (cxf-codegen to 4.0.4
> and cxf-xjc to 4.0.1) See
> [https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b]
>
> The build failed with:
> {code:java}
> [INFO] < org.apache.camel:camel-itest
> >
> [INFO] Building Camel :: Integration Tests 4.5.0-SNAPSHOT
> [557/559]
> [INFO] from tests/camel-itest/pom.xml
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- clean:3.3.2:clean (default-clean) @ camel-itest ---
> [INFO] Deleting /home/jondruse/git/community/camel/tests/camel-itest/target
> [INFO]
> [INFO] --- cxf-codegen:4.0.4:wsdl2java (generate-test-sources) @ camel-itest
> ---
> [INFO] Running code generation in fork mode...
> [INFO] The java executable is
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> [INFO] Building jar:
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> [WARNING] Exception in thread "main"
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding
> file, please check the namespace
> {code}
> {code:java}
> ...
> ERROR] Failed to execute goal
> org.apache.cxf:cxf-codegen-plugin:4.0.4:wsdl2java (generate-test-sources) on
> project camel-itest:
> [ERROR] Exit code: 1
> [ERROR] Command line was:
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED
> --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED
> --add-opens java.base/java.security=ALL-UNNAMED --add-opens
> java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED
> --add-opens java.base/java.util=ALL-UNNAMED --add-opens
> java.base/java.util.concurrent=ALL-UNNAMED -jar
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> /tmp/cxf-tmp-14372731791450387841/cxf-w2j15211708284601236974args
> {code}
> Issue can be simulated by building of Camel from this commit:
> https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8986) Ws-security-policy: if more policies are used in the same JVM, their algorithm suites influence each other
[
https://issues.apache.org/jira/browse/CXF-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827563#comment-17827563
]
Freeman Yue Fang commented on CXF-8986:
---
Hi [~jondruse],
This behaviour(expected) actually comes from your test, in your
custom-encrypt-sign-policy.xml
and
encrypt-sign-policy.xml
two different policies share the same policy ID, the PoliyEngine in CXF won't
rebuild policy again if found the Policy with same ID existent already.
So if you change your testcase like
{code}
---
a/integration-tests/ws-security-policy/src/main/resources/custom-encrypt-sign-policy.xml
+++
b/integration-tests/ws-security-policy/src/main/resources/custom-encrypt-sign-policy.xml
@@ -1,5 +1,5 @@
-http://www.w3.org/ns/ws-policy;
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702;>
{code}
You can find it works as expected.
Freeman
> Ws-security-policy: if more policies are used in the same JVM, their
> algorithm suites influence each other
> --
>
> Key: CXF-8986
> URL: https://issues.apache.org/jira/browse/CXF-8986
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 4.0.4
>Reporter: Jiri Ondrusek
>Priority: Major
>
> I'm fixing some tests in quarkus-cxf and I found a behavior which seems to be
> not desired. On the other hand I might be missing some information and this
> behavior is expected.
> Reproducer:
> # Clone and build
> [https://github.com/JiriOndrusek/quarkus-cxf/tree/suite-influence-reprodocer]
> # Run (with remote debug)
> {code:java}
> ./mvnw clean test -f integration-tests/ws-security-policy
> -Dtest="EncryptSignPolicyTest#helloEncryptSign" -Dmaven.surefire.debug{code}
> Check value of effectivePolicy in this line
> [https://github.com/apache/cxf/blob/main/rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/PolicyOutInterceptor.java#L98]
> Look into
> {code:java}
> effectivePolicy->policy->policyComponents->exactlyOne->policyComponents->all->policyComponents->asymmetricBinding->alghoritnSuite->alghorithSuiteType{code}
> Value is *Basic256*
> # Run different test by this command
> {code:java}
> ./mvnw clean test -f integration-tests/ws-security-policy
> -Dtest="CustomEncryptSignPolicyTest#helloDefaultCustomValues"
> -Dmaven.surefire.debug{code}
> Debug the same place and you can see, that the alghoritmSuiteType is
> *CustomAlgorithmSuite*
> # Now run both tests together by
> {code:java}
> ./mvnw clean test -f integration-tests/ws-security-policy
> -Dtest="EncryptSignPolicyTest#helloEncryptSign,CustomEncryptSignPolicyTest#helloDefaultCustomValues"
> -Dmaven.surefire.debug{code}
> The first breakpoint is triggered by
> {code:java}
> CustomEncryptSignPolicyTest#helloDefaultCustomValues{code}
> and you can see hat the alghoritmSuiteType is *CustomAlgorithmSuite*
> The second breakpoint belongs to
> {code:java}
> EncryptSignPolicyTest#helloEncryptSign{code}
> , but the value in the efectivePolicy->..->asymmetricBinding is
> *CustomAlgorithmSuite*
> This is wrong, the correct value should be *Basic256*
> I changed test `CustomEncryptSignPolicyTest#helloDefaultCustomValues` to use
> *Basic128Rsa15* (to verify that the culprit is not the customAlgorithmSuite)
> and the result was wrong as with default values.
> Single execution showed *Basic128Rsa15* or *Basic256* (depends on the test),
> but execution of both tests showed *Basic128Rsa15* in both cases.
> I think that the behavior is wrong. I have a test suite running on FIPS
> machine. If tests are executed alone all works correctly (some tests asserts
> success, some tests asserts failure). If I run tests together, the tests
> which should fail, are successful.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8984) HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in closeInputStream()
[
https://issues.apache.org/jira/browse/CXF-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang updated CXF-8984:
--
Fix Version/s: 3.6.3
> HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in
> closeInputStream()
>
>
> Key: CXF-8984
> URL: https://issues.apache.org/jira/browse/CXF-8984
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.1, 4.0.2, 4.0.3
>Reporter: Thomas Egli
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
>
> The package private class {{HttpClientWrappedOutputStream in
> org.apache.cxf.transport.http.HttpClientHTTPConduit}} implements the methods
> _getInputStream()_ and {_}closeInputStream(){_}.
> There are several paths where _getInputStream()_ returns null. This will then
> lead to a *NullPointerException* in _closeInputStream()_ because there is no
> null check.
> {code:java}
> @Override
> protected InputStream getInputStream() throws IOException {
> HttpResponse resp = getResponse();
> String method =
> (String)outMessage.get(Message.HTTP_REQUEST_METHOD);
> int sc = resp.statusCode();
> if ("HEAD".equals(method)) {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> if (sc == 204) {
> //no content
> return null;
> }
> if ("OPTIONS".equals(method) || (sc >= 300 && sc < 500)) {
> Optional f =
> resp.headers().firstValue("content-length");
> Optional fChunk =
> resp.headers().firstValue("transfer-encoding");
> if (f.isPresent()) {
> long l = Long.parseLong(f.get());
> if (l == 0) {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> } else if (!fChunk.isPresent() ||
> !"chunked".equals(fChunk.get())) {
> if (resp.version() == Version.HTTP_2) {
> InputStream in = resp.body();
> if (in.available() <= 0) {
> try (in) {
> return null;
> }
> }
> } else {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> }
> }
> return new HttpClientFilteredInputStream(resp.body());
> }
> @Override
> protected void closeInputStream() throws IOException {
> getInputStream().close();
> }
> {code}
> We encountered this issue with SOAP WS POST requests that return status 204.
> A downgrade to 4.0.0 fixed it, as {{HttpClientHTTPConduit}} was introduced
> with 4.0.1.
>
> The fix looks (too?) easy:
> {code:java}
> @Override
> protected void closeInputStream() throws IOException {
> InputStream is = getInputStream();
> if (is != null) {
> is.close();
> }
> }{code}
>
> I will gladly create a PR for this, but maybe someone else can double-check
> if this is really as simple as it looks like :)
> Version 4.0.1 was released in May 2023, and it looks unlikely to me that
> no-one else stumbled upon this problem until now.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8984) HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in closeInputStream()
[
https://issues.apache.org/jira/browse/CXF-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-8984.
---
Resolution: Fixed
> HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in
> closeInputStream()
>
>
> Key: CXF-8984
> URL: https://issues.apache.org/jira/browse/CXF-8984
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.1, 4.0.2, 4.0.3
>Reporter: Thomas Egli
>Priority: Major
> Fix For: 4.0.4
>
>
> The package private class {{HttpClientWrappedOutputStream in
> org.apache.cxf.transport.http.HttpClientHTTPConduit}} implements the methods
> _getInputStream()_ and {_}closeInputStream(){_}.
> There are several paths where _getInputStream()_ returns null. This will then
> lead to a *NullPointerException* in _closeInputStream()_ because there is no
> null check.
> {code:java}
> @Override
> protected InputStream getInputStream() throws IOException {
> HttpResponse resp = getResponse();
> String method =
> (String)outMessage.get(Message.HTTP_REQUEST_METHOD);
> int sc = resp.statusCode();
> if ("HEAD".equals(method)) {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> if (sc == 204) {
> //no content
> return null;
> }
> if ("OPTIONS".equals(method) || (sc >= 300 && sc < 500)) {
> Optional f =
> resp.headers().firstValue("content-length");
> Optional fChunk =
> resp.headers().firstValue("transfer-encoding");
> if (f.isPresent()) {
> long l = Long.parseLong(f.get());
> if (l == 0) {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> } else if (!fChunk.isPresent() ||
> !"chunked".equals(fChunk.get())) {
> if (resp.version() == Version.HTTP_2) {
> InputStream in = resp.body();
> if (in.available() <= 0) {
> try (in) {
> return null;
> }
> }
> } else {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> }
> }
> return new HttpClientFilteredInputStream(resp.body());
> }
> @Override
> protected void closeInputStream() throws IOException {
> getInputStream().close();
> }
> {code}
> We encountered this issue with SOAP WS POST requests that return status 204.
> A downgrade to 4.0.0 fixed it, as {{HttpClientHTTPConduit}} was introduced
> with 4.0.1.
>
> The fix looks (too?) easy:
> {code:java}
> @Override
> protected void closeInputStream() throws IOException {
> InputStream is = getInputStream();
> if (is != null) {
> is.close();
> }
> }{code}
>
> I will gladly create a PR for this, but maybe someone else can double-check
> if this is really as simple as it looks like :)
> Version 4.0.1 was released in May 2023, and it looks unlikely to me that
> no-one else stumbled upon this problem until now.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8984) HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in closeInputStream()
[
https://issues.apache.org/jira/browse/CXF-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824130#comment-17824130
]
Freeman Yue Fang commented on CXF-8984:
---
Patch applied on behalf of [~thegli] with thanks!
> HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in
> closeInputStream()
>
>
> Key: CXF-8984
> URL: https://issues.apache.org/jira/browse/CXF-8984
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.1, 4.0.2, 4.0.3
>Reporter: Thomas Egli
>Priority: Major
> Fix For: 4.0.4
>
>
> The package private class {{HttpClientWrappedOutputStream in
> org.apache.cxf.transport.http.HttpClientHTTPConduit}} implements the methods
> _getInputStream()_ and {_}closeInputStream(){_}.
> There are several paths where _getInputStream()_ returns null. This will then
> lead to a *NullPointerException* in _closeInputStream()_ because there is no
> null check.
> {code:java}
> @Override
> protected InputStream getInputStream() throws IOException {
> HttpResponse resp = getResponse();
> String method =
> (String)outMessage.get(Message.HTTP_REQUEST_METHOD);
> int sc = resp.statusCode();
> if ("HEAD".equals(method)) {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> if (sc == 204) {
> //no content
> return null;
> }
> if ("OPTIONS".equals(method) || (sc >= 300 && sc < 500)) {
> Optional f =
> resp.headers().firstValue("content-length");
> Optional fChunk =
> resp.headers().firstValue("transfer-encoding");
> if (f.isPresent()) {
> long l = Long.parseLong(f.get());
> if (l == 0) {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> } else if (!fChunk.isPresent() ||
> !"chunked".equals(fChunk.get())) {
> if (resp.version() == Version.HTTP_2) {
> InputStream in = resp.body();
> if (in.available() <= 0) {
> try (in) {
> return null;
> }
> }
> } else {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> }
> }
> return new HttpClientFilteredInputStream(resp.body());
> }
> @Override
> protected void closeInputStream() throws IOException {
> getInputStream().close();
> }
> {code}
> We encountered this issue with SOAP WS POST requests that return status 204.
> A downgrade to 4.0.0 fixed it, as {{HttpClientHTTPConduit}} was introduced
> with 4.0.1.
>
> The fix looks (too?) easy:
> {code:java}
> @Override
> protected void closeInputStream() throws IOException {
> InputStream is = getInputStream();
> if (is != null) {
> is.close();
> }
> }{code}
>
> I will gladly create a PR for this, but maybe someone else can double-check
> if this is really as simple as it looks like :)
> Version 4.0.1 was released in May 2023, and it looks unlikely to me that
> no-one else stumbled upon this problem until now.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8984) HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in closeInputStream()
[
https://issues.apache.org/jira/browse/CXF-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824106#comment-17824106
]
Freeman Yue Fang commented on CXF-8984:
---
Hi [~thegli],
Thanks for reporting this issue.
Yes, please send PR and put a NPE here. FYI, I'm doing final cleanup and will
cut CXF 4.0.4 release today, so I'd like this fix in for CXF 4.0.4, thanks!
Freeman
> HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in
> closeInputStream()
>
>
> Key: CXF-8984
> URL: https://issues.apache.org/jira/browse/CXF-8984
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.1, 4.0.2, 4.0.3
>Reporter: Thomas Egli
>Priority: Major
> Fix For: 4.0.4
>
>
> The package private class {{HttpClientWrappedOutputStream in
> org.apache.cxf.transport.http.HttpClientHTTPConduit}} implements the methods
> _getInputStream()_ and {_}closeInputStream(){_}.
> There are several paths where _getInputStream()_ returns null. This will then
> lead to a *NullPointerException* in _closeInputStream()_ because there is no
> null check.
> {code:java}
> @Override
> protected InputStream getInputStream() throws IOException {
> HttpResponse resp = getResponse();
> String method =
> (String)outMessage.get(Message.HTTP_REQUEST_METHOD);
> int sc = resp.statusCode();
> if ("HEAD".equals(method)) {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> if (sc == 204) {
> //no content
> return null;
> }
> if ("OPTIONS".equals(method) || (sc >= 300 && sc < 500)) {
> Optional f =
> resp.headers().firstValue("content-length");
> Optional fChunk =
> resp.headers().firstValue("transfer-encoding");
> if (f.isPresent()) {
> long l = Long.parseLong(f.get());
> if (l == 0) {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> } else if (!fChunk.isPresent() ||
> !"chunked".equals(fChunk.get())) {
> if (resp.version() == Version.HTTP_2) {
> InputStream in = resp.body();
> if (in.available() <= 0) {
> try (in) {
> return null;
> }
> }
> } else {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> }
> }
> return new HttpClientFilteredInputStream(resp.body());
> }
> @Override
> protected void closeInputStream() throws IOException {
> getInputStream().close();
> }
> {code}
> We encountered this issue with SOAP WS POST requests that return status 204.
> A downgrade to 4.0.0 fixed it, as {{HttpClientHTTPConduit}} was introduced
> with 4.0.1.
>
> The fix looks (too?) easy:
> {code:java}
> @Override
> protected void closeInputStream() throws IOException {
> InputStream is = getInputStream();
> if (is != null) {
> is.close();
> }
> }{code}
>
> I will gladly create a PR for this, but maybe someone else can double-check
> if this is really as simple as it looks like :)
> Version 4.0.1 was released in May 2023, and it looks unlikely to me that
> no-one else stumbled upon this problem until now.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8984) HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in closeInputStream()
[
https://issues.apache.org/jira/browse/CXF-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang updated CXF-8984:
--
Fix Version/s: 4.0.4
> HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in
> closeInputStream()
>
>
> Key: CXF-8984
> URL: https://issues.apache.org/jira/browse/CXF-8984
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.1, 4.0.2, 4.0.3
>Reporter: Thomas Egli
>Priority: Major
> Fix For: 4.0.4
>
>
> The package private class {{HttpClientWrappedOutputStream in
> org.apache.cxf.transport.http.HttpClientHTTPConduit}} implements the methods
> _getInputStream()_ and {_}closeInputStream(){_}.
> There are several paths where _getInputStream()_ returns null. This will then
> lead to a *NullPointerException* in _closeInputStream()_ because there is no
> null check.
> {code:java}
> @Override
> protected InputStream getInputStream() throws IOException {
> HttpResponse resp = getResponse();
> String method =
> (String)outMessage.get(Message.HTTP_REQUEST_METHOD);
> int sc = resp.statusCode();
> if ("HEAD".equals(method)) {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> if (sc == 204) {
> //no content
> return null;
> }
> if ("OPTIONS".equals(method) || (sc >= 300 && sc < 500)) {
> Optional f =
> resp.headers().firstValue("content-length");
> Optional fChunk =
> resp.headers().firstValue("transfer-encoding");
> if (f.isPresent()) {
> long l = Long.parseLong(f.get());
> if (l == 0) {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> } else if (!fChunk.isPresent() ||
> !"chunked".equals(fChunk.get())) {
> if (resp.version() == Version.HTTP_2) {
> InputStream in = resp.body();
> if (in.available() <= 0) {
> try (in) {
> return null;
> }
> }
> } else {
> try (InputStream in = resp.body()) {
> return null;
> }
> }
> }
> }
> return new HttpClientFilteredInputStream(resp.body());
> }
> @Override
> protected void closeInputStream() throws IOException {
> getInputStream().close();
> }
> {code}
> We encountered this issue with SOAP WS POST requests that return status 204.
> A downgrade to 4.0.0 fixed it, as {{HttpClientHTTPConduit}} was introduced
> with 4.0.1.
>
> The fix looks (too?) easy:
> {code:java}
> @Override
> protected void closeInputStream() throws IOException {
> InputStream is = getInputStream();
> if (is != null) {
> is.close();
> }
> }{code}
>
> I will gladly create a PR for this, but maybe someone else can double-check
> if this is really as simple as it looks like :)
> Version 4.0.1 was released in May 2023, and it looks unlikely to me that
> no-one else stumbled upon this problem until now.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8983) cxf-services-sts-core should depend on cxf-rt-rs-security-jose instead of cxf-rt-rs-security-jose-jaxrs
[ https://issues.apache.org/jira/browse/CXF-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang updated CXF-8983: -- Fix Version/s: 4.0.4 (was: 4.0.5) > cxf-services-sts-core should depend on cxf-rt-rs-security-jose instead of > cxf-rt-rs-security-jose-jaxrs > --- > > Key: CXF-8983 > URL: https://issues.apache.org/jira/browse/CXF-8983 > Project: CXF > Issue Type: Bug > Components: STS >Affects Versions: 4.0.4 >Reporter: Peter Palaga >Priority: Major > Fix For: 4.0.4 > > > cxf-services-sts-core does not need to depend on > cxf-rt-rs-security-jose-jaxrs; cxf-rt-rs-security-jose would be enough. > My understanding is that STS has nothing to do with JAX-RS, so there is no > need to pull any JAX-RS related code via cxf-rt-rs-security-jose-jaxrs. > cxf-services-sts-systests seem to pass when cxf-rt-rs-security-jose-jaxrs is > replaced by cxf-rt-rs-security-jose in cxf-services-sts-core. > Let me send a PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8981) WSS4J Encyption using the Key Agreement Method with the apache-CXF
[ https://issues.apache.org/jira/browse/CXF-8981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang resolved CXF-8981. --- Resolution: Fixed > WSS4J Encyption using the Key Agreement Method with the apache-CXF > --- > > Key: CXF-8981 > URL: https://issues.apache.org/jira/browse/CXF-8981 > Project: CXF > Issue Type: Test > Components: WS-* Components >Affects Versions: 4.0.3 >Reporter: Joze Rihtarsic >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 4.0.4 > > > Recently, the Santuario/XMLSEC and WSS4J libraries added the support for the > Key Agreement method. See the following tickets: SANTUARIO-511 and WSS-706. > The purpose of this task is to implement tests within the cxf library to > verify that the Key Agreement method for encryption with EC and XEC keys is > working as expected with the CXF framework. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823393#comment-17823393
]
Freeman Yue Fang commented on CXF-8962:
---
Sure [~reta], done!
Cheers
Freeman
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.6.2, 4.0.3
>Reporter: Alonso Gonzalez
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-8962.
---
Resolution: Fixed
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.6.2, 4.0.3
>Reporter: Alonso Gonzalez
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8933) Add doPrivileged block to ProxyFactoryProxySelector.select() in HttpClientHTTPConduit
[
https://issues.apache.org/jira/browse/CXF-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-8933.
---
Resolution: Fixed
> Add doPrivileged block to ProxyFactoryProxySelector.select() in
> HttpClientHTTPConduit
> --
>
> Key: CXF-8933
> URL: https://issues.apache.org/jira/browse/CXF-8933
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Jim Ma
>Assignee: Jim Ma
>Priority: Major
> Fix For: 4.0.4
>
>
> Then the security manager is enabled, there is AccessControlException thrown
> from HttpClientHTTPConduit.
> {code:java}
> Caused by: java.security.AccessControlException: Permission check failed
> (permission "("java.net.NetPermission" "getProxySelector")"
> at java.base/java.net.ProxySelector.getDefault(ProxySelector.java:96)
> at
> org.apache.cxf.impl//org.apache.cxf.transport.http.HttpClientHTTPConduit$ProxyFactoryProxySelector.select(HttpClientHTTPConduit.java:330)
> at
> java.net.http/jdk.internal.net.http.HttpRequestImpl.retrieveProxy(HttpRequestImpl.java:287)
> at
> java.net.http/jdk.internal.net.http.HttpRequestImpl.(HttpRequestImpl.java:133)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.sendAsync(HttpClientImpl.java:603)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.sendAsync(HttpClientImpl.java:586)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.sendAsync(HttpClientImpl.java:578)
> at
> java.net.http/jdk.internal.net.http.HttpClientFacade.sendAsync(HttpClientFacade.java:129)
> at
> org.apache.cxf.impl//org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientWrappedOutputStream.setProtocolHeaders(HttpClientHTTPConduit.java:534)
> at
> org.apache.cxf.impl//org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1373)
> at
> org.apache.cxf.impl//org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1409)
> {code}
> We need another doPrivileged block to fix this.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8970) ensure we can build and run without bouncycastle dependencies
[ https://issues.apache.org/jira/browse/CXF-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang resolved CXF-8970. --- Fix Version/s: 4.0.4 4.1.0 Resolution: Fixed > ensure we can build and run without bouncycastle dependencies > - > > Key: CXF-8970 > URL: https://issues.apache.org/jira/browse/CXF-8970 > Project: CXF > Issue Type: New Feature >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 4.0.4, 4.1.0 > > > So far for most security modules in CXF we don't need the BouncyCastle > dependencies, but in rs/jose security module we have some code using > BouncyCastle API directly. But we actually can use java security API instead > and use the counterpart security algorithm from in-jdk default security > providers so that CXF doesn't have hard BouncyCastle dependencies -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CXF-8971) Introduce a customerizedAlgorithmSuite and make all parameters of it configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808787#comment-17808787
]
Freeman Yue Fang edited comment on CXF-8971 at 1/19/24 7:53 PM:
Hi [~ppalaga],
We probably can introduce AlgorithmSuiteDefinition element as you suggested, I
just checked the ws-securitypolicy xsd schema, so AlgorithmSuite definition
there is very flexible, so technically we pretty much can add any thing under
AlgorithmSuite.
{code}
7.1 AlgorithmSuite Assertion
{code}
However, properties way are more align with current CXF implementation, please
take a look at CXF ws-securitypolicy document here
https://cxf.apache.org/docs/ws-securitypolicy.html
A lot of info is not defined in policy xml fragment but derived from properties
during runtime, we need to create Map as security context(used
by underlying WSS4J) for both client and server accordingly anyway when using
ws-security|ws-securitypolicy.
Currently, for all fields of AlgorithmSuite$AlgorithmSuiteType class
{code}
private String name;
private String digest;
private String encryption;
private String symmetricKeyWrap;
private String asymmetricKeyWrap;
private String encryptionKeyDerivation;
private String signatureKeyDerivation;
private int encryptionDerivedKeyLength;
private int signatureDerivedKeyLength;
private int minimumSymmetricKeyLength;
private int maximumSymmetricKeyLength;
private int minimumAsymmetricKeyLength;
private int maximumAsymmetricKeyLength;
private String mgfAlgo;
private String ns;
private String encryptionDigest;
private String symmetricSignature = SPConstants.HMAC_SHA1;
private String asymmetricSignature = SPConstants.RSA_SHA1;
{code}
Per CXF ws-securitypolicy doc
[here|https://cxf.apache.org/docs/ws-securitypolicy.html]
asymmetricSignature is configurable by property
ws-security.asymmetric.signature.algorithm
symmetricSignature is configurable by property
ws-security.symmetric.signature.algorithm. We better follow the similar way
here if we want other fields configurable as well in
AlgorithmSuite$AlgorithmSuiteType class
Freeman
was (Author: ffang):
Hi [~ppalaga],
We probably can introduce AlgorithmSuiteDefinition element as you suggested, I
just checked the ws-securitypolicy xsd schema, so AlgorithmSuite definition
there is very flexible, so technically we pretty much can add any thing under
AlgorithmSuite.
{code}
7.1 AlgorithmSuite Assertion
{code}
However, properties way are more align with current CXF implementation, please
take a look at CXF ws-securitypolicy document here
https://cxf.apache.org/docs/ws-securitypolicy.html
A lot of info is not defined in policy xml fragment but derived from properties
during runtime, we need to create Map as security context(used
by underlying WSS4J) for both client and server accordingly anyway when using
ws-security|ws-securitypolicy.
Freeman
> Introduce a customerizedAlgorithmSuite and make all parameters of it
> configurable
> -
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong
[jira] [Comment Edited] (CXF-8971) Introduce a customerizedAlgorithmSuite and make all parameters of it configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808787#comment-17808787
]
Freeman Yue Fang edited comment on CXF-8971 at 1/19/24 7:27 PM:
Hi [~ppalaga],
We probably can introduce AlgorithmSuiteDefinition element as you suggested, I
just checked the ws-securitypolicy xsd schema, so AlgorithmSuite definition
there is very flexible, so technically we pretty much can add any thing under
AlgorithmSuite.
{code}
7.1 AlgorithmSuite Assertion
{code}
However, properties way are more align with current CXF implementation, please
take a look at CXF ws-securitypolicy document here
https://cxf.apache.org/docs/ws-securitypolicy.html
A lot of info is not defined in policy xml fragment but derived from properties
during runtime, we need to create Map as security context(used
by underlying WSS4J) for both client and server accordingly anyway when using
ws-security|ws-securitypolicy.
Freeman
was (Author: ffang):
Hi [~ppalaga],
We probably can introduce AlgorithmSuiteDefinition element as you suggested, I
just checked the ws-securitypolicy xsd schema, so AlgorithmSuite definition
there is very flexible, so technically we pretty much can add any thing under
AlgorithmSuite.
{code}
7.1 AlgorithmSuite Assertion
{code}
However, properties way are more align with current CXF implementation, please
take a look at CXF ws-securitypolicy document here
https://cxf.apache.org/docs/ws-securitypolicy.html
A lot of info is not defined in policy xml fragment, we need to create
Map as security context(used by underlying WSS4J) for both
client and server accordingly anyway when using ws-security|ws-securitypolicy.
Freeman
> Introduce a customerizedAlgorithmSuite and make all parameters of it
> configurable
> -
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8971) Introduce a customerizedAlgorithmSuite and make all parameters of it configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808787#comment-17808787
]
Freeman Yue Fang commented on CXF-8971:
---
Hi [~ppalaga],
We probably can introduce AlgorithmSuiteDefinition element as you suggested, I
just checked the ws-securitypolicy xsd schema, so AlgorithmSuite definition
there is very flexible, so technically we pretty much can add any thing under
AlgorithmSuite.
{code}
7.1 AlgorithmSuite Assertion
{code}
However, properties way are more align with current CXF implementation, please
take a look at CXF ws-securitypolicy document here
https://cxf.apache.org/docs/ws-securitypolicy.html
A lot of info is not defined in policy xml fragment, we need to create
Map as security context(used by underlying WSS4J) for both
client and server accordingly anyway when using ws-security|ws-securitypolicy.
Freeman
> Introduce a customerizedAlgorithmSuite and make all parameters of it
> configurable
> -
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8971) Introduce a customerizedAlgorithmSuite and make all parameters of it configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang updated CXF-8971:
--
Summary: Introduce a customerizedAlgorithmSuite and make all parameters of
it configurable (was: Make all parameters of ws-securitypolicy AlgorithmSuite
configurableMake all parameters of ws-securitypolicy AlgorithmSuite
configurable)
> Introduce a customerizedAlgorithmSuite and make all parameters of it
> configurable
> -
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8971) Make all parameters of ws-securitypolicy AlgorithmSuite configurableMake all parameters of ws-securitypolicy AlgorithmSuite configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang updated CXF-8971:
--
Summary: Make all parameters of ws-securitypolicy AlgorithmSuite
configurableMake all parameters of ws-securitypolicy AlgorithmSuite
configurable (was: Make all parameters of ws-securitypolicy AlgorithmSuite
configurable)
> Make all parameters of ws-securitypolicy AlgorithmSuite configurableMake all
> parameters of ws-securitypolicy AlgorithmSuite configurable
>
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8971) Introduce a Make all parameters of ws-securitypolicy AlgorithmSuite configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang updated CXF-8971:
--
Summary: Introduce a Make all parameters of ws-securitypolicy
AlgorithmSuite configurable (was: Make all parameters of ws-securitypolicy
AlgorithmSuite configurable)
> Introduce a Make all parameters of ws-securitypolicy AlgorithmSuite
> configurable
>
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8971) Make all parameters of ws-securitypolicy AlgorithmSuite configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang updated CXF-8971:
--
Summary: Make all parameters of ws-securitypolicy AlgorithmSuite
configurable (was: Introduce a Make all parameters of ws-securitypolicy
AlgorithmSuite configurable)
> Make all parameters of ws-securitypolicy AlgorithmSuite configurable
>
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-8971) Make all parameters of ws-securitypolicy AlgorithmSuite configurable
Freeman Yue Fang created CXF-8971:
-
Summary: Make all parameters of ws-securitypolicy AlgorithmSuite
configurable
Key: CXF-8971
URL: https://issues.apache.org/jira/browse/CXF-8971
Project: CXF
Issue Type: Improvement
Reporter: Freeman Yue Fang
In ws-securitypolicy, currently we have a list of AlgorithmSuite by name, some
are defined in ws-securitypolicy, they are
{code}
Basic256
Basic192
Basic128
TripleDes
Basic256Rsa15
Basic192Rsa15
Basic128Rsa15
TripleDesRsa15
Basic256Sha256
Basic192Sha256
Basic128Sha256
TripleDesSha256
Basic256Sha256Rsa15
Basic192Sha256Rsa15
Basic128Sha256Rsa15
TripleDesSha256Rsa15
{code}
And some are from CXF itself to address CVEs, they are
{code}
Basic128GCM
Basic192GCM
Basic256GCM
{code}
so if users specify a AlgorithmSuite name like
{code}
{code}
they will get a AlgorithmSuiteType instance of all parameters hardcoded with
this AlgorithmSuite name.
{code}
new AlgorithmSuiteType(
"Basic256Sha256Rsa15",
SPConstants.SHA256,
SPConstants.AES256,
SPConstants.KW_AES256,
SPConstants.KW_RSA15,
SPConstants.P_SHA1_L256,
SPConstants.P_SHA1_L192,
256, 192, 256,
MAX_SKL, MIN_AKL, MAX_AKL)
{code}
However, security algorithms are evolving and some old-time algos may get
cracked, or sometimes only some limited modern/strong security algorithms can
be used in some scenarios, so current available AlgorithmSuiteType from both
ws-securitypolicy or CXF may not meet the specific requirements.
It would be great that we can introduce a fully configurable AlgorithmSuiteType
which could be named as ,say, customerizedAlgorithmSuite which could have
default values, but the parameters of AlgorithmSuiteType can be configured via
endpoint(client or server) properties. This flexibility can offer us more
convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8970) ensure we can build and run without bouncycastle dependencies
[ https://issues.apache.org/jira/browse/CXF-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806127#comment-17806127 ] Freeman Yue Fang commented on CXF-8970: --- PR is https://github.com/apache/cxf/pull/1645 > ensure we can build and run without bouncycastle dependencies > - > > Key: CXF-8970 > URL: https://issues.apache.org/jira/browse/CXF-8970 > Project: CXF > Issue Type: New Feature >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > > So far for most security modules in CXF we don't need the BouncyCastle > dependencies, but in rs/jose security module we have some code using > BouncyCastle API directly. But we actually can use java security API instead > and use the counterpart security algorithm from in-jdk default security > providers so that CXF doesn't have hard BouncyCastle dependencies -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8970) ensure we can build and run without bouncycastle dependencies
[ https://issues.apache.org/jira/browse/CXF-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang reassigned CXF-8970: - Assignee: Freeman Yue Fang > ensure we can build and run without bouncycastle dependencies > - > > Key: CXF-8970 > URL: https://issues.apache.org/jira/browse/CXF-8970 > Project: CXF > Issue Type: New Feature >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > > So far for most security modules in CXF we don't need the BouncyCastle > dependencies, but in rs/jose security module we have some code using > BouncyCastle API directly. But we actually can use java security API instead > and use the counterpart security algorithm from in-jdk default security > providers so that CXF doesn't have hard BouncyCastle dependencies -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8970) ensure we can build and run without bouncycastle dependencies
Freeman Yue Fang created CXF-8970: - Summary: ensure we can build and run without bouncycastle dependencies Key: CXF-8970 URL: https://issues.apache.org/jira/browse/CXF-8970 Project: CXF Issue Type: New Feature Reporter: Freeman Yue Fang So far for most security modules in CXF we don't need the BouncyCastle dependencies, but in rs/jose security module we have some code using BouncyCastle API directly. But we actually can use java security API instead and use the counterpart security algorithm from in-jdk default security providers so that CXF doesn't have hard BouncyCastle dependencies -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8671) Support Jakarta EE 10
[ https://issues.apache.org/jira/browse/CXF-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805319#comment-17805319 ] Freeman Yue Fang commented on CXF-8671: --- PR to upgrade to Jetty 12 against CXF-8671 branch https://github.com/apache/cxf/pull/1633 > Support Jakarta EE 10 > - > > Key: CXF-8671 > URL: https://issues.apache.org/jira/browse/CXF-8671 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0 > > > Support Jakarta EE 10 > Jakarta EE 10 has Landed - > [https://jakartaee-ambassadors.io/2022/09/22/jakarta-ee-10-released/] > [https://jakarta.ee/release/10/] > [https://www.infoq.com/news/2023/01/glassfish-delivers-support-jdk17/] > > Specs > ([https://repo1.maven.org/maven2/jakarta/platform/jakartaee-api-parent/10.0.0/jakartaee-api-parent-10.0.0.pom):] > * Jakarta Activation 2.1* > * Jakarta Authentication 3.0* > * Jakarta Authorization 2.1* > * Jakarta Batch 2.1* > * Jakarta Bean Validation 3.0 > * Jakarta Common Annotations 2.1* > * Jakarta Concurrency 3.0* > * Jakarta Connectors 2.1* > * Jakarta Contexts and Dependency Injection 4.0* > * Jakarta Debugging Support for Other Languages 2.0 > * Jakarta Dependency Injection 2.0 > * Jakarta Enterprise Beans 4.0 (except for Jakarta Enterprise Beans entity > beans and associated Jakarta Enterprise Beans QL, and embedded container, > which have been made removed) > * Jakarta Expression Language 5.0* > * Jakarta Interceptors 2.1* > * Jakarta JSON Processing 2.1* > * Jakarta JSON Binding 3.0* > * Jakarta Mail 2.1* > * Jakarta Managed Beans 2.0 > * Jakarta Messaging 3.1* > * Jakarta Persistence 3.1* > * Jakarta RESTful Web Services 3.1* > * Jakarta Security 3.0* > * Jakarta Servlet 6.0* > * Jakarta Server Faces 4.0* > * Jakarta Server Pages 3.1* > * Jakarta Standard Tag Library 3.0* > * Jakarta Transactions 2.0 > * Jakarta WebSocket 2.1* > * Jakarta Enterprise Beans 3.2 and earlier entity beans and associated > Jakarta Enterprise Beans QL > * Jakarta Enterprise Beans 2.x API group > * Jakarta Enterprise Web Services 2.0 > * Jakarta SOAP with Attachments 3.0* > * Jakarta XML Web Services 4.0* > * Jakarta XML Binding 4.0* > > Rest Client TCK update: > - [https://github.com/eclipse/microprofile-rest-client/pull/352] > > Updates required: > - Undertow 2.3.x > - Jetty 12 > ([https://github.com/eclipse/jetty.project/releases/tag/jetty-12.0.0.beta0]) > - Hibernate Validator 8 ([https://hibernate.org/validator/releases/8.0/)] > - Hibernate 6.4 > ([https://in.relation.to/2023/11/23/orm-640-final/|https://in.relation.to/2023/08/31/orm-630/]) > - Weld 5 ([https://weld.cdi-spec.org/news/2022/04/29/weld-500Final/]) > - Spring Boot 3.2 > ([https://github.com/spring-projects/spring-boot/releases/tag/v3.2.0|https://github.com/spring-projects/spring-boot/releases/tag/v3.1.0]) > - Spring Security 6.2 > ([https://github.com/spring-projects/spring-security/releases/tag/6.1.0]) > - Micrometer 1.12 > ([https://github.com/micrometer-metrics/micrometer/releases/tag/v1.11.0|https://github.com/micrometer-metrics/micrometer/releases/tag/v1.11.0-M1]) > - Micrometer Tracing 1.2 > ([https://github.com/micrometer-metrics/tracing/releases/tag/v1.1.4)] > - Spring LDAP 3.2 > ([https://github.com/spring-projects/spring-ldap/releases/tag/3.2.0)|https://github.com/spring-projects/spring-ldap/releases/tag/3.1.0)] > Microprofile 6.0 > ([https://download.eclipse.org/microprofile/microprofile-6.0/microprofile-spec-6.0.html),] > aligned with JakartaEE 10 core profile: > - Microprofile OpenAPI 3.1 > ([https://github.com/eclipse/microprofile-open-api/releases/tag/3.1]) > - Microprofile Config 3.1 > (https://github.com/eclipse/microprofile-config/releases/tag/3.1) > - Angus Mail > ([https://github.com/eclipse-ee4j/angus-mail/releases/tag/2.0.1]) > - > [https://github.com/arquillian/arquillian-container-weld/releases/tag/3.0.2.Final] > > Integration branch: > - [https://github.com/apache/cxf/tree/CXF-8671] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8967) More informative message should be given if multiple security bindings co-exist in ws-securitypolicy
[
https://issues.apache.org/jira/browse/CXF-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803567#comment-17803567
]
Freeman Yue Fang commented on CXF-8967:
---
Hi [~ppalaga],
I think we can reuse this ticket. Rephrased the description accordingly.
Cheers
Freeman
> More informative message should be given if multiple security bindings
> co-exist in ws-securitypolicy
>
>
> Key: CXF-8967
> URL: https://issues.apache.org/jira/browse/CXF-8967
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
>
> This might have a similar cause like CXF-8940.
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git -o ppalaga
> cd quarkus-cxf
> git checkout CXF-8967
> mvn clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
> ...
> 2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT]
> (executor-thread-1) REQ_OUT
> Address: https://localhost:8444/services/helloSaml1
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
> ServiceName: Saml1PolicyHelloService
> PortName: Saml1PolicyHelloServicePort
> PortTypeName: Saml1PolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;>
> 2023-12-25T11:46:31.087Z
> 2023-12-25T11:51:31.087Z
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
> IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
> MinorVersion="1" xsi:type="saml1:AssertionType">
> NotOnOrAfter="2023-12-25T11:51:31.070Z"/>
>
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> NameQualifier="www.mock-sts.com">uid=sts-client,o=mock-sts.com
>
>
> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
>
>
>AttributeNamespace="http://custom-ns;>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema;
> xsi:type="xsd:string">system-user
>
>
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/;>
> random saml person
>
>
>
> 2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.timestamp.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.saml.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache
> 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
> EhcacheManager.
> 2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
> (executor-thread-2) Interceptor for
> {http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl
> has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault:
> Error reading XMLStreamReader:
> org.apache.wss4j.common.ext.WSSecurityException: SAML proof-of-possession of
> the private/secret key failed
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:233)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:207)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:159)
>
[jira] [Commented] (CXF-8967) More informative message should be given if multiple security bindings co-exist in ws-securitypolicy
[
https://issues.apache.org/jira/browse/CXF-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803566#comment-17803566
]
Freeman Yue Fang commented on CXF-8967:
---
If multiple security bindings(TransportBinding, AsymmetricBinding and
SymmetricBinding) coexist in ws-securitypolicy, only one will be used. But the
behaviour between dom and stream/stax modes are different. In Dom mode, the
sequence to be considered is
AsymmetricBinding==>SymmetricBinding==>TransportBinding(org.apache.cxf.ws.security.policy.PolicyUtils#getSecurityBinding),
while in Stream mode, the sequence is
TransportBinding===>AsymmetricBinding==>SymmetricBinding(in
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JStaxOutInterceptor#configureProperties).
We should align the behaviour between stream and dom mode, plus, we should
print out a warning message that only one security binding will be used
> More informative message should be given if multiple security bindings
> co-exist in ws-securitypolicy
>
>
> Key: CXF-8967
> URL: https://issues.apache.org/jira/browse/CXF-8967
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
>
> This might have a similar cause like CXF-8940.
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git -o ppalaga
> cd quarkus-cxf
> git checkout CXF-8967
> mvn clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
> ...
> 2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT]
> (executor-thread-1) REQ_OUT
> Address: https://localhost:8444/services/helloSaml1
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
> ServiceName: Saml1PolicyHelloService
> PortName: Saml1PolicyHelloServicePort
> PortTypeName: Saml1PolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;>
> 2023-12-25T11:46:31.087Z
> 2023-12-25T11:51:31.087Z
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
> IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
> MinorVersion="1" xsi:type="saml1:AssertionType">
> NotOnOrAfter="2023-12-25T11:51:31.070Z"/>
>
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> NameQualifier="www.mock-sts.com">uid=sts-client,o=mock-sts.com
>
>
> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
>
>
>AttributeNamespace="http://custom-ns;>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema;
> xsi:type="xsd:string">system-user
>
>
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/;>
> random saml person
>
>
>
> 2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.timestamp.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.saml.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache
> 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
> EhcacheManager.
> 2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
> (executor-thread-2) Interceptor for
> {http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl
> has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault:
> Error reading XMLStreamReader:
> org.apache.wss4j.common.ext.WSSecurityException: SAML proof-of-possession of
> the private/secret key failed
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
> at
>
[jira] [Updated] (CXF-8967) More informative message should be given if multiple security bindings co-exist in ws-securitypolicy
[
https://issues.apache.org/jira/browse/CXF-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang updated CXF-8967:
--
Summary: More informative message should be given if multiple security
bindings co-exist in ws-securitypolicy (was: Body and elements not signed with
security.enable.streaming = true)
> More informative message should be given if multiple security bindings
> co-exist in ws-securitypolicy
>
>
> Key: CXF-8967
> URL: https://issues.apache.org/jira/browse/CXF-8967
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
>
> This might have a similar cause like CXF-8940.
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git -o ppalaga
> cd quarkus-cxf
> git checkout CXF-8967
> mvn clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
> ...
> 2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT]
> (executor-thread-1) REQ_OUT
> Address: https://localhost:8444/services/helloSaml1
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
> ServiceName: Saml1PolicyHelloService
> PortName: Saml1PolicyHelloServicePort
> PortTypeName: Saml1PolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;>
> 2023-12-25T11:46:31.087Z
> 2023-12-25T11:51:31.087Z
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
> IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
> MinorVersion="1" xsi:type="saml1:AssertionType">
> NotOnOrAfter="2023-12-25T11:51:31.070Z"/>
>
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> NameQualifier="www.mock-sts.com">uid=sts-client,o=mock-sts.com
>
>
> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
>
>
>AttributeNamespace="http://custom-ns;>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema;
> xsi:type="xsd:string">system-user
>
>
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/;>
> random saml person
>
>
>
> 2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.timestamp.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.saml.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache
> 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
> EhcacheManager.
> 2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
> (executor-thread-2) Interceptor for
> {http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl
> has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault:
> Error reading XMLStreamReader:
> org.apache.wss4j.common.ext.WSSecurityException: SAML proof-of-possession of
> the private/secret key failed
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:233)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:207)
> at
>
[jira] [Commented] (CXF-8967) Body and elements not signed with security.enable.streaming = true
[
https://issues.apache.org/jira/browse/CXF-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803354#comment-17803354
]
Freeman Yue Fang commented on CXF-8967:
---
Hi [~ppalaga],
{code}
I wonder whether we should not introduce some measures so that policies with
multiple security bindings (such as TransportBinding, AsymmetricBinding and
SymmetricBinding) would not be accepted at all given that CXF does not honor
them anyway?
{code}
Yes, this is something we should address in CXF.
Cheers
Freeman
> Body and elements not signed with security.enable.streaming = true
> --
>
> Key: CXF-8967
> URL: https://issues.apache.org/jira/browse/CXF-8967
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
>
> This might have a similar cause like CXF-8940.
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git -o ppalaga
> cd quarkus-cxf
> git checkout CXF-8967
> mvn clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
> ...
> 2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT]
> (executor-thread-1) REQ_OUT
> Address: https://localhost:8444/services/helloSaml1
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
> ServiceName: Saml1PolicyHelloService
> PortName: Saml1PolicyHelloServicePort
> PortTypeName: Saml1PolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;>
> 2023-12-25T11:46:31.087Z
> 2023-12-25T11:51:31.087Z
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
> IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
> MinorVersion="1" xsi:type="saml1:AssertionType">
> NotOnOrAfter="2023-12-25T11:51:31.070Z"/>
>
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> NameQualifier="www.mock-sts.com">uid=sts-client,o=mock-sts.com
>
>
> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
>
>
>AttributeNamespace="http://custom-ns;>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema;
> xsi:type="xsd:string">system-user
>
>
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/;>
> random saml person
>
>
>
> 2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.timestamp.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.saml.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache
> 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
> EhcacheManager.
> 2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
> (executor-thread-2) Interceptor for
> {http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl
> has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault:
> Error reading XMLStreamReader:
> org.apache.wss4j.common.ext.WSSecurityException: SAML proof-of-possession of
> the private/secret key failed
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:233)
> at
>
[jira] [Commented] (CXF-8967) Body and elements not signed with security.enable.streaming = true
[
https://issues.apache.org/jira/browse/CXF-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803322#comment-17803322
]
Freeman Yue Fang commented on CXF-8967:
---
Hi [~ppalaga],
Please see my PR against your test, also my comments there.
https://github.com/ppalaga/quarkus-cxf/pull/2
Best Regards
Freeman
> Body and elements not signed with security.enable.streaming = true
> --
>
> Key: CXF-8967
> URL: https://issues.apache.org/jira/browse/CXF-8967
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
>
> This might have a similar cause like CXF-8940.
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git -o ppalaga
> cd quarkus-cxf
> git checkout CXF-8967
> mvn clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
> ...
> 2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT]
> (executor-thread-1) REQ_OUT
> Address: https://localhost:8444/services/helloSaml1
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
> ServiceName: Saml1PolicyHelloService
> PortName: Saml1PolicyHelloServicePort
> PortTypeName: Saml1PolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;>
> 2023-12-25T11:46:31.087Z
> 2023-12-25T11:51:31.087Z
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
> IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
> MinorVersion="1" xsi:type="saml1:AssertionType">
> NotOnOrAfter="2023-12-25T11:51:31.070Z"/>
>
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> NameQualifier="www.mock-sts.com">uid=sts-client,o=mock-sts.com
>
>
> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
>
>
>AttributeNamespace="http://custom-ns;>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema;
> xsi:type="xsd:string">system-user
>
>
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/;>
> random saml person
>
>
>
> 2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.timestamp.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.saml.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache
> 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
> EhcacheManager.
> 2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
> (executor-thread-2) Interceptor for
> {http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl
> has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault:
> Error reading XMLStreamReader:
> org.apache.wss4j.common.ext.WSSecurityException: SAML proof-of-possession of
> the private/secret key failed
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:233)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:207)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:159)
> at
>
[jira] [Commented] (CXF-8967) Body and elements not signed with security.enable.streaming = true
[
https://issues.apache.org/jira/browse/CXF-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801818#comment-17801818
]
Freeman Yue Fang commented on CXF-8967:
---
Hi [~reta],
Sure, I will take a close look.
Cheers
Freeman
> Body and elements not signed with security.enable.streaming = true
> --
>
> Key: CXF-8967
> URL: https://issues.apache.org/jira/browse/CXF-8967
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
>
> This might have a similar cause like CXF-8940.
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git -o ppalaga
> cd quarkus-cxf
> git checkout CXF-8967
> mvn clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
> ...
> 2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT]
> (executor-thread-1) REQ_OUT
> Address: https://localhost:8444/services/helloSaml1
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
> ServiceName: Saml1PolicyHelloService
> PortName: Saml1PolicyHelloServicePort
> PortTypeName: Saml1PolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;>
> 2023-12-25T11:46:31.087Z
> 2023-12-25T11:51:31.087Z
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
> IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
> MinorVersion="1" xsi:type="saml1:AssertionType">
> NotOnOrAfter="2023-12-25T11:51:31.070Z"/>
>
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> NameQualifier="www.mock-sts.com">uid=sts-client,o=mock-sts.com
>
>
> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
>
>
>AttributeNamespace="http://custom-ns;>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema;
> xsi:type="xsd:string">system-user
>
>
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/;>
> random saml person
>
>
>
> 2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.timestamp.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.saml.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache
> 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
> EhcacheManager.
> 2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
> (executor-thread-2) Interceptor for
> {http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl
> has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault:
> Error reading XMLStreamReader:
> org.apache.wss4j.common.ext.WSSecurityException: SAML proof-of-possession of
> the private/secret key failed
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:233)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:207)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:159)
> at
> io.quarkiverse.cxf.transport.CxfHandler.process(CxfHandler.java:241)
> at
[jira] [Assigned] (CXF-8967) Body and elements not signed with security.enable.streaming = true
[
https://issues.apache.org/jira/browse/CXF-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang reassigned CXF-8967:
-
Assignee: Freeman Yue Fang
> Body and elements not signed with security.enable.streaming = true
> --
>
> Key: CXF-8967
> URL: https://issues.apache.org/jira/browse/CXF-8967
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
>
> This might have a similar cause like CXF-8940.
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git -o ppalaga
> cd quarkus-cxf
> git checkout CXF-8967
> mvn clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
> ...
> 2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT]
> (executor-thread-1) REQ_OUT
> Address: https://localhost:8444/services/helloSaml1
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
> ServiceName: Saml1PolicyHelloService
> PortName: Saml1PolicyHelloServicePort
> PortTypeName: Saml1PolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;>
> 2023-12-25T11:46:31.087Z
> 2023-12-25T11:51:31.087Z
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
> IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
> MinorVersion="1" xsi:type="saml1:AssertionType">
> NotOnOrAfter="2023-12-25T11:51:31.070Z"/>
>
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> NameQualifier="www.mock-sts.com">uid=sts-client,o=mock-sts.com
>
>
> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
>
>
>AttributeNamespace="http://custom-ns;>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema;
> xsi:type="xsd:string">system-user
>
>
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/;>
> random saml person
>
>
>
> 2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.timestamp.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.saml.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache
> 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
> EhcacheManager.
> 2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
> (executor-thread-2) Interceptor for
> {http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl
> has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault:
> Error reading XMLStreamReader:
> org.apache.wss4j.common.ext.WSSecurityException: SAML proof-of-possession of
> the private/secret key failed
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:233)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:207)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:159)
> at
> io.quarkiverse.cxf.transport.CxfHandler.process(CxfHandler.java:241)
> at io.quarkiverse.cxf.transport.CxfHandler.handle(CxfHandler.java:178)
> at
[jira] [Commented] (CXF-8671) Support Jakarta EE 10
[ https://issues.apache.org/jira/browse/CXF-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782736#comment-17782736 ] Freeman Yue Fang commented on CXF-8671: --- Hi [~karlvr1] [~reta], Thanks for what you have done here, very nice! And for the Servlet API 6.0 support of EE10, we need to upgrade to use Jetty 12 and Undertow 2.3.x, and I've been working on it. The working on Jetty12 upgrade took me a while as the Jetty12 API changed a lot. I think I've got most issues resolved for Servlet API 6.0 upgrade, and I just pushed my working branch here https://github.com/apache/cxf/tree/servlet-6 I rebased this branch against branch CXF-8671 you guys have worked on, and I am gonna polish servlet-6 branch a little bit and then send a PR against CXF-8671. Best Regards Freeman > Support Jakarta EE 10 > - > > Key: CXF-8671 > URL: https://issues.apache.org/jira/browse/CXF-8671 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.1.0 > > > Support Jakarta EE 10 > Jakarta EE 10 has Landed - > [https://jakartaee-ambassadors.io/2022/09/22/jakarta-ee-10-released/] > [https://jakarta.ee/release/10/] > [https://www.infoq.com/news/2023/01/glassfish-delivers-support-jdk17/] > > Specs: > * Jakarta Activation 2.1* > * Jakarta Authentication 3.0* > * Jakarta Authorization 2.1* > * Jakarta Batch 2.1* > * Jakarta Bean Validation 3.0 > * Jakarta Common Annotations 2.1* > * Jakarta Concurrency 3.0* > * Jakarta Connectors 2.1* > * Jakarta Contexts and Dependency Injection 4.0* > * Jakarta Debugging Support for Other Languages 2.0 > * Jakarta Dependency Injection 2.0 > * Jakarta Enterprise Beans 4.0 (except for Jakarta Enterprise Beans entity > beans and associated Jakarta Enterprise Beans QL, and embedded container, > which have been made removed) > * Jakarta Expression Language 5.0* > * Jakarta Interceptors 2.1* > * Jakarta JSON Processing 2.1* > * Jakarta JSON Binding 3.0* > * Jakarta Mail 2.1* > * Jakarta Managed Beans 2.0 > * Jakarta Messaging 3.1* > * Jakarta Persistence 3.1* > * Jakarta RESTful Web Services 3.1* > * Jakarta Security 3.0* > * Jakarta Servlet 6.0* > * Jakarta Server Faces 4.0* > * Jakarta Server Pages 3.1* > * Jakarta Standard Tag Library 3.0* > * Jakarta Transactions 2.0 > * Jakarta WebSocket 2.1* > * Jakarta Enterprise Beans 3.2 and earlier entity beans and associated > Jakarta Enterprise Beans QL > * Jakarta Enterprise Beans 2.x API group > * Jakarta Enterprise Web Services 2.0 > * Jakarta SOAP with Attachments 3.0* > * Jakarta XML Web Services 4.0* > * Jakarta XML Binding 4.0* > > Rest Client TCK update: > - [https://github.com/eclipse/microprofile-rest-client/pull/352] > > Updates required: > - Undertow 2.3.x > - Jetty 12 > ([https://github.com/eclipse/jetty.project/releases/tag/jetty-12.0.0.beta0]) > - Hibernate Validator 8 ([https://hibernate.org/validator/releases/8.0/)] > - Hibernate 6.3 (https://in.relation.to/2023/08/31/orm-630/) > - Weld 5 ([https://weld.cdi-spec.org/news/2022/04/29/weld-500Final/]) > - Spring Boot 3.1 > ([https://github.com/spring-projects/spring-boot/releases/tag/v3.1.0]) > - Spring Security 6.1 > ([https://github.com/spring-projects/spring-security/releases/tag/6.1.0]) > - Micrometer 1.11 > ([https://github.com/micrometer-metrics/micrometer/releases/tag/v1.11.0|https://github.com/micrometer-metrics/micrometer/releases/tag/v1.11.0-M1]) > - Micrometer Tracing 1.1 > ([https://github.com/micrometer-metrics/tracing/releases/tag/v1.1.4)] > - Spring LDAP 3.1 > ([https://github.com/spring-projects/spring-ldap/releases/tag/3.1.0)] > Microprofile 6.0 > ([https://download.eclipse.org/microprofile/microprofile-6.0/microprofile-spec-6.0.html),] > aligned with JakartaEE 10 core profile: > - Microprofile OpenAPI 3.1 > ([https://github.com/eclipse/microprofile-open-api/releases/tag/3.1]) > - Angus Mail > ([https://github.com/eclipse-ee4j/angus-mail/releases/tag/2.0.1]) > - > [https://github.com/arquillian/arquillian-container-weld/releases/tag/3.0.2.Final] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8940) ws-security.must-understand works only if security.enable.streaming is true
[
https://issues.apache.org/jira/browse/CXF-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-8940.
---
Fix Version/s: 3.6.3
4.0.4
Resolution: Fixed
> ws-security.must-understand works only if security.enable.streaming is true
> ---
>
> Key: CXF-8940
> URL: https://issues.apache.org/jira/browse/CXF-8940
> Project: CXF
> Issue Type: Bug
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
>
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git
> cd quarkus-cxf
> git checkout CXF-8940
> mvnd clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvnd clean test
> -Dtest=UsernameTokenSecurityPolicyTest#helloUsernameTokenNoMustUnderstand
> ...
> [ERROR]
> UsernameTokenSecurityPolicyTest>AbstractUsernameTokenSecurityPolicyTest.helloUsernameTokenNoMustUnderstand:180
>
> Expecting actual:
> "REQ_OUT
> Address: https://localhost:8444/services/helloUsernameToken
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 03fe3642-ab5b-4b85-b712-b8ed107f5a71
> ServiceName: UsernameTokenPolicyHelloService
> PortName: UsernameTokenPolicyHelloServicePort
> PortTypeName: UsernameTokenPolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
> wsu:Id="UsernameToken-4e64841c-ad35-48fd-b7ee-70e5f978e098">
> cxf-user
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText;>secret
> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary;>5rs0Ra3q0FPLXFguajlTwQ==
> 2023-10-05T22:40:54.436Z
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/;>
> helloUsernameTokenNoMustUnderstand
>
>
>
> "
> not to contain:
> "soap:mustUnderstand="1""
> {code}
> Running the same logic with
> {{quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.enable.streaming
> = true}} works as expected:
> {code}
> mvnd clean test
> -Dtest=UsernameTokenSecurityPolicyStaxTest#helloUsernameTokenNoMustUnderstand
> ...
> BUILD SUCCESS
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-8940) ws-security.must-understand works only if security.enable.streaming is true
[
https://issues.apache.org/jira/browse/CXF-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang reassigned CXF-8940:
-
Assignee: Freeman Yue Fang
> ws-security.must-understand works only if security.enable.streaming is true
> ---
>
> Key: CXF-8940
> URL: https://issues.apache.org/jira/browse/CXF-8940
> Project: CXF
> Issue Type: Bug
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
>
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git
> cd quarkus-cxf
> git checkout CXF-8940
> mvnd clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvnd clean test
> -Dtest=UsernameTokenSecurityPolicyTest#helloUsernameTokenNoMustUnderstand
> ...
> [ERROR]
> UsernameTokenSecurityPolicyTest>AbstractUsernameTokenSecurityPolicyTest.helloUsernameTokenNoMustUnderstand:180
>
> Expecting actual:
> "REQ_OUT
> Address: https://localhost:8444/services/helloUsernameToken
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 03fe3642-ab5b-4b85-b712-b8ed107f5a71
> ServiceName: UsernameTokenPolicyHelloService
> PortName: UsernameTokenPolicyHelloServicePort
> PortTypeName: UsernameTokenPolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
> wsu:Id="UsernameToken-4e64841c-ad35-48fd-b7ee-70e5f978e098">
> cxf-user
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText;>secret
> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary;>5rs0Ra3q0FPLXFguajlTwQ==
> 2023-10-05T22:40:54.436Z
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/;>
> helloUsernameTokenNoMustUnderstand
>
>
>
> "
> not to contain:
> "soap:mustUnderstand="1""
> {code}
> Running the same logic with
> {{quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.enable.streaming
> = true}} works as expected:
> {code}
> mvnd clean test
> -Dtest=UsernameTokenSecurityPolicyStaxTest#helloUsernameTokenNoMustUnderstand
> ...
> BUILD SUCCESS
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8948) wsdlto tool should throw exception when bindingFiles is invalid
[ https://issues.apache.org/jira/browse/CXF-8948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang resolved CXF-8948. --- Fix Version/s: 4.0.4 Resolution: Fixed > wsdlto tool should throw exception when bindingFiles is invalid > --- > > Key: CXF-8948 > URL: https://issues.apache.org/jira/browse/CXF-8948 > Project: CXF > Issue Type: Improvement > Components: Tooling >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 4.0.4 > > > Currently if the bindingFile namespaces are not recognized the bindingFile > will be ignored. We better throw an exception and stop the process of wsdlto > CLI or codegen-maven-plugin to make it more explicit and informative. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8948) wsdlto tool should throw exception when bindingFiles is invalid
[ https://issues.apache.org/jira/browse/CXF-8948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang reassigned CXF-8948: - Assignee: Freeman Yue Fang > wsdlto tool should throw exception when bindingFiles is invalid > --- > > Key: CXF-8948 > URL: https://issues.apache.org/jira/browse/CXF-8948 > Project: CXF > Issue Type: Improvement > Components: Tooling >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > > Currently if the bindingFile namespaces are not recognized the bindingFile > will be ignored. We better throw an exception and stop the process of wsdlto > CLI or codegen-maven-plugin to make it more explicit and informative. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8948) wsdlto tool should throw exception when bindingFiles is invalid
Freeman Yue Fang created CXF-8948: - Summary: wsdlto tool should throw exception when bindingFiles is invalid Key: CXF-8948 URL: https://issues.apache.org/jira/browse/CXF-8948 Project: CXF Issue Type: Improvement Components: Tooling Reporter: Freeman Yue Fang Currently if the bindingFile namespaces are not recognized the bindingFile will be ignored. We better throw an exception and stop the process of wsdlto CLI or codegen-maven-plugin to make it more explicit and informative. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8940) ws-security.must-understand works only if security.enable.streaming is true
[
https://issues.apache.org/jira/browse/CXF-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17775308#comment-17775308
]
Freeman Yue Fang commented on CXF-8940:
---
Hi Peter,
I think the problem comes from that if in the policy files only have Supporting
Tokens(like UsernameToken) but no Security Binding(like HTTPS
TransportBinding), the PolicyBasedWSS4JOutInterceptor can't be added, this is
the difference between your test and current test in CXF codebase.
And I think we should address it in UsernameTokenInterceptorProvider, I have a
PR ready here
https://github.com/apache/cxf/pull/1473
Cheers
Freeman
> ws-security.must-understand works only if security.enable.streaming is true
> ---
>
> Key: CXF-8940
> URL: https://issues.apache.org/jira/browse/CXF-8940
> Project: CXF
> Issue Type: Bug
>Reporter: Peter Palaga
>Priority: Major
>
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git
> cd quarkus-cxf
> git checkout CXF-8940
> mvnd clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvnd clean test
> -Dtest=UsernameTokenSecurityPolicyTest#helloUsernameTokenNoMustUnderstand
> ...
> [ERROR]
> UsernameTokenSecurityPolicyTest>AbstractUsernameTokenSecurityPolicyTest.helloUsernameTokenNoMustUnderstand:180
>
> Expecting actual:
> "REQ_OUT
> Address: https://localhost:8444/services/helloUsernameToken
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 03fe3642-ab5b-4b85-b712-b8ed107f5a71
> ServiceName: UsernameTokenPolicyHelloService
> PortName: UsernameTokenPolicyHelloServicePort
> PortTypeName: UsernameTokenPolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
> wsu:Id="UsernameToken-4e64841c-ad35-48fd-b7ee-70e5f978e098">
> cxf-user
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText;>secret
> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary;>5rs0Ra3q0FPLXFguajlTwQ==
> 2023-10-05T22:40:54.436Z
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/;>
> helloUsernameTokenNoMustUnderstand
>
>
>
> "
> not to contain:
> "soap:mustUnderstand="1""
> {code}
> Running the same logic with
> {{quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.enable.streaming
> = true}} works as expected:
> {code}
> mvnd clean test
> -Dtest=UsernameTokenSecurityPolicyStaxTest#helloUsernameTokenNoMustUnderstand
> ...
> BUILD SUCCESS
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8941) Intermittent IllegalArgumentException: invalid header name: ":status" when processing responses
[
https://issues.apache.org/jira/browse/CXF-8941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772812#comment-17772812
]
Freeman Yue Fang commented on CXF-8941:
---
Hi [~bocamel],
I believe this has been resolved by CAMEL-19843 already.
Cheers
Freeman
> Intermittent IllegalArgumentException: invalid header name: ":status" when
> processing responses
> ---
>
> Key: CXF-8941
> URL: https://issues.apache.org/jira/browse/CXF-8941
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.6.2
>Reporter: John Yin
>Priority: Major
>
> Intermittently, our CXF 3.6.2 application throws
> java.lang.IllegalArgumentException: invalid header name: ":status" when
> processing an HTTP 200 response. For some responses that look almost the
> same, CXF does not complain at all. A sample response is provided below
> along with the stacktrace. Thanks in advance for your help!
>
> Here is one sample response that caused the error.
> Response-Code: 200
> Encoding: UTF-8
> Content-Type: application/json; charset=utf-8
> Headers: {{*}:status=[200]{*}, cache-control=[max-age=0, private,
> must-revalidate], cf-cache-status=[DYNAMIC], cf-ray=[8120d7582c945770-IAD],
> content-type=[application/json; charset=utf-8], date=[Fri, 06 Oct 2023
> 21:01:44 GMT], etag=[W/"ee18109d88c13426e719d4b94ee966ed"],
> nel=[\{"success_fraction":0.01,"report_to":"cf-nel","max_age":604800}],
> rate-limit=[2500], rate-limit-remaining=[2431], rate-limit-reset=[16],
> report-to=[\{"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=cOsINr5vmtTDMmXBT5prRJo0t%2BH6pPQ0XMI3jqa3BqngB0QhhzoH51kNiQ36yWPtTzI%2FyL3fOXgG%2BchPNpGVcMG0BVzVGrcDguWlf5WrD9w0rj0cY58vOpkML%2FPbSnV5Ne053tBNQc5MzRDvtRKWPuRz6QU%3D"}],"group":"cf-nel","max_age":604800}],
> server=[cloudflare],
> set-cookie=[_zendesk_cookie=BAhJIhl7ImRldmljZV90b2tlbnMiOnt9fQY6BkVU--0bf2100788cb010d0183feca16aaf88ccaf719ca;
> path=/; expires=Sun, 06 Oct 2024 20:32:12 GMT; secure; HttpOnly;
> SameSite=None, __cfruid=06ac2cb41aceac3e3b01106d2faee9ebc301c6c2-1696626104;
> path=/; domain=.tescosupportcentre.zendesk.com; HttpOnly; Secure;
> SameSite=None], strict-transport-security=[max-age=31536000;
> includeSubDomains], x-frame-options=[SAMEORIGIN], x-rate-limit=[2500],
> x-rate-limit-remaining=[2431], x-request-id=[8120d7582c945770-IAD,
> 8120d7582c945770-IAD], x-runtime=[0.888500], x-zendesk-api-version=[v2],
> x-zendesk-application-version=[v18586],
> x-zendesk-origin-server=[classic-app-server-5cf4594448-kpvc5],
> x-zendesk-zorg=[yes]}
> Payload: \{... removed}
>
> Here is the stacktrace:
>
> org.apache.cxf.interceptor.Fault: Problem with writing the data, class
> java.lang.String, ContentType: application/json;charset=utf-8
> at
> org.apache.cxf.jaxrs.client.WebClient$BodyWriter.doWriteBody(WebClient.java:1228)
> ~[cxf-rt-rs-client-3.6.2.jar:3.6.2]
> at
> org.apache.cxf.jaxrs.client.AbstractClient$AbstractBodyWriter.handleMessage(AbstractClient.java:1223)
> ~[cxf-rt-rs-client-3.6.2.jar:3.6.2]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> ~[cxf-core-3.6.2.jar:3.6.2]
> at
> org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain(AbstractClient.java:710)
> ~[cxf-rt-rs-client-3.6.2.jar:3.6.2]
> at
> org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:1086)
> ~[cxf-rt-rs-client-3.6.2.jar:3.6.2]
> at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:932)
> ~[cxf-rt-rs-client-3.6.2.jar:3.6.2]
> at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:901)
> ~[cxf-rt-rs-client-3.6.2.jar:3.6.2]
> at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:364)
> ~[cxf-rt-rs-client-3.6.2.jar:3.6.2]
> at
> org.apache.camel.component.cxf.jaxrs.CxfRsProducer.invokeHttpClient(CxfRsProducer.java:348)
> ~[camel-cxf-rest-3.20.6.jar:3.20.6]
> at
> org.apache.camel.component.cxf.jaxrs.CxfRsProducer.process(CxfRsProducer.java:102)
> ~[camel-cxf-rest-3.20.6.jar:3.20.6]
> at
> org.apache.camel.support.SynchronousDelegateProducer.process(SynchronousDelegateProducer.java:48)
> ~[camel-support-3.20.6.jar:3.20.6]
> at
> org.apache.camel.support.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:66)
> ~[camel-support-3.20.6.jar:3.20.6]
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:172)
> ~[camel-core-processor-3.20.6.jar:3.20.6]
> at
> org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:392)
> ~[camel-base-engine-3.20.6.jar:3.20.6]
> at
> org.apache.camel.processor.ChoiceProcessor.process(ChoiceProcessor.java:95)
>
[jira] [Comment Edited] (CXF-8940) ws-security.must-understand works only if security.enable.streaming is true
[
https://issues.apache.org/jira/browse/CXF-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772696#comment-17772696
]
Freeman Yue Fang edited comment on CXF-8940 at 10/6/23 9:05 PM:
Hi [~ppalaga],
Thanks for raising this issue!
After the first glance, I don't think this is the problem in CXF. The problem
should be from quarkus-cxf or the test itself. The root cause that the
configuration in your test
{code}
...security.must-understand = false
{code}
doesn't work is that the
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor somehow not
added into the quarkus cxf client
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand. But
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor should be added
by default in CXF by
org.apache.cxf.ws.security.policy.interceptors.WSSecurityInterceptorProvider,
together with PolicyBasedWSS4JStaxOutInterceptor. We have test case in CXF
source code
cxf/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/ut/UsernameTokenPolicyTest.java
and I checked there, the
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor in CXF test is
added and invoked correctly.
The PolicyBasedWSS4JStaxOutInterceptor contains the logic when
security.enable.streaming is true(Stax API based), while
PolicyBasedWSS4JOutInterceptor contains the logic when
security.enable.streaming is false(DOM api based).
If I explicitly add PolicyBasedWSS4JOutInterceptor to your test client, then it
works, but surely the real fix should be somewhere else.
{code}
---
a/integration-tests/ws-security-policy/src/main/resources/application.properties
+++
b/integration-tests/ws-security-policy/src/main/resources/application.properties
@@ -94,6 +94,7 @@
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.trust-store-password = pas
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.username =
${wss.user}
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.callback-handler
= #usernameTokenPasswordCallback
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.must-understand
= false
+quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.out-interceptors =
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.features =
#messageCollector
{code}
In your testcase you can see that PolicyBasedWSS4JStaxOutInterceptor can be
added and invoked(that's why stax stream works as expected) by default while
PolicyBasedWSS4JOutInterceptor can't. I don't know why now but this should be
the direction to investigate.
Best Regards
Freeman
was (Author: ffang):
Hi [~ppalaga],
Thanks for raising this issue!
After the first glance, I don't think this is the problem in CXF. The problem
should be from quarkus-cxf or the test itself. The root cause that the
configuration in your test
{code}
...security.must-understand = false
{code}
doesn't work is that the
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor somehow not
added into the quarkus cxf client
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand. But
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor should be added
by default in CXF by
org.apache.cxf.ws.security.policy.interceptors.WSSecurityInterceptorProvider,
together with PolicyBasedWSS4JStaxOutInterceptor. We have test case in CXF
source code
cxf/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/ut/UsernameTokenPolicyTest.java
and I checked there, the
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor in CXF test is
added and invoked correctly.
The PolicyBasedWSS4JStaxOutInterceptor contains the logic when
security.enable.streaming is true(Stax API based), while
PolicyBasedWSS4JOutInterceptor contains the logic when
security.enable.streaming is false(DOM api based).
If I explicitly add PolicyBasedWSS4JOutInterceptor to your test client, then it
works, but surely the real fix should be somewhere else.
{code}
---
a/integration-tests/ws-security-policy/src/main/resources/application.properties
+++
b/integration-tests/ws-security-policy/src/main/resources/application.properties
@@ -94,6 +94,7 @@
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.trust-store-password = pas
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.username =
${wss.user}
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.callback-handler
= #usernameTokenPasswordCallback
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.must-understand
= false
+quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.out-interceptors =
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.features =
#messageCollector
{code}
Best Regards
Freeman
> ws-security.must-understand works only if security.enable.streaming is
[jira] [Commented] (CXF-8940) ws-security.must-understand works only if security.enable.streaming is true
[
https://issues.apache.org/jira/browse/CXF-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772696#comment-17772696
]
Freeman Yue Fang commented on CXF-8940:
---
Hi [~ppalaga],
Thanks for raising this issue!
After the first glance, I don't think this is the problem in CXF. The problem
should be from quarkus-cxf or the test itself. The root cause that the
configuration in your test
{code}
...security.must-understand = false
{code}
doesn't work is that the
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor somehow not
added into the quarkus cxf client
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand. But
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor should be added
by default in CXF by
org.apache.cxf.ws.security.policy.interceptors.WSSecurityInterceptorProvider,
together with PolicyBasedWSS4JStaxOutInterceptor. We have test case in CXF
source code
cxf/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/ut/UsernameTokenPolicyTest.java
and I checked there, the
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor in CXF test is
added and invoked correctly.
The PolicyBasedWSS4JStaxOutInterceptor contains the logic when
security.enable.streaming is true(Stax API based), while
PolicyBasedWSS4JOutInterceptor contains the logic when
security.enable.streaming is false(DOM api based).
If I explicitly add PolicyBasedWSS4JOutInterceptor to your test client, then it
works, but surely the real fix should be somewhere else.
{code}
---
a/integration-tests/ws-security-policy/src/main/resources/application.properties
+++
b/integration-tests/ws-security-policy/src/main/resources/application.properties
@@ -94,6 +94,7 @@
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.trust-store-password = pas
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.username =
${wss.user}
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.callback-handler
= #usernameTokenPasswordCallback
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.must-understand
= false
+quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.out-interceptors =
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor
quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.features =
#messageCollector
{code}
Best Regards
Freeman
> ws-security.must-understand works only if security.enable.streaming is true
> ---
>
> Key: CXF-8940
> URL: https://issues.apache.org/jira/browse/CXF-8940
> Project: CXF
> Issue Type: Bug
>Reporter: Peter Palaga
>Priority: Major
>
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git
> cd quarkus-cxf
> git checkout CXF-8940
> mvnd clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvnd clean test
> -Dtest=UsernameTokenSecurityPolicyTest#helloUsernameTokenNoMustUnderstand
> ...
> [ERROR]
> UsernameTokenSecurityPolicyTest>AbstractUsernameTokenSecurityPolicyTest.helloUsernameTokenNoMustUnderstand:180
>
> Expecting actual:
> "REQ_OUT
> Address: https://localhost:8444/services/helloUsernameToken
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 03fe3642-ab5b-4b85-b712-b8ed107f5a71
> ServiceName: UsernameTokenPolicyHelloService
> PortName: UsernameTokenPolicyHelloServicePort
> PortTypeName: UsernameTokenPolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/;>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
> wsu:Id="UsernameToken-4e64841c-ad35-48fd-b7ee-70e5f978e098">
> cxf-user
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText;>secret
> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary;>5rs0Ra3q0FPLXFguajlTwQ==
> 2023-10-05T22:40:54.436Z
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/;>
> helloUsernameTokenNoMustUnderstand
>
>
>
> "
> not to contain:
> "soap:mustUnderstand="1""
> {code}
> Running the same logic with
> {{quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.enable.streaming
> = true}} works as expected:
> {code}
> mvnd clean
[jira] [Commented] (CXF-8880) Catch wrong XML binding file during parsing
[
https://issues.apache.org/jira/browse/CXF-8880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729318#comment-17729318
]
Freeman Yue Fang commented on CXF-8880:
---
fixed by
https://github.com/apache/cxf/commit/6266242cb5e720efdd0add51842ea953376494f9
> Catch wrong XML binding file during parsing
> ---
>
> Key: CXF-8880
> URL: https://issues.apache.org/jira/browse/CXF-8880
> Project: CXF
> Issue Type: Bug
>Reporter: Lukas Lowinger
>Assignee: Freeman Yue Fang
>Priority: Critical
> Fix For: 4.0.2
>
>
> Taking this example
> https://github.com/apache/camel-spring-boot-examples/tree/bd9f51ed67d74fa5f4e8c4b40935ef88e7089274/soap-cxf
>
> (which uses _cxf-codegen-plugin:3.10.1:wsdl2java_) and running `mvn clean
> package` will generate class *Customer.java* with
> {noformat}protected LocalDate birthDate;{noformat}
> but when changing version to _cxf-codegen-plugin:4.0.0:wsdl2java_ it will
> generate
> {noformat}protected XMLGregorianCalendar birthDate;{noformat}
> Which means the binding XML was not used, the problem is that we must use
> {code}
> xmlns:jaxws="https://jakarta.ee/xml/ns/jaxws;
> xmlns:jxb="https://jakarta.ee/xml/ns/jaxb;
> {code}
> instead of
> {code}
> xmlns:jaxws="https://java.sun.com/xml/ns/jaxws;
> xmlns:jxb="https://java.sun.com/xml/ns/jaxb;
> {code}
> The problem is, that the cxf-codegen plugin doesn't throw any error while
> loading such wrong XML binding file. Which could lead to problems during
> upgrading to newer CXF codegen plugin. It should also be documented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8880) Catch wrong XML binding file during parsing
[
https://issues.apache.org/jira/browse/CXF-8880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-8880.
---
Fix Version/s: 4.0.2
Resolution: Fixed
> Catch wrong XML binding file during parsing
> ---
>
> Key: CXF-8880
> URL: https://issues.apache.org/jira/browse/CXF-8880
> Project: CXF
> Issue Type: Bug
>Reporter: Lukas Lowinger
>Assignee: Freeman Yue Fang
>Priority: Critical
> Fix For: 4.0.2
>
>
> Taking this example
> https://github.com/apache/camel-spring-boot-examples/tree/bd9f51ed67d74fa5f4e8c4b40935ef88e7089274/soap-cxf
>
> (which uses _cxf-codegen-plugin:3.10.1:wsdl2java_) and running `mvn clean
> package` will generate class *Customer.java* with
> {noformat}protected LocalDate birthDate;{noformat}
> but when changing version to _cxf-codegen-plugin:4.0.0:wsdl2java_ it will
> generate
> {noformat}protected XMLGregorianCalendar birthDate;{noformat}
> Which means the binding XML was not used, the problem is that we must use
> {code}
> xmlns:jaxws="https://jakarta.ee/xml/ns/jaxws;
> xmlns:jxb="https://jakarta.ee/xml/ns/jaxb;
> {code}
> instead of
> {code}
> xmlns:jaxws="https://java.sun.com/xml/ns/jaxws;
> xmlns:jxb="https://java.sun.com/xml/ns/jaxb;
> {code}
> The problem is, that the cxf-codegen plugin doesn't throw any error while
> loading such wrong XML binding file. Which could lead to problems during
> upgrading to newer CXF codegen plugin. It should also be documented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-8880) Catch wrong XML binding file during parsing
[
https://issues.apache.org/jira/browse/CXF-8880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang reassigned CXF-8880:
-
Assignee: Freeman Yue Fang
> Catch wrong XML binding file during parsing
> ---
>
> Key: CXF-8880
> URL: https://issues.apache.org/jira/browse/CXF-8880
> Project: CXF
> Issue Type: Bug
>Reporter: Lukas Lowinger
>Assignee: Freeman Yue Fang
>Priority: Critical
>
> Taking this example
> https://github.com/apache/camel-spring-boot-examples/tree/bd9f51ed67d74fa5f4e8c4b40935ef88e7089274/soap-cxf
>
> (which uses _cxf-codegen-plugin:3.10.1:wsdl2java_) and running `mvn clean
> package` will generate class *Customer.java* with
> {noformat}protected LocalDate birthDate;{noformat}
> but when changing version to _cxf-codegen-plugin:4.0.0:wsdl2java_ it will
> generate
> {noformat}protected XMLGregorianCalendar birthDate;{noformat}
> Which means the binding XML was not used, the problem is that we must use
> {code}
> xmlns:jaxws="https://jakarta.ee/xml/ns/jaxws;
> xmlns:jxb="https://jakarta.ee/xml/ns/jaxb;
> {code}
> instead of
> {code}
> xmlns:jaxws="https://java.sun.com/xml/ns/jaxws;
> xmlns:jxb="https://java.sun.com/xml/ns/jaxb;
> {code}
> The problem is, that the cxf-codegen plugin doesn't throw any error while
> loading such wrong XML binding file. Which could lead to problems during
> upgrading to newer CXF codegen plugin. It should also be documented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXFXJC-34) Code generation breaks on boolean restricted to 0 or 1
[ https://issues.apache.org/jira/browse/CXFXJC-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488159#comment-17488159 ] Freeman Yue Fang commented on CXFXJC-34: Hi [~ElectRocnic], Yes, cxf-xjc 3.3.1 release has already contained the fix. Thanks! Freeman > Code generation breaks on boolean restricted to 0 or 1 > -- > > Key: CXFXJC-34 > URL: https://issues.apache.org/jira/browse/CXFXJC-34 > Project: CXF XJC Utils > Issue Type: Bug > Components: Maven Plugin >Affects Versions: 3.3.0 >Reporter: Ruud de Jong >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 3.3.1 > > > Exception in thread "main" java.lang.InternalError: Unable to load source > code of com.sun.tools.xjc.runtime.ZeroOneBooleanAdapter as a resource > at > com.sun.codemodel.fmt.JStaticJavaFile$ResourceLoader.getResourceAsStream(JStaticJavaFile.java:234) > at com.sun.codemodel.fmt.JStaticJavaFile.build(JStaticJavaFile.java:84) > at com.sun.codemodel.JPackage.build(JPackage.java:446) > at com.sun.codemodel.JCodeModel.build(JCodeModel.java:327) > at com.sun.codemodel.JCodeModel.build(JCodeModel.java:317) > at org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:226) > at > org.apache.cxf.maven_plugin.AbstractXSDToJavaMojo.run(AbstractXSDToJavaMojo.java:368) > at > org.apache.cxf.maven_plugin.AbstractXSDToJavaMojo.execute(AbstractXSDToJavaMojo.java:276) > at org.apache.cxf.maven_plugin.XSDToJavaMojo.execute(XSDToJavaMojo.java:41) > > This happens in 3.3.0 (not in 3.2.3). > > The XSD uses this definition: > > > > > > > > which triggers a special piece of code within JCodeModel of jaxb-xjc and > tries to copy some Java source file from classpath. > Apparently, this has changed from 3.2.3 to 3.3.0 and does not work properly > anymore within the Maven plugin scope. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CXFXJC-34) Code generation breaks on boolean restricted to 0 or 1
[ https://issues.apache.org/jira/browse/CXFXJC-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang resolved CXFXJC-34. Fix Version/s: 3.3.1 Resolution: Fixed > Code generation breaks on boolean restricted to 0 or 1 > -- > > Key: CXFXJC-34 > URL: https://issues.apache.org/jira/browse/CXFXJC-34 > Project: CXF XJC Utils > Issue Type: Bug > Components: Maven Plugin >Affects Versions: 3.3.0 >Reporter: Ruud de Jong >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 3.3.1 > > > Exception in thread "main" java.lang.InternalError: Unable to load source > code of com.sun.tools.xjc.runtime.ZeroOneBooleanAdapter as a resource > at > com.sun.codemodel.fmt.JStaticJavaFile$ResourceLoader.getResourceAsStream(JStaticJavaFile.java:234) > at com.sun.codemodel.fmt.JStaticJavaFile.build(JStaticJavaFile.java:84) > at com.sun.codemodel.JPackage.build(JPackage.java:446) > at com.sun.codemodel.JCodeModel.build(JCodeModel.java:327) > at com.sun.codemodel.JCodeModel.build(JCodeModel.java:317) > at org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:226) > at > org.apache.cxf.maven_plugin.AbstractXSDToJavaMojo.run(AbstractXSDToJavaMojo.java:368) > at > org.apache.cxf.maven_plugin.AbstractXSDToJavaMojo.execute(AbstractXSDToJavaMojo.java:276) > at org.apache.cxf.maven_plugin.XSDToJavaMojo.execute(XSDToJavaMojo.java:41) > > This happens in 3.3.0 (not in 3.2.3). > > The XSD uses this definition: > > > > > > > > which triggers a special piece of code within JCodeModel of jaxb-xjc and > tries to copy some Java source file from classpath. > Apparently, this has changed from 3.2.3 to 3.3.0 and does not work properly > anymore within the Maven plugin scope. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CXF-8647) add DisallowedMethodsHandler for cxf http-undertow transport
[ https://issues.apache.org/jira/browse/CXF-8647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang resolved CXF-8647. --- Fix Version/s: 3.4.6 3.5.1 4.0.0 Resolution: Fixed > add DisallowedMethodsHandler for cxf http-undertow transport > > > Key: CXF-8647 > URL: https://issues.apache.org/jira/browse/CXF-8647 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 3.4.6, 3.5.1, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (CXF-8647) add DisallowedMethodsHandler for cxf http-undertow transport
[ https://issues.apache.org/jira/browse/CXF-8647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang reassigned CXF-8647: - Assignee: Freeman Yue Fang > add DisallowedMethodsHandler for cxf http-undertow transport > > > Key: CXF-8647 > URL: https://issues.apache.org/jira/browse/CXF-8647 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CXF-8647) add DisallowedMethodsHandler for cxf http-undertow transport
Freeman Yue Fang created CXF-8647: - Summary: add DisallowedMethodsHandler for cxf http-undertow transport Key: CXF-8647 URL: https://issues.apache.org/jira/browse/CXF-8647 Project: CXF Issue Type: Improvement Reporter: Freeman Yue Fang -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CXF-8644) introduce a cache for AbstractJAXBProvider to avoid unnecessary ObjectFactory.class|jaxb.index availability check
[ https://issues.apache.org/jira/browse/CXF-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang resolved CXF-8644. --- Fix Version/s: 3.4.6 3.5.1 4.0.0 Resolution: Fixed > introduce a cache for AbstractJAXBProvider to avoid unnecessary > ObjectFactory.class|jaxb.index availability check > -- > > Key: CXF-8644 > URL: https://issues.apache.org/jira/browse/CXF-8644 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 3.4.6, 3.5.1, 4.0.0 > > > So for a certain class type, we only check once -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CXF-8644) introduce a cache for AbstractJAXBProvider to avoid unnecessary ObjectFactory.class|jaxb.index availability check
Freeman Yue Fang created CXF-8644: - Summary: introduce a cache for AbstractJAXBProvider to avoid unnecessary ObjectFactory.class|jaxb.index availability check Key: CXF-8644 URL: https://issues.apache.org/jira/browse/CXF-8644 Project: CXF Issue Type: Improvement Reporter: Freeman Yue Fang Assignee: Freeman Yue Fang So for a certain class type, we only check once -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CXF-8641) NPE on NamePasswordCallbackHandler
[
https://issues.apache.org/jira/browse/CXF-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-8641.
---
Fix Version/s: 3.4.6
3.5.1
4.0.0
Resolution: Fixed
patch applied on behalf of [~globalbus] with thanks!
> NPE on NamePasswordCallbackHandler
> --
>
> Key: CXF-8641
> URL: https://issues.apache.org/jira/browse/CXF-8641
> Project: CXF
> Issue Type: Bug
> Components: Core
>Reporter: Jan Filipski
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.4.6, 3.5.1, 4.0.0
>
>
> If Basic Auth password is empty, AbstractHTTPDestination sets password to
> null.
> Later, if NamePasswordCallbackHandler is used, it calls String.toCharArray()
> on null password.
> Standard authentication error should be present, without NullPointerException
> Stacktrace looks like that
> {code:java}
> org.apache.cxf.interceptor.security.AuthenticationException: Authentication
> failed: java.lang.NullPointerException
> at
> org.apache.cxf.interceptor.security.NamePasswordCallbackHandler.handle(NamePasswordCallbackHandler.java:67)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:904)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:901)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:901)
> at
> org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.doLogin(LdapLoginModule.java:49)
> at
> org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.login(LdapLoginModule.java:37)
> at
> org.apache.karaf.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:83)
> at
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> at
> java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
> at
> org.apache.cxf.interceptor.security.JAASLoginInterceptor.handleMessage(JAASLoginInterceptor.java:140)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:220)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:763)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1631)
> at
> org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1618)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:549)
> at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
>
[jira] [Commented] (CXF-8640) Missing OSGi import javax.xml.ws in cxf bundles
[ https://issues.apache.org/jira/browse/CXF-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477901#comment-17477901 ] Freeman Yue Fang commented on CXF-8640: --- Hi [~globalbus], This is expected behaviour per OSGi classloader delegation mechanism. cxf-rt-features-logging bundle imports package org.apache.cxf.feature, and org.apache.cxf.feature.AbstractFeature class which extends javax.xml.ws.WebServiceFeature is in cxf-core bundle, and cxf-core bundle imports javax.xml.ws package. And this works by my test with Karaf+JDK11. If this doesn't work for you, please elaborate the Karaf/CXF version you use, as well as the detailed step to reproduce it. Thanks! Freeman > Missing OSGi import javax.xml.ws in cxf bundles > --- > > Key: CXF-8640 > URL: https://issues.apache.org/jira/browse/CXF-8640 > Project: CXF > Issue Type: Bug > Components: OSGi > Environment: Issue is only visible on JDK9 or higher (where > javax.xml.ws package is not present in JDK directly). > Can be easily reproduced on Karaf container if you try to install > cxf-logging-feature. >Reporter: Jan Filipski >Assignee: Freeman Yue Fang >Priority: Minor > > cxf-rt-features-logging bundle has missing import to javax.xml.ws package. > This affects probably all versions. > LoggingFeature class has indirect dependency to > javax.xml.ws.WebServiceFeature, by extending AbstractFeature. > Issue is directly visible, because OSGi Activator calls constructor in start > method. That's blocking bundle activation. Probably all bundles with classes > extending AbstractFeature has the same issue. > Not-so-elegant solution is to add javax.xml.ws package to classpath, > imitating JDK8 and lower behavior (as I do for years). Target resolution > should be provided by importing required package by cxf bundles. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (CXF-8641) NPE on NamePasswordCallbackHandler
[
https://issues.apache.org/jira/browse/CXF-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang reassigned CXF-8641:
-
Assignee: Freeman Yue Fang
> NPE on NamePasswordCallbackHandler
> --
>
> Key: CXF-8641
> URL: https://issues.apache.org/jira/browse/CXF-8641
> Project: CXF
> Issue Type: Bug
> Components: Core
>Reporter: Jan Filipski
>Assignee: Freeman Yue Fang
>Priority: Major
>
> If Basic Auth password is empty, AbstractHTTPDestination sets password to
> null.
> Later, if NamePasswordCallbackHandler is used, it calls String.toCharArray()
> on null password.
> Standard authentication error should be present, without NullPointerException
> Stacktrace looks like that
> {code:java}
> org.apache.cxf.interceptor.security.AuthenticationException: Authentication
> failed: java.lang.NullPointerException
> at
> org.apache.cxf.interceptor.security.NamePasswordCallbackHandler.handle(NamePasswordCallbackHandler.java:67)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:904)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:901)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:901)
> at
> org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.doLogin(LdapLoginModule.java:49)
> at
> org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.login(LdapLoginModule.java:37)
> at
> org.apache.karaf.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:83)
> at
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> at
> java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
> at
> org.apache.cxf.interceptor.security.JAASLoginInterceptor.handleMessage(JAASLoginInterceptor.java:140)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:220)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:763)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1631)
> at
> org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1618)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:549)
> at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1363)
> at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:298)
> at
>
[jira] [Assigned] (CXF-8640) Missing OSGi import javax.xml.ws in cxf bundles
[ https://issues.apache.org/jira/browse/CXF-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang reassigned CXF-8640: - Assignee: Freeman Yue Fang > Missing OSGi import javax.xml.ws in cxf bundles > --- > > Key: CXF-8640 > URL: https://issues.apache.org/jira/browse/CXF-8640 > Project: CXF > Issue Type: Bug > Components: OSGi > Environment: Issue is only visible on JDK9 or higher (where > javax.xml.ws package is not present in JDK directly). > Can be easily reproduced on Karaf container if you try to install > cxf-logging-feature. >Reporter: Jan Filipski >Assignee: Freeman Yue Fang >Priority: Minor > > cxf-rt-features-logging bundle has missing import to javax.xml.ws package. > This affects probably all versions. > LoggingFeature class has indirect dependency to > javax.xml.ws.WebServiceFeature, by extending AbstractFeature. > Issue is directly visible, because OSGi Activator calls constructor in start > method. That's blocking bundle activation. Probably all bundles with classes > extending AbstractFeature has the same issue. > Not-so-elegant solution is to add javax.xml.ws package to classpath, > imitating JDK8 and lower behavior (as I do for years). Target resolution > should be provided by importing required package by cxf bundles. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CXF-8639) CXF client exception: Interceptor for {XXX} has thrown exception, unwinding now..............401unauthrized
[
https://issues.apache.org/jira/browse/CXF-8639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-8639.
---
Resolution: Not A Problem
> CXF client exception: Interceptor for {XXX} has thrown exception, unwinding
> now..401unauthrized
> ---
>
> Key: CXF-8639
> URL: https://issues.apache.org/jira/browse/CXF-8639
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Reporter: Soungoo
>Priority: Critical
>
> Hi all,
> I am facing 'org.apache.cxf.interceptor.Fault: Could not send Message.' when
> we submit soap request to CRM.
> * xmlns:soap="[http://schemas.xmlsoap.org/soap/envelope/];>
> xmlns:ns2="urn:sap-com:document:sap:soap:functions:mc-style">*
> *...*
> **
> *Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '401:
> Unauthorized' when communicating with
> [http://:8000/sap/bc/srt/scs/sap/test1?sap-client=600|https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/cxf-client-exception-interceptor-for-xxx-has-thrown-exception/m-p/437106]*
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CXF-8639) CXF client exception: Interceptor for {XXX} has thrown exception, unwinding now..............401unauthrized
[
https://issues.apache.org/jira/browse/CXF-8639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476114#comment-17476114
]
Freeman Yue Fang commented on CXF-8639:
---
Hi [~Soung],
This '401: Unauthorized' response normally means the server of webservice
requires authorization(like token or username/password thing).
This isn't something wrong from CXF stack, and you can send further questions
to CXF mailing list.
https://cxf.apache.org/mailing-lists.html
Thanks!
Freeman
> CXF client exception: Interceptor for {XXX} has thrown exception, unwinding
> now..401unauthrized
> ---
>
> Key: CXF-8639
> URL: https://issues.apache.org/jira/browse/CXF-8639
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Reporter: Soungoo
>Priority: Critical
>
> Hi all,
> I am facing 'org.apache.cxf.interceptor.Fault: Could not send Message.' when
> we submit soap request to CRM.
> * xmlns:soap="[http://schemas.xmlsoap.org/soap/envelope/];>
> xmlns:ns2="urn:sap-com:document:sap:soap:functions:mc-style">*
> *...*
> **
> *Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '401:
> Unauthorized' when communicating with
> [http://:8000/sap/bc/srt/scs/sap/test1?sap-client=600|https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/cxf-client-exception-interceptor-for-xxx-has-thrown-exception/m-p/437106]*
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CXF-8633) "http.responseMessage" gets lost in AbstractClient#setResponseBuilder
[ https://issues.apache.org/jira/browse/CXF-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang resolved CXF-8633. --- Fix Version/s: 3.4.6 4.0.0 3.5.1 Resolution: Fixed > "http.responseMessage" gets lost in AbstractClient#setResponseBuilder > - > > Key: CXF-8633 > URL: https://issues.apache.org/jira/browse/CXF-8633 > Project: CXF > Issue Type: Bug >Affects Versions: 3.4.5 >Reporter: Rob Audenaerde >Assignee: Freeman Yue Fang >Priority: Minor > Fix For: 3.4.6, 4.0.0, 3.5.1 > > > The `http.responseMessage` is correctly returned in the `inMessage`. However, > when converting to `ResponseBuilder` in `setResponseBuilder()` only the > status is used, not the message > JAXRSUtils.toResponseBuilder(status) > Please include the reasonphrase there as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (CXF-8633) "http.responseMessage" gets lost in AbstractClient#setResponseBuilder
[ https://issues.apache.org/jira/browse/CXF-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang reassigned CXF-8633: - Assignee: Freeman Yue Fang > "http.responseMessage" gets lost in AbstractClient#setResponseBuilder > - > > Key: CXF-8633 > URL: https://issues.apache.org/jira/browse/CXF-8633 > Project: CXF > Issue Type: Bug >Affects Versions: 3.4.5 >Reporter: Rob Audenaerde >Assignee: Freeman Yue Fang >Priority: Minor > > The `http.responseMessage` is correctly returned in the `inMessage`. However, > when converting to `ResponseBuilder` in `setResponseBuilder()` only the > status is used, not the message > JAXRSUtils.toResponseBuilder(status) > Please include the reasonphrase there as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CXF-8626) async http client may handle response by multiple threads on work queue
[
https://issues.apache.org/jira/browse/CXF-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460221#comment-17460221
]
Freeman Yue Fang commented on CXF-8626:
---
Hi [~reta],
I think HttpClient 5 has a different issue, you are right, seems it can't
handle the chunked input, no matter retransmit is enabled or not.
For the HttpClient4, it's just a corner case, when enabling retransmit(another
layer of CachedSteam is introduced) && chunklength async http client may handle response by multiple threads on work queue
> ---
>
> Key: CXF-8626
> URL: https://issues.apache.org/jira/browse/CXF-8626
> Project: CXF
> Issue Type: Bug
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.5.0, 3.4.6, 3.3.13
>
>
> In the AsyncHttpConduit, we have code like
> {code}
> protected synchronized void setHttpResponse(HttpResponse r) {
> httpResponse = r;
> if (isAsync) {
> //got a response, need to start the response processing now
> try {
> handleResponseOnWorkqueue(false, true);
> isAsync = false; // don't trigger another start on next
> block. :-)
> } catch (Exception ex) {
> //ignore, we'll try again on the next consume;
> }
> }
> notifyAll();
> }
> {code}
> which intends to spin only one threads to handle response, not matter how
> many blocks the response contains. However, in some cases, the isAsync field
> can be reset true by handleResponseAsync method, hence the second thread can
> be launched to handle the same response stream, so can mess up the response
> stream. Actually isAsync has already been initialized correctly when the
> first time to create AsyncWrappedOutputStream, so method handleResponseAsync
> shouldn't reset it.
> We can see this problem when enabling retransmit && chunklength
[jira] [Resolved] (CXF-8627) AttachmentDataSource should always returns a valid contentType
[
https://issues.apache.org/jira/browse/CXF-8627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-8627.
---
Fix Version/s: 3.5.0
3.4.6
3.3.13
Resolution: Fixed
> AttachmentDataSource should always returns a valid contentType
> --
>
> Key: CXF-8627
> URL: https://issues.apache.org/jira/browse/CXF-8627
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.5.0, 3.4.6, 3.3.13
>
>
> Per the javax.activation.DataSource API
> {code}
> /**
> * This method returns the MIME type of the data in the form of a
> * string. It should always return a valid type. It is suggested
> * that getContentType return "application/octet-stream" if the
> * DataSource implementation can not determine the data type.
> *
> * @return the MIME Type
> */
> public String getContentType();
> {code}
> So cxf AttachmentDataSource should also follow this. For the case that the
> incoming soap message with attachments, if the MIME part doesn't specify a
> content-type, use the general
> "application/octet-stream"
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CXF-8626) async http client may handle response by multiple threads on work queue
[
https://issues.apache.org/jira/browse/CXF-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-8626.
---
Fix Version/s: 3.5.0
3.4.6
3.3.13
Resolution: Fixed
> async http client may handle response by multiple threads on work queue
> ---
>
> Key: CXF-8626
> URL: https://issues.apache.org/jira/browse/CXF-8626
> Project: CXF
> Issue Type: Bug
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.5.0, 3.4.6, 3.3.13
>
>
> In the AsyncHttpConduit, we have code like
> {code}
> protected synchronized void setHttpResponse(HttpResponse r) {
> httpResponse = r;
> if (isAsync) {
> //got a response, need to start the response processing now
> try {
> handleResponseOnWorkqueue(false, true);
> isAsync = false; // don't trigger another start on next
> block. :-)
> } catch (Exception ex) {
> //ignore, we'll try again on the next consume;
> }
> }
> notifyAll();
> }
> {code}
> which intends to spin only one threads to handle response, not matter how
> many blocks the response contains. However, in some cases, the isAsync field
> can be reset true by handleResponseAsync method, hence the second thread can
> be launched to handle the same response stream, so can mess up the response
> stream. Actually isAsync has already been initialized correctly when the
> first time to create AsyncWrappedOutputStream, so method handleResponseAsync
> shouldn't reset it.
> We can see this problem when enabling retransmit && chunklength
[jira] [Created] (CXF-8627) AttachmentDataSource should always returns a valid contentType
Freeman Yue Fang created CXF-8627:
-
Summary: AttachmentDataSource should always returns a valid
contentType
Key: CXF-8627
URL: https://issues.apache.org/jira/browse/CXF-8627
Project: CXF
Issue Type: Improvement
Reporter: Freeman Yue Fang
Per the javax.activation.DataSource API
{code}
/**
* This method returns the MIME type of the data in the form of a
* string. It should always return a valid type. It is suggested
* that getContentType return "application/octet-stream" if the
* DataSource implementation can not determine the data type.
*
* @return the MIME Type
*/
public String getContentType();
{code}
So cxf AttachmentDataSource should also follow this. For the case that the
incoming soap message with attachments, if the MIME part doesn't specify a
content-type, use the general
"application/octet-stream"
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (CXF-8627) AttachmentDataSource should always returns a valid contentType
[
https://issues.apache.org/jira/browse/CXF-8627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang reassigned CXF-8627:
-
Assignee: Freeman Yue Fang
> AttachmentDataSource should always returns a valid contentType
> --
>
> Key: CXF-8627
> URL: https://issues.apache.org/jira/browse/CXF-8627
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
>
> Per the javax.activation.DataSource API
> {code}
> /**
> * This method returns the MIME type of the data in the form of a
> * string. It should always return a valid type. It is suggested
> * that getContentType return "application/octet-stream" if the
> * DataSource implementation can not determine the data type.
> *
> * @return the MIME Type
> */
> public String getContentType();
> {code}
> So cxf AttachmentDataSource should also follow this. For the case that the
> incoming soap message with attachments, if the MIME part doesn't specify a
> content-type, use the general
> "application/octet-stream"
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (CXF-8626) async http client may handle response by multiple threads on work queue
[
https://issues.apache.org/jira/browse/CXF-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang reassigned CXF-8626:
-
Assignee: Freeman Yue Fang
> async http client may handle response by multiple threads on work queue
> ---
>
> Key: CXF-8626
> URL: https://issues.apache.org/jira/browse/CXF-8626
> Project: CXF
> Issue Type: Bug
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
>
> In the AsyncHttpConduit, we have code like
> {code}
> protected synchronized void setHttpResponse(HttpResponse r) {
> httpResponse = r;
> if (isAsync) {
> //got a response, need to start the response processing now
> try {
> handleResponseOnWorkqueue(false, true);
> isAsync = false; // don't trigger another start on next
> block. :-)
> } catch (Exception ex) {
> //ignore, we'll try again on the next consume;
> }
> }
> notifyAll();
> }
> {code}
> which intends to spin only one threads to handle response, not matter how
> many blocks the response contains. However, in some cases, the isAsync field
> can be reset true by handleResponseAsync method, hence the second thread can
> be launched to handle the same response stream, so can mess up the response
> stream. Actually isAsync has already been initialized correctly when the
> first time to create AsyncWrappedOutputStream, so method handleResponseAsync
> shouldn't reset it.
> We can see this problem when enabling retransmit && chunklength
[jira] [Created] (CXF-8626) async http client may handle response by multiple threads on work queue
Freeman Yue Fang created CXF-8626:
-
Summary: async http client may handle response by multiple threads
on work queue
Key: CXF-8626
URL: https://issues.apache.org/jira/browse/CXF-8626
Project: CXF
Issue Type: Bug
Reporter: Freeman Yue Fang
In the AsyncHttpConduit, we have code like
{code}
protected synchronized void setHttpResponse(HttpResponse r) {
httpResponse = r;
if (isAsync) {
//got a response, need to start the response processing now
try {
handleResponseOnWorkqueue(false, true);
isAsync = false; // don't trigger another start on next
block. :-)
} catch (Exception ex) {
//ignore, we'll try again on the next consume;
}
}
notifyAll();
}
{code}
which intends to spin only one threads to handle response, not matter how many
blocks the response contains. However, in some cases, the isAsync field can be
reset true by handleResponseAsync method, hence the second thread can be
launched to handle the same response stream, so can mess up the response
stream. Actually isAsync has already been initialized correctly when the first
time to create AsyncWrappedOutputStream, so method handleResponseAsync
shouldn't reset it.
We can see this problem when enabling retransmit && chunklength
[jira] [Commented] (CXF-8622) Issue with serving schema files over http
[
https://issues.apache.org/jira/browse/CXF-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17456583#comment-17456583
]
Freeman Yue Fang commented on CXF-8622:
---
Thanks for the update [~ashishsingh]
And please find the latest update here
https://issues.apache.org/jira/browse/INFRA-22590
This should be resolved
> Issue with serving schema files over http
> -
>
> Key: CXF-8622
> URL: https://issues.apache.org/jira/browse/CXF-8622
> Project: CXF
> Issue Type: Bug
>Reporter: Jeff
>Priority: Major
>
> Hello,
> We use spring framework libraries and they're utilizing sites on apache such
> as:
> [http://cxf.apache.org/schemas/jaxrs.xsd]
> The error we currently get is the following:
> {code}
> 2021-12-03 16:54:51,760 ERROR - Context initialization failed
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 1
> in XML document from ServletContext resource
> [/WEB-INF/application-context.xml] is invalid; nested exception is
> org.xml.sax.SAXParseException; systemId:
> http://cxf.apache.org/schemas/jaxrs.xsd; lineNumber: 1; columnNumber: 1;
> Premature end of file.
> at
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:399)
> at
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:336)
> {code}
> We believe this is due to the fact that http isn't serving the schema file.
> We had this working yesterday so believe that something may have changed
> recently around this. A similar bug that we found I believe is here:
> https://issues.apache.org/jira/browse/CAMEL-13890
> We tried internally referencing the https location. e.g.
> [https://cxf.apache.org/schemas/jaxrs.xsd] but then we get a schema doesn't
> match error.
> {code}
> Caused by: org.xml.sax.SAXParseException; systemId:
> https://cxf.apache.org/schemas/jaxrs.xsd; lineNumber: 28; columnNumber: 40;
> TargetNamespace.1: Expecting namespace 'https://cxf.apache.org/jaxrs', but
> the target namespace of the schema document is 'http://cxf.apache.org/jaxrs'.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:396)
> {code}
> Also when we do curl here vs doing curl in https the body is different as
> expected:
> {code:java}
> platform % curl -vvv http://cxf.apache.org/schemas/jaxrs.xsd
> * Trying 151.101.2.132...
> * TCP_NODELAY set
> * Connected to cxf.apache.org (151.101.2.132) port 80 (#0)
> > GET /schemas/jaxrs.xsd HTTP/1.1
> > Host: cxf.apache.org
> > User-Agent: curl/7.64.1
> > Accept: */*
> >
> < HTTP/1.1 301 Moved Permanently
> < Server: Varnish
> < Retry-After: 0
> < Location: https://cxf.apache.org/schemas/jaxrs.xsd
> < Content-Length: 0
> < Accept-Ranges: bytes
> < Date: Sat, 04 Dec 2021 01:28:38 GMT
> < Via: 1.1 varnish
> < Connection: close
> < X-Served-By: cache-bos4646-BOS
> < X-Cache: HIT
> < X-Cache-Hits: 0
> < X-Timer: S1638581319.719643,VS0,VE0
> < Strict-Transport-Security: max-age=300
> <
> * Closing connection 0{code}
> Here's an example of the application-context.xml file that we have where
> springframework.org files serve fine over http
> {code}
> http://www.springframework.org/schema/context;
> xmlns="http://www.springframework.org/schema/beans;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xmlns:jaxrs="http://cxf.apache.org/jaxrs;
> xmlns:jaxws="http://cxf.apache.org/jaxws;
> xsi:schemaLocation="http://www.springframework.org/schema/beans
>
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/context
>
> http://www.springframework.org/schema/context/spring-context.xsd
> http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/jaxrs.xsd
> http://cxf.apache.org/jaxws
> http://cxf.apache.org/schemas/jaxws.xsd;>
> {code}
> Any help around this is greatly appreciated, thanks!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CXF-8623) XSD Not Served over HTTP
[
https://issues.apache.org/jira/browse/CXF-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17456581#comment-17456581
]
Freeman Yue Fang commented on CXF-8623:
---
Please find the latest update here
https://issues.apache.org/jira/browse/INFRA-22590
This should be resolved
> XSD Not Served over HTTP
>
>
> Key: CXF-8623
> URL: https://issues.apache.org/jira/browse/CXF-8623
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Reporter: Kevin Burnett
>Priority: Major
> Attachments: image-2021-12-06-18-03-55-276.png
>
>
> First of all, thanks for the work you do and making a tool that helps a lot
> of people. I don't know if this issue is best served here, or should go to
> the cxf.apache.org website managers.
> Anyways, I'm loading a webservice module via OSGi and am receiving the
> following error when loading the module:
> {code:java}
> org.xml.sax.SAXParseException; systemId:
> http://cxf.apache.org/schemas/jaxrs.xsd; lineNumber: 1; columnNumber: 1;
> Premature end of file. {code}
>
> When I try to curl the XSD URL, I get nothing returned (however, I do get a
> file returned when curling the HTTPS URL). As a comparison, when I curl the
> Spring Beans XSD,
> [http://www.springframework.org/schema/beans/spring-beans.xsd,] I do get back
> a file.
>
> We just started seeing this today in our production environment, but I could
> reproduce it locally when trying to start the module in OSGi. We hadn't made
> any changes in our production environment other than restarting the OSGi
> service. We discovered the fix was to download the JAX-RS XSD, reference it
> from the class path directly, then update the schema imports in "jaxrs.xsd"
> to be the following:
>
> {code:java}
> http://cxf.apache.org/configuration/beans;
> schemaLocation="https://cxf.apache.org/schemas/configuration/cxf-beans.xsd"/>
> schemaLocation="https://cxf.apache.org/schemas/jaxrs-common.xsd"/> {code}
>
>
> However, it would be nice to not have to make this change and allow the XSD,
> though resolved to https, to still return the XML over http.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CXF-8622) Issue with serving schema files over http
[
https://issues.apache.org/jira/browse/CXF-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454616#comment-17454616
]
Freeman Yue Fang commented on CXF-8622:
---
And please see the related discussion here
https://lists.apache.org/thread/xzo8jjjql3y9lmfm50jpklwqq6tgg2qo
> Issue with serving schema files over http
> -
>
> Key: CXF-8622
> URL: https://issues.apache.org/jira/browse/CXF-8622
> Project: CXF
> Issue Type: Bug
>Reporter: Jeff
>Priority: Major
>
> Hello,
> We use spring framework libraries and they're utilizing sites on apache such
> as:
> [http://cxf.apache.org/schemas/jaxrs.xsd]
> The error we currently get is the following:
> {code}
> 2021-12-03 16:54:51,760 ERROR - Context initialization failed
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 1
> in XML document from ServletContext resource
> [/WEB-INF/application-context.xml] is invalid; nested exception is
> org.xml.sax.SAXParseException; systemId:
> http://cxf.apache.org/schemas/jaxrs.xsd; lineNumber: 1; columnNumber: 1;
> Premature end of file.
> at
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:399)
> at
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:336)
> {code}
> We believe this is due to the fact that http isn't serving the schema file.
> We had this working yesterday so believe that something may have changed
> recently around this. A similar bug that we found I believe is here:
> https://issues.apache.org/jira/browse/CAMEL-13890
> We tried internally referencing the https location. e.g.
> [https://cxf.apache.org/schemas/jaxrs.xsd] but then we get a schema doesn't
> match error.
> {code}
> Caused by: org.xml.sax.SAXParseException; systemId:
> https://cxf.apache.org/schemas/jaxrs.xsd; lineNumber: 28; columnNumber: 40;
> TargetNamespace.1: Expecting namespace 'https://cxf.apache.org/jaxrs', but
> the target namespace of the schema document is 'http://cxf.apache.org/jaxrs'.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:396)
> {code}
> Also when we do curl here vs doing curl in https the body is different as
> expected:
> {code:java}
> platform % curl -vvv http://cxf.apache.org/schemas/jaxrs.xsd
> * Trying 151.101.2.132...
> * TCP_NODELAY set
> * Connected to cxf.apache.org (151.101.2.132) port 80 (#0)
> > GET /schemas/jaxrs.xsd HTTP/1.1
> > Host: cxf.apache.org
> > User-Agent: curl/7.64.1
> > Accept: */*
> >
> < HTTP/1.1 301 Moved Permanently
> < Server: Varnish
> < Retry-After: 0
> < Location: https://cxf.apache.org/schemas/jaxrs.xsd
> < Content-Length: 0
> < Accept-Ranges: bytes
> < Date: Sat, 04 Dec 2021 01:28:38 GMT
> < Via: 1.1 varnish
> < Connection: close
> < X-Served-By: cache-bos4646-BOS
> < X-Cache: HIT
> < X-Cache-Hits: 0
> < X-Timer: S1638581319.719643,VS0,VE0
> < Strict-Transport-Security: max-age=300
> <
> * Closing connection 0{code}
> Here's an example of the application-context.xml file that we have where
> springframework.org files serve fine over http
> {code}
> http://www.springframework.org/schema/context;
> xmlns="http://www.springframework.org/schema/beans;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xmlns:jaxrs="http://cxf.apache.org/jaxrs;
> xmlns:jaxws="http://cxf.apache.org/jaxws;
> xsi:schemaLocation="http://www.springframework.org/schema/beans
>
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/context
>
> http://www.springframework.org/schema/context/spring-context.xsd
> http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/jaxrs.xsd
> http://cxf.apache.org/jaxws
> http://cxf.apache.org/schemas/jaxws.xsd;>
> {code}
> Any help around this is greatly appreciated, thanks!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CXF-8623) XSD Not Served over HTTP
[
https://issues.apache.org/jira/browse/CXF-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454615#comment-17454615
]
Freeman Yue Fang commented on CXF-8623:
---
And please see the related discussion here
https://lists.apache.org/thread/xzo8jjjql3y9lmfm50jpklwqq6tgg2qo
> XSD Not Served over HTTP
>
>
> Key: CXF-8623
> URL: https://issues.apache.org/jira/browse/CXF-8623
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Reporter: Kevin Burnett
>Priority: Major
> Attachments: image-2021-12-06-18-03-55-276.png
>
>
> First of all, thanks for the work you do and making a tool that helps a lot
> of people. I don't know if this issue is best served here, or should go to
> the cxf.apache.org website managers.
> Anyways, I'm loading a webservice module via OSGi and am receiving the
> following error when loading the module:
> {code:java}
> org.xml.sax.SAXParseException; systemId:
> http://cxf.apache.org/schemas/jaxrs.xsd; lineNumber: 1; columnNumber: 1;
> Premature end of file. {code}
>
> When I try to curl the XSD URL, I get nothing returned (however, I do get a
> file returned when curling the HTTPS URL). As a comparison, when I curl the
> Spring Beans XSD,
> [http://www.springframework.org/schema/beans/spring-beans.xsd,] I do get back
> a file.
>
> We just started seeing this today in our production environment, but I could
> reproduce it locally when trying to start the module in OSGi. We hadn't made
> any changes in our production environment other than restarting the OSGi
> service. We discovered the fix was to download the JAX-RS XSD, reference it
> from the class path directly, then update the schema imports in "jaxrs.xsd"
> to be the following:
>
> {code:java}
> http://cxf.apache.org/configuration/beans;
> schemaLocation="https://cxf.apache.org/schemas/configuration/cxf-beans.xsd"/>
> schemaLocation="https://cxf.apache.org/schemas/jaxrs-common.xsd"/> {code}
>
>
> However, it would be nice to not have to make this change and allow the XSD,
> though resolved to https, to still return the XML over http.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CXF-8623) XSD Not Served over HTTP
[
https://issues.apache.org/jira/browse/CXF-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454111#comment-17454111
]
Freeman Yue Fang commented on CXF-8623:
---
Is jaxrs.xsd actually in the META-INF/cxf classpath of your project bundle jar?
If not, I don't think it wouldn't work this way. You should use something like
{code}
http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd
{code}
so that spring.schemas from cxf jars(provided they are in the OSGi container
already) can kick in to resolve the xsd file locally.
Freeman
> XSD Not Served over HTTP
>
>
> Key: CXF-8623
> URL: https://issues.apache.org/jira/browse/CXF-8623
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Reporter: Kevin Burnett
>Priority: Major
>
> First of all, thanks for the work you do and making a tool that helps a lot
> of people. I don't know if this issue is best served here, or should go to
> the cxf.apache.org website managers.
> Anyways, I'm loading a webservice module via OSGi and am receiving the
> following error when loading the module:
> {code:java}
> org.xml.sax.SAXParseException; systemId:
> http://cxf.apache.org/schemas/jaxrs.xsd; lineNumber: 1; columnNumber: 1;
> Premature end of file. {code}
>
> When I try to curl the XSD URL, I get nothing returned (however, I do get a
> file returned when curling the HTTPS URL). As a comparison, when I curl the
> Spring Beans XSD,
> [http://www.springframework.org/schema/beans/spring-beans.xsd,] I do get back
> a file.
>
> We just started seeing this today in our production environment, but I could
> reproduce it locally when trying to start the module in OSGi. We hadn't made
> any changes in our production environment other than restarting the OSGi
> service. We discovered the fix was to download the JAX-RS XSD, reference it
> from the class path directly, then update the schema imports in "jaxrs.xsd"
> to be the following:
>
> {code:java}
> http://cxf.apache.org/configuration/beans;
> schemaLocation="https://cxf.apache.org/schemas/configuration/cxf-beans.xsd"/>
> schemaLocation="https://cxf.apache.org/schemas/jaxrs-common.xsd"/> {code}
>
>
> However, it would be nice to not have to make this change and allow the XSD,
> though resolved to https, to still return the XML over http.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CXF-8623) XSD Not Served over HTTP
[ https://issues.apache.org/jira/browse/CXF-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454085#comment-17454085 ] Freeman Yue Fang commented on CXF-8623: --- Hi, Seems we have several related issues now https://issues.apache.org/jira/browse/CXF-8622 https://issues.apache.org/jira/browse/SM-4967 Which are all caused by "http" protocol now is replaced by "https" protocol by default. One thing still remains unclear to me is that why the remote one is necessary here. We have all xsd files in the local cxf jars, so that via spring.schemas mechanism, the local xsd files should be used instead of the remote one(no matter it's http or https) Best Regards Freeman > XSD Not Served over HTTP > > > Key: CXF-8623 > URL: https://issues.apache.org/jira/browse/CXF-8623 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Reporter: Kevin Burnett >Priority: Major > > First of all, thanks for the work you do and making a tool that helps a lot > of people. I don't know if this issue is best served here, or should go to > the cxf.apache.org website managers. > Anyways, I'm loading a webservice module via OSGi and am receiving the > following error when loading the module: > org.xml.sax.SAXParseException; systemId: > [http://cxf.apache.org/schemas/jaxrs.xsd]; lineNumber: 1; columnNumber: 1; > Premature end of file. > > When I try to curl the XSD URL, I get nothing returned (however, I do get a > file returned when curling the HTTPS URL). As a comparison, when I curl the > Spring Beans XSD, > [http://www.springframework.org/schema/beans/spring-beans.xsd,] I do get back > a file. > > We just started seeing this today in our production environment, but I could > reproduce it locally when trying to start the module in OSGi. We hadn't made > any changes in our production environment other than restarting the OSGi > service. We discovered the fix was to download the JAX-RS XSD, reference it > from the class path directly, then update the schema imports in "jaxrs.xsd" > to be the following: > http://cxf.apache.org/configuration/beans; > schemaLocation="https://cxf.apache.org/schemas/configuration/cxf-beans.xsd"/> > schemaLocation="https://cxf.apache.org/schemas/jaxrs-common.xsd"/> > > However, it would be nice to not have to make this change and allow the XSD, > though resolved to https, to still return the XML over http. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CXF-8622) Issue with serving schema files over http
[
https://issues.apache.org/jira/browse/CXF-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454082#comment-17454082
]
Freeman Yue Fang commented on CXF-8622:
---
Hi,
Seems we have several related issues now
https://issues.apache.org/jira/browse/CXF-8623
https://issues.apache.org/jira/browse/SM-4967
Which are all caused by "http" protocol now is replaced by "https" protocol by
default.
One thing still remains unclear to me is that why the remote one is necessary
here. We have all xsd files in the local cxf jars, so that via spring.schemas
mechanism, the local xsd files should be used instead of the remote one(no
matter it's http or https)
Best Regards
Freeman
> Issue with serving schema files over http
> -
>
> Key: CXF-8622
> URL: https://issues.apache.org/jira/browse/CXF-8622
> Project: CXF
> Issue Type: Bug
>Reporter: Jeff
>Priority: Major
>
> Hello,
> We use spring framework libraries and they're utilizing sites on apache such
> as:
> [http://cxf.apache.org/schemas/jaxrs.xsd]
> The error we currently get is the following:
> {code}
> 2021-12-03 16:54:51,760 ERROR - Context initialization failed
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 1
> in XML document from ServletContext resource
> [/WEB-INF/application-context.xml] is invalid; nested exception is
> org.xml.sax.SAXParseException; systemId:
> http://cxf.apache.org/schemas/jaxrs.xsd; lineNumber: 1; columnNumber: 1;
> Premature end of file.
> at
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:399)
> at
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:336)
> {code}
> We believe this is due to the fact that http isn't serving the schema file.
> We had this working yesterday so believe that something may have changed
> recently around this. A similar bug that we found I believe is here:
> https://issues.apache.org/jira/browse/CAMEL-13890
> We tried internally referencing the https location. e.g.
> [https://cxf.apache.org/schemas/jaxrs.xsd] but then we get a schema doesn't
> match error.
> {code}
> Caused by: org.xml.sax.SAXParseException; systemId:
> https://cxf.apache.org/schemas/jaxrs.xsd; lineNumber: 28; columnNumber: 40;
> TargetNamespace.1: Expecting namespace 'https://cxf.apache.org/jaxrs', but
> the target namespace of the schema document is 'http://cxf.apache.org/jaxrs'.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:396)
> {code}
> Also when we do curl here vs doing curl in https the body is different as
> expected:
> {code:java}
> platform % curl -vvv http://cxf.apache.org/schemas/jaxrs.xsd
> * Trying 151.101.2.132...
> * TCP_NODELAY set
> * Connected to cxf.apache.org (151.101.2.132) port 80 (#0)
> > GET /schemas/jaxrs.xsd HTTP/1.1
> > Host: cxf.apache.org
> > User-Agent: curl/7.64.1
> > Accept: */*
> >
> < HTTP/1.1 301 Moved Permanently
> < Server: Varnish
> < Retry-After: 0
> < Location: https://cxf.apache.org/schemas/jaxrs.xsd
> < Content-Length: 0
> < Accept-Ranges: bytes
> < Date: Sat, 04 Dec 2021 01:28:38 GMT
> < Via: 1.1 varnish
> < Connection: close
> < X-Served-By: cache-bos4646-BOS
> < X-Cache: HIT
> < X-Cache-Hits: 0
> < X-Timer: S1638581319.719643,VS0,VE0
> < Strict-Transport-Security: max-age=300
> <
> * Closing connection 0{code}
> Here's an example of the application-context.xml file that we have where
> springframework.org files serve fine over http
> {code}
> http://www.springframework.org/schema/context;
> xmlns="http://www.springframework.org/schema/beans;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xmlns:jaxrs="http://cxf.apache.org/jaxrs;
> xmlns:jaxws="http://cxf.apache.org/jaxws;
> xsi:schemaLocation="http://www.springframework.org/schema/beans
>
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/context
>
> http://www.springframework.org/schema/context/spring-context.xsd
> http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/jaxrs.xsd
> http://cxf.apache.org/jaxws
> http://cxf.apache.org/schemas/jaxws.xsd;>
> {code}
> Any help around this is greatly appreciated, thanks!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CXF-8045) Disable HTTP TRACE method on CXF http-undertow transport
[ https://issues.apache.org/jira/browse/CXF-8045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17451226#comment-17451226 ] Freeman Yue Fang commented on CXF-8045: --- Sounds good, thanks [~reta]! Freeman > Disable HTTP TRACE method on CXF http-undertow transport > > > Key: CXF-8045 > URL: https://issues.apache.org/jira/browse/CXF-8045 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 3.2.10, 3.3.3 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CXF-8045) Disable HTTP TRACE method on CXF http-undertow transport
[ https://issues.apache.org/jira/browse/CXF-8045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17451221#comment-17451221 ] Freeman Yue Fang commented on CXF-8045: --- Hi [~reta], This ticket is for http-undertow transport, and it actually aligns with the same behaviour as http-jetty(please see CXF-7114, HTTP trace is normally considered as a security risk since it can leak some sensitive info ) If JAX-RS TCK needs TRACE, probably we can introduce another option to enable it(but with the default behaviour that disable HTTP trace for CXF endpoint) Best Regards Freeman > Disable HTTP TRACE method on CXF http-undertow transport > > > Key: CXF-8045 > URL: https://issues.apache.org/jira/browse/CXF-8045 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 3.2.10, 3.3.3 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
