[jira] [Resolved] (CXF-8999) KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java
[
https://issues.apache.org/jira/browse/CXF-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-8999.
--
Resolution: Fixed
> KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java
> -
>
> Key: CXF-8999
> URL: https://issues.apache.org/jira/browse/CXF-8999
> Project: CXF
> Issue Type: Test
>Affects Versions: 4.0.4
>Reporter: Jamie Mark Goodyear
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.5.9, 4.0.5, 3.6.4
>
>
> KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java.
> The test case fails on ClassNotFound com.ibm.security.jgss.InquireType - this
> is thrown due to wss4j-ws-security-common having a hard coded check for IBM
> Java to use the above mentioned class.
> {{KerberosClientExceptionAction.class:}}
> {{`}}
> {{{}try{}}}{{{}{ {}}}
> {{ Class inquireType = Class.forName(IS_IBM_VENDOR ?
> "com.ibm.security.jgss.InquireType" : "com.sun.security.jgss.InquireType"); }}
> {{ Class extendedGSSContext = Class.forName(IS_IBM_VENDOR ?
> "com.ibm.security.jgss.ExtendedGSSContext" :
> "com.sun.security.jgss.ExtendedGSSContext"); }}
> {{ Method inquireSecContext =
> extendedGSSContext.getMethod("inquireSecContext", inquireType); }}
> {{ Key key = (Key)inquireSecContext.invoke(secContext,
> Enum.valueOf(inquireType, "KRB5_GET_SESSION_KEY"));
> krbCtx.setSecretKey(key); }}
> {{ return krbCtx; }}
> {{} }}{{{}catch (NoSuchMethodException | IllegalAccessException |
> InvocationTargetException | ClassNotFoundException var13){}}}{{{}{ {}}}
> {{ throw new WSSecurityException(ErrorCode.FAILURE, var13,
> "kerberosServiceTicketError"); }}
> {{}}}
> `
> Most of the test cases in KerberosTokenTest are set to avoid running when on
> IBM, I believe this test case should also be set to not run. A future
> improvement would be to update wss4j-ws-security-common to be IBM Semeru
> friendly, then update CXF accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8999) KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java
[
https://issues.apache.org/jira/browse/CXF-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-8999:
-
Fix Version/s: 3.5.9
3.6.4
> KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java
> -
>
> Key: CXF-8999
> URL: https://issues.apache.org/jira/browse/CXF-8999
> Project: CXF
> Issue Type: Test
>Affects Versions: 4.0.4
>Reporter: Jamie Mark Goodyear
>Priority: Major
> Fix For: 3.5.9, 4.0.5, 3.6.4
>
>
> KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java.
> The test case fails on ClassNotFound com.ibm.security.jgss.InquireType - this
> is thrown due to wss4j-ws-security-common having a hard coded check for IBM
> Java to use the above mentioned class.
> {{KerberosClientExceptionAction.class:}}
> {{`}}
> {{{}try{}}}{{{}{ {}}}
> {{ Class inquireType = Class.forName(IS_IBM_VENDOR ?
> "com.ibm.security.jgss.InquireType" : "com.sun.security.jgss.InquireType"); }}
> {{ Class extendedGSSContext = Class.forName(IS_IBM_VENDOR ?
> "com.ibm.security.jgss.ExtendedGSSContext" :
> "com.sun.security.jgss.ExtendedGSSContext"); }}
> {{ Method inquireSecContext =
> extendedGSSContext.getMethod("inquireSecContext", inquireType); }}
> {{ Key key = (Key)inquireSecContext.invoke(secContext,
> Enum.valueOf(inquireType, "KRB5_GET_SESSION_KEY"));
> krbCtx.setSecretKey(key); }}
> {{ return krbCtx; }}
> {{} }}{{{}catch (NoSuchMethodException | IllegalAccessException |
> InvocationTargetException | ClassNotFoundException var13){}}}{{{}{ {}}}
> {{ throw new WSSecurityException(ErrorCode.FAILURE, var13,
> "kerberosServiceTicketError"); }}
> {{}}}
> `
> Most of the test cases in KerberosTokenTest are set to avoid running when on
> IBM, I believe this test case should also be set to not run. A future
> improvement would be to update wss4j-ws-security-common to be IBM Semeru
> friendly, then update CXF accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-8999) KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java
[
https://issues.apache.org/jira/browse/CXF-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned CXF-8999:
Assignee: Colm O hEigeartaigh
> KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java
> -
>
> Key: CXF-8999
> URL: https://issues.apache.org/jira/browse/CXF-8999
> Project: CXF
> Issue Type: Test
>Affects Versions: 4.0.4
>Reporter: Jamie Mark Goodyear
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.5.9, 4.0.5, 3.6.4
>
>
> KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java.
> The test case fails on ClassNotFound com.ibm.security.jgss.InquireType - this
> is thrown due to wss4j-ws-security-common having a hard coded check for IBM
> Java to use the above mentioned class.
> {{KerberosClientExceptionAction.class:}}
> {{`}}
> {{{}try{}}}{{{}{ {}}}
> {{ Class inquireType = Class.forName(IS_IBM_VENDOR ?
> "com.ibm.security.jgss.InquireType" : "com.sun.security.jgss.InquireType"); }}
> {{ Class extendedGSSContext = Class.forName(IS_IBM_VENDOR ?
> "com.ibm.security.jgss.ExtendedGSSContext" :
> "com.sun.security.jgss.ExtendedGSSContext"); }}
> {{ Method inquireSecContext =
> extendedGSSContext.getMethod("inquireSecContext", inquireType); }}
> {{ Key key = (Key)inquireSecContext.invoke(secContext,
> Enum.valueOf(inquireType, "KRB5_GET_SESSION_KEY"));
> krbCtx.setSecretKey(key); }}
> {{ return krbCtx; }}
> {{} }}{{{}catch (NoSuchMethodException | IllegalAccessException |
> InvocationTargetException | ClassNotFoundException var13){}}}{{{}{ {}}}
> {{ throw new WSSecurityException(ErrorCode.FAILURE, var13,
> "kerberosServiceTicketError"); }}
> {{}}}
> `
> Most of the test cases in KerberosTokenTest are set to avoid running when on
> IBM, I believe this test case should also be set to not run. A future
> improvement would be to update wss4j-ws-security-common to be IBM Semeru
> friendly, then update CXF accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8995) OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
[
https://issues.apache.org/jira/browse/CXF-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834254#comment-17834254
]
Colm O hEigeartaigh commented on CXF-8995:
--
Can you give a test-case?
> OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds
> for length 7
> -
>
> Key: CXF-8995
> URL: https://issues.apache.org/jira/browse/CXF-8995
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.6.0, 3.6.1, 3.6.2, 3.6.3
>Reporter: Florian Wermelskirchen
>Priority: Major
>
> After upgrading our software to apache camel 3.22.1 and cxf 3.6.2 we get this
> Error running our Tests.
> {code:java}
> 2024-04-02 14:44:01,698 | ERROR | Test worker |
> org.apache.camel.impl.engine.AbstractCamelContext | Error starting
> CamelContext (camel-1) due to exception thrown: Index 7 out of bounds for
> length 7
> java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
> at org.apache.cxf.common.util.OpcodesProxy.(OpcodesProxy.java:37)
> at
> org.apache.cxf.common.util.ASMHelperImpl.getOpCodes(ASMHelperImpl.java:105)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:200)
> at
> org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122)
> at
> org.apache.cxf.jaxws.spi.WrapperClassCreatorProxyService.generate(WrapperClassCreatorProxyService.java:40)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
> at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> at
> org.apache.camel.component.cxf.jaxws.CxfConsumer.createServer(CxfConsumer.java:75)
> at
> org.apache.camel.component.cxf.jaxws.CxfConsumer.doStart(CxfConsumer.java:107)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:119)
> at
> org.apache.camel.support.service.ServiceHelper.startService(ServiceHelper.java:113)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.startService(AbstractCamelContext.java:3760)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRouteConsumers(InternalRouteStartupManager.java:401)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartRouteConsumers(InternalRouteStartupManager.java:319)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.safelyStartRouteServices(InternalRouteStartupManager.java:213)
> at
> org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRoutes(InternalRouteStartupManager.java:147)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartCamel(AbstractCamelContext.java:3445)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStartContext(AbstractCamelContext.java:3114)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.doStart(AbstractCamelContext.java:3069)
> at
> org.apache.camel.spring.boot.SpringBootCamelContext.doStart(SpringBootCamelContext.java:43)
> at
> org.apache.camel.support.service.BaseService.start(BaseService.java:119)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.start(AbstractCamelContext.java:2718)
> at
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:262)
> at
> org.apache.camel.spring.SpringCamelContext.start(SpringCamelContext.java:119)
> at
> org.apache.camel.test.spring.junit5.CamelAnnotationsHandler$8.execute(CamelAnnotationsHandler.java:407)
> at
> org.apache.camel.test.spring.junit5.CamelSpringTestHelper.doToSpringCamelContexts(CamelSpringTestHelper.java:108)
> at
> org.apache.camel.test.spring.junit5.CamelAnnotationsHandler.handleCamelContextStartup(CamelAnnotationsHandler.java:400)
> at
>
[jira] [Closed] (FEDIZ-256) Tomcat authenticationSessionTimeout
[
https://issues.apache.org/jira/browse/FEDIZ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed FEDIZ-256.
-
> Tomcat authenticationSessionTimeout
> ---
>
> Key: FEDIZ-256
> URL: https://issues.apache.org/jira/browse/FEDIZ-256
> Project: CXF-Fediz
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.6.1
>Reporter: Tomas Milian
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 1.6.2
>
>
> Hello,
> I was configuring Fediz 1.6.1 on Tomcat 9.0.74 and found the following issue.
> Tomcat 9.0.74 introduced a new FORM authenticator Valve attribute
> (authenticationSessionTimeout) that breaks Fediz authentication process.
> {color:#172b4d}Fediz uses FormAuthenticator to save the request, the change
> introduced in Tomcat 9.0.74 replaces the original session timeout with the
> authenticationSessionTimeout default value (120 seconds).{color}
> {code:java}
> if (session instanceof HttpSession && ((HttpSession)
> session).isNew()) {
> int originalMaxInactiveInterval =
> session.getMaxInactiveInterval();
> if (originalMaxInactiveInterval >
> getAuthenticationSessionTimeout()) {
>
> saved.setOriginalMaxInactiveInterval(originalMaxInactiveInterval);
>
> session.setMaxInactiveInterval(getAuthenticationSessionTimeout());
> }
> } {code}
> {color:#172b4d}Once the Fediz authentication is resumed, the original session
> maxInactiveInterval is not restored, so authenticated session always ends up
> with a 120 second maxInactiveInterval{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FEDIZ-257) Apache CXF Fediz Tomcat Plugin ver 1.6.1 does not work with Jakarta
[ https://issues.apache.org/jira/browse/FEDIZ-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824509#comment-17824509 ] Colm O hEigeartaigh commented on FEDIZ-257: --- At this point I have no plans to update Fediz with CXF 4.0.0 / Jakarta, unless someone wants to contribute it. > Apache CXF Fediz Tomcat Plugin ver 1.6.1 does not work with Jakarta > --- > > Key: FEDIZ-257 > URL: https://issues.apache.org/jira/browse/FEDIZ-257 > Project: CXF-Fediz > Issue Type: Dependency upgrade > Components: Plugin >Affects Versions: 1.6.1 >Reporter: Mark >Priority: Major > Fix For: 1.6.1 > > > The following version of the fediz tomcat plugin was compiled with JDK 1.6 > and uses > https://cxf.apache.org/fediz-downloads.html > https://downloads.apache.org/cxf/fediz/1.6.1/ > If using version 1.6.1 with TomEE https://tomee.apache.org/download.html > I see errors encountering, java.lang.NoClassDefFoundError: > javax/xml/bind/JAXBException, that indicates the Java JAXB (Java Architecture > for XML Binding) API is not available in the runtime environment. This issue > is commonly encountered when running applications on Java versions 9 and > later, as JAXB was removed from the Java SE platform starting with Java 11. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8691) Logging Feature - Sensitive element with arrays
[
https://issues.apache.org/jira/browse/CXF-8691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-8691:
-
Fix Version/s: 3.5.9
3.6.4
(was: 3.5.8)
(was: 3.6.3)
> Logging Feature - Sensitive element with arrays
> ---
>
> Key: CXF-8691
> URL: https://issues.apache.org/jira/browse/CXF-8691
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.4.0, 3.5.1
>Reporter: Daniel
>Assignee: Andriy Redko
>Priority: Minor
> Labels: Logging
> Fix For: 3.5.9, 4.0.5, 3.6.4
>
>
> Hi,
> I am trying to use the LoggingFeature within cxf-rt and hide sensitive
> element names.
> The code I use looks like the following:
>
> {code:java}
> LoggingFeature loggingFeature = new LoggingFeature();
> loggingFeature.setLogBinary(false);
> loggingFeature.setPrettyLogging(true);
> loggingFeature.setLogMultipart(false);
> loggingFeature.addSensitiveElementNames(new
> HashSet<>(Arrays.asList("password")));
> {code}
> Payload:
> {code:java}
> private final String shortName;
> private final char[] password;
> {code}
>
> Output:
>
> {code:java}
> [services.MyWebservicePort.REQ_OUT] INFO - REQ_OUT
> Address: http://
> HttpMethod: POST
> Content-Type: application/json
> ExchangeId: 560b73ae-e7e0-4687-9674-19ee72995a08
> Headers: {Accept=text/plain, Accept-Encoding=gzip;q=1.0, identity; q=0.5,
> *;q=0, Content-Type=application/json}
> Payload:
> {"shortName":"UserName","password":["G","e","h","e","i","m","1","2","3","!"]}
> {code}
> As you can see, my password is not hidden in the output of the payload. It is
> important to mention, that the field "password" in my code is declared as a
> char-array.
> However, if I add "shortName" to the sensetiveElementNames, everything works
> as expected. The shortName is hidden (XXX), due to it beeing declared as a
> String.
> I looked at the source code an tracked the problem down to a regex.
> "password" is not found, as the value is an array (MarkSensetiveHelper.java)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8950) HttpClient in CXF closing prematurely; 4.0.4-SNAPSHOT
[
https://issues.apache.org/jira/browse/CXF-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-8950:
-
Fix Version/s: 3.6.4
(was: 3.6.3)
> HttpClient in CXF closing prematurely; 4.0.4-SNAPSHOT
> -
>
> Key: CXF-8950
> URL: https://issues.apache.org/jira/browse/CXF-8950
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.3, 4.0.4
>Reporter: Sebastian Violet
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: 4.0.5, 3.6.4
>
> Attachments: CXF-HTTPClient-LargePayload.zip
>
>
> When processing requests using the JAX RS client which used the new
> HttpClient, there is the input stream is closed prematurely.
>
> [^CXF-HTTPClient-LargePayload.zip] , you will see that we are using
> {*}Response{*}, because we are interested in getting response status as well
> as the response headers. This fails with the following error:
> {code:java}
> Exception in thread "main" java.lang.RuntimeException: java.io.IOException:
> closed
> at LargeDataTester.main(LargeDataTester.java:89)
> Caused by: java.io.IOException: closed
> at
> java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.current(ResponseSubscribers.java:448)
> at
> java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.read(ResponseSubscribers.java:508)
> at java.base/java.io.FilterInputStream.read(FilterInputStream.java:119)
> at
> org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientFilteredInputStream.read(HttpClientHTTPConduit.java:422)
> at
> java.base/java.io.SequenceInputStream.read(SequenceInputStream.java:197)
> at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:333)
> at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:376)
> at java.base/sun.nio.cs.StreamDecoder.lockedRead(StreamDecoder.java:219)
> at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:173)
> at java.base/java.io.InputStreamReader.read(InputStreamReader.java:189)
> at java.base/java.io.Reader.read(Reader.java:265)
> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1610)
> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1589)
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:1384)
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:1153)
> at org.apache.commons.io.IOUtils.toString(IOUtils.java:3105)
> at LargeDataTester.main(LargeDataTester.java:84)
> Caused by: java.io.IOException: selector manager closed
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.selectorClosedException(HttpClientImpl.java:1061)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.closeSubscribers(HttpClientImpl.java:552)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.stop(HttpClientImpl.java:543)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.shutdown(HttpClientImpl.java:1165)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:1364)
> {code}
>
> {color:#FF}*You can execute the code like so:*{color}
> {code:java}
> mvn compile exec:exec{code}
> ℹ️ {*}Note{*}: You can do a diff between what works(Letting CXF deserialize
> the object response payload automatically), and the last commit(Using
> Response).
> {code:java}
> git diff HEAD^ HEAD {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-7396: - Fix Version/s: 3.5.9 3.6.4 (was: 3.5.8) (was: 3.6.3) > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.5.9, 4.0.5, 3.6.4 > > Attachments: HTTP Request.jmx, Screenshot 2020-05-05 at 10.09.43.png, > Screenshot 2020-05-12 at 12.42.11.png, image-2018-05-29-13-58-03-109.png, > image-2018-05-29-14-00-16-442.png, image-2018-05-29-14-00-54-215.png > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8629) AsyncHTTPConduit (hc5) should support chunked request / response
[ https://issues.apache.org/jira/browse/CXF-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8629: - Fix Version/s: 3.5.9 3.6.4 (was: 3.5.8) (was: 3.6.3) > AsyncHTTPConduit (hc5) should support chunked request / response > > > Key: CXF-8629 > URL: https://issues.apache.org/jira/browse/CXF-8629 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.0, 3.4.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.5.9, 4.0.5, 3.6.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8950) HttpClient in CXF closing prematurely; 4.0.4-SNAPSHOT
[
https://issues.apache.org/jira/browse/CXF-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-8950:
-
Fix Version/s: 4.0.5
(was: 4.0.4)
> HttpClient in CXF closing prematurely; 4.0.4-SNAPSHOT
> -
>
> Key: CXF-8950
> URL: https://issues.apache.org/jira/browse/CXF-8950
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.3, 4.0.4
>Reporter: Sebastian Violet
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: 3.6.3, 4.0.5
>
> Attachments: CXF-HTTPClient-LargePayload.zip
>
>
> When processing requests using the JAX RS client which used the new
> HttpClient, there is the input stream is closed prematurely.
>
> [^CXF-HTTPClient-LargePayload.zip] , you will see that we are using
> {*}Response{*}, because we are interested in getting response status as well
> as the response headers. This fails with the following error:
> {code:java}
> Exception in thread "main" java.lang.RuntimeException: java.io.IOException:
> closed
> at LargeDataTester.main(LargeDataTester.java:89)
> Caused by: java.io.IOException: closed
> at
> java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.current(ResponseSubscribers.java:448)
> at
> java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.read(ResponseSubscribers.java:508)
> at java.base/java.io.FilterInputStream.read(FilterInputStream.java:119)
> at
> org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientFilteredInputStream.read(HttpClientHTTPConduit.java:422)
> at
> java.base/java.io.SequenceInputStream.read(SequenceInputStream.java:197)
> at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:333)
> at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:376)
> at java.base/sun.nio.cs.StreamDecoder.lockedRead(StreamDecoder.java:219)
> at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:173)
> at java.base/java.io.InputStreamReader.read(InputStreamReader.java:189)
> at java.base/java.io.Reader.read(Reader.java:265)
> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1610)
> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1589)
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:1384)
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:1153)
> at org.apache.commons.io.IOUtils.toString(IOUtils.java:3105)
> at LargeDataTester.main(LargeDataTester.java:84)
> Caused by: java.io.IOException: selector manager closed
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.selectorClosedException(HttpClientImpl.java:1061)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.closeSubscribers(HttpClientImpl.java:552)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.stop(HttpClientImpl.java:543)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.shutdown(HttpClientImpl.java:1165)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:1364)
> {code}
>
> {color:#FF}*You can execute the code like so:*{color}
> {code:java}
> mvn compile exec:exec{code}
> ℹ️ {*}Note{*}: You can do a diff between what works(Letting CXF deserialize
> the object response payload automatically), and the last commit(Using
> Response).
> {code:java}
> git diff HEAD^ HEAD {code}
--
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 ] Colm O hEigeartaigh updated CXF-8983: - Fix Version/s: 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.5 > > > 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] [Updated] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-7396: - Fix Version/s: 4.0.5 (was: 4.0.4) > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.5.8, 3.6.3, 4.0.5 > > Attachments: HTTP Request.jmx, Screenshot 2020-05-05 at 10.09.43.png, > Screenshot 2020-05-12 at 12.42.11.png, image-2018-05-29-13-58-03-109.png, > image-2018-05-29-14-00-16-442.png, image-2018-05-29-14-00-54-215.png > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-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 ] Colm O hEigeartaigh resolved CXF-8983. -- Resolution: Fixed Thanks for the PR > 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.5 > > > 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] [Updated] (CXF-8691) Logging Feature - Sensitive element with arrays
[
https://issues.apache.org/jira/browse/CXF-8691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-8691:
-
Fix Version/s: 4.0.5
(was: 4.0.4)
> Logging Feature - Sensitive element with arrays
> ---
>
> Key: CXF-8691
> URL: https://issues.apache.org/jira/browse/CXF-8691
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.4.0, 3.5.1
>Reporter: Daniel
>Assignee: Andriy Redko
>Priority: Minor
> Labels: Logging
> Fix For: 3.5.8, 3.6.3, 4.0.5
>
>
> Hi,
> I am trying to use the LoggingFeature within cxf-rt and hide sensitive
> element names.
> The code I use looks like the following:
>
> {code:java}
> LoggingFeature loggingFeature = new LoggingFeature();
> loggingFeature.setLogBinary(false);
> loggingFeature.setPrettyLogging(true);
> loggingFeature.setLogMultipart(false);
> loggingFeature.addSensitiveElementNames(new
> HashSet<>(Arrays.asList("password")));
> {code}
> Payload:
> {code:java}
> private final String shortName;
> private final char[] password;
> {code}
>
> Output:
>
> {code:java}
> [services.MyWebservicePort.REQ_OUT] INFO - REQ_OUT
> Address: http://
> HttpMethod: POST
> Content-Type: application/json
> ExchangeId: 560b73ae-e7e0-4687-9674-19ee72995a08
> Headers: {Accept=text/plain, Accept-Encoding=gzip;q=1.0, identity; q=0.5,
> *;q=0, Content-Type=application/json}
> Payload:
> {"shortName":"UserName","password":["G","e","h","e","i","m","1","2","3","!"]}
> {code}
> As you can see, my password is not hidden in the output of the payload. It is
> important to mention, that the field "password" in my code is declared as a
> char-array.
> However, if I add "shortName" to the sensetiveElementNames, everything works
> as expected. The shortName is hidden (XXX), due to it beeing declared as a
> String.
> I looked at the source code an tracked the problem down to a regex.
> "password" is not found, as the value is an array (MarkSensetiveHelper.java)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8763) Migrate to Jakarta WebSocket (from Jetty Websockets)
[ https://issues.apache.org/jira/browse/CXF-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8763: - Fix Version/s: 4.0.5 (was: 4.0.4) > Migrate to Jakarta WebSocket (from Jetty Websockets) > > > Key: CXF-8763 > URL: https://issues.apache.org/jira/browse/CXF-8763 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.5 > > > Migrate from Jetty WebSockets to Jakarta WebSockets -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8629) AsyncHTTPConduit (hc5) should support chunked request / response
[ https://issues.apache.org/jira/browse/CXF-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8629: - Fix Version/s: 4.0.5 (was: 4.0.4) > AsyncHTTPConduit (hc5) should support chunked request / response > > > Key: CXF-8629 > URL: https://issues.apache.org/jira/browse/CXF-8629 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.0, 3.4.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.5.8, 3.6.3, 4.0.5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8675) jakarta.xml.bind.ModuleUtil error after jaxb 3.0.1 upgrade
[ https://issues.apache.org/jira/browse/CXF-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8675: - Fix Version/s: 4.0.5 (was: 4.0.4) > jakarta.xml.bind.ModuleUtil error after jaxb 3.0.1 upgrade > -- > > Key: CXF-8675 > URL: https://issues.apache.org/jira/browse/CXF-8675 > Project: CXF > Issue Type: Task > Components: Core >Reporter: Jim Ma >Assignee: Jim Ma >Priority: Major > Fix For: 4.0.5 > > > SOAPRpcLitClientTypeTest throws the follow exception. > [INFO] Running org.apache.cxf.systest.type_test.soap.SOAPRpcLitClientTypeTest > jakarta.xml.ws.WebServiceException: > org.apache.cxf.service.factory.ServiceConstructionException > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:373) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255) > at > org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:130) > at jakarta.xml.ws.Endpoint.publish(Endpoint.java:224) > at > org.apache.cxf.systest.type_test.soap.SOAPRpcLitServerImpl.run(SOAPRpcLitServerImpl.java:33) > at > org.apache.cxf.testutil.common.AbstractTestServerBase.startInProcess(AbstractTestServerBase.java:44) > at > org.apache.cxf.testutil.common.ServerLauncher.launchServer(ServerLauncher.java:193) > at > org.apache.cxf.testutil.common.AbstractClientServerTestBase.launchServer(AbstractClientServerTestBase.java:91) > at > org.apache.cxf.systest.type_test.soap.SOAPRpcLitClientTypeTest.startServers(SOAPRpcLitClientTypeTest.java:45) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:364) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:237) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:158) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428) > at > org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162) > at > org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548) > Caused by: org.apache.cxf.service.factory.ServiceConstructionException > at > org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:360) > at > org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:87) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:425) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262) > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199) > at > org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103) > at > org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168) > at > org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:210) > at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:458) > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:336) > ... 28 more > Caused by: jakarta.xml.bind.JAXBException: Package javax.xml.namespace with > Jakarta
[jira] [Assigned] (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 ] Colm O hEigeartaigh reassigned CXF-8981: Assignee: Colm O hEigeartaigh > 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-8977) Add support for MTOM Serialization Policy Assertion 1.1
[
https://issues.apache.org/jira/browse/CXF-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818809#comment-17818809
]
Colm O hEigeartaigh commented on CXF-8977:
--
It's a working draft from 2007, was it ever published?
[https://www.w3.org/TR/soap12-mtom-policy/]
> Add support for MTOM Serialization Policy Assertion 1.1
> ---
>
> Key: CXF-8977
> URL: https://issues.apache.org/jira/browse/CXF-8977
> Project: CXF
> Issue Type: New Feature
> Components: WS-* Components
>Affects Versions: 4.0.3
>Reporter: Daniel Spilker
>Priority: Major
>
> When trying to consume a WSDL containing a MTOM Serialization Policy
> Assertion 1.1 (https://www.w3.org/TR/soap12-mtom-policy/) a warning is logged
> and an exception is thrown.
> {code}
> Feb. 13, 2024 7:10:47 AM
> org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl
> handleNoRegisteredBuilder
> WARNUNG: No assertion builder for type
> {http://www.w3.org/2007/08/soap12-mtom-policy}MTOM registered.
> jakarta.xml.ws.soap.SOAPFaultException: None of the policy alternatives can
> be satisfied.
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.mapException(JaxWsClientProxy.java:195)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145)
> at jdk.proxy2/jdk.proxy2.$Proxy48.listShipments(Unknown Source)
> at
> com.example.shipment.adapters.TransferServiceAdapter.listShipments(TransferServiceAdapter.java:52)
> at
> com.example.shipment.adapters.TransferServiceAdapterTest.testListShipments(TransferServiceAdapterTest.java:39)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
> Caused by: org.apache.cxf.ws.policy.PolicyException: None of the policy
> alternatives can be satisfied.
> at
> org.apache.cxf.ws.policy.EndpointPolicyImpl.chooseAlternative(EndpointPolicyImpl.java:172)
> at
> org.apache.cxf.ws.policy.EndpointPolicyImpl.finalizeConfig(EndpointPolicyImpl.java:146)
> at
> org.apache.cxf.ws.policy.EndpointPolicyImpl.initialize(EndpointPolicyImpl.java:142)
> at
> org.apache.cxf.ws.policy.PolicyEngineImpl.createEndpointPolicyInfo(PolicyEngineImpl.java:614)
> at
> org.apache.cxf.ws.policy.PolicyEngineImpl.getEndpointPolicy(PolicyEngineImpl.java:326)
> at
> org.apache.cxf.ws.policy.PolicyEngineImpl.getClientEndpointPolicy(PolicyEngineImpl.java:313)
> at
> org.apache.cxf.ws.policy.PolicyDataEngineImpl.getClientEndpointPolicy(PolicyDataEngineImpl.java:61)
> at
> org.apache.cxf.transport.http.HTTPConduit.updateClientPolicy(HTTPConduit.java:372)
> at
> org.apache.cxf.transport.http.HTTPConduit.updateClientPolicy(HTTPConduit.java:392)
> at
> org.apache.cxf.transport.http.HTTPConduit.getClient(HTTPConduit.java:938)
> at
> org.apache.cxf.transport.http.HTTPConduit.configureConduitFromEndpointInfo(HTTPConduit.java:414)
> at
> org.apache.cxf.transport.http.HTTPConduit.finalizeConfig(HTTPConduit.java:494)
> at
> org.apache.cxf.transport.http.HTTPTransportFactory.getConduit(HTTPTransportFactory.java:257)
> at
> org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:226)
> at
> org.apache.cxf.endpoint.AbstractConduitSelector.createConduit(AbstractConduitSelector.java:151)
> at
> org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:108)
> at
> org.apache.cxf.endpoint.UpfrontConduitSelector.prepare(UpfrontConduitSelector.java:63)
> at
> org.apache.cxf.endpoint.ClientImpl.prepareConduitSelector(ClientImpl.java:885)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:523)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:439)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:354)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:312)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140)
> ... 6 more
> {code}
> WSDL:
> {code}
>
> http://www.example.com/namespace;
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
> xmlns:wsoma="http://www.w3.org/2007/08/soap12-mtom-policy;
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/;
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy;
> targetNamespace="http://www.example.com/namespace;>
>
> type="example:TransferServicePortType">
>
>
>
>
>
>
>
>
>
[jira] [Resolved] (FEDIZ-256) Tomcat authenticationSessionTimeout
[
https://issues.apache.org/jira/browse/FEDIZ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved FEDIZ-256.
---
Resolution: Fixed
> Tomcat authenticationSessionTimeout
> ---
>
> Key: FEDIZ-256
> URL: https://issues.apache.org/jira/browse/FEDIZ-256
> Project: CXF-Fediz
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.6.1
>Reporter: Tomas Milian
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 1.6.2
>
>
> Hello,
> I was configuring Fediz 1.6.1 on Tomcat 9.0.74 and found the following issue.
> Tomcat 9.0.74 introduced a new FORM authenticator Valve attribute
> (authenticationSessionTimeout) that breaks Fediz authentication process.
> {color:#172b4d}Fediz uses FormAuthenticator to save the request, the change
> introduced in Tomcat 9.0.74 replaces the original session timeout with the
> authenticationSessionTimeout default value (120 seconds).{color}
> {code:java}
> if (session instanceof HttpSession && ((HttpSession)
> session).isNew()) {
> int originalMaxInactiveInterval =
> session.getMaxInactiveInterval();
> if (originalMaxInactiveInterval >
> getAuthenticationSessionTimeout()) {
>
> saved.setOriginalMaxInactiveInterval(originalMaxInactiveInterval);
>
> session.setMaxInactiveInterval(getAuthenticationSessionTimeout());
> }
> } {code}
> {color:#172b4d}Once the Fediz authentication is resumed, the original session
> maxInactiveInterval is not restored, so authenticated session always ends up
> with a 120 second maxInactiveInterval{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FEDIZ-256) Tomcat authenticationSessionTimeout
[
https://issues.apache.org/jira/browse/FEDIZ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated FEDIZ-256:
--
Fix Version/s: 1.6.2
> Tomcat authenticationSessionTimeout
> ---
>
> Key: FEDIZ-256
> URL: https://issues.apache.org/jira/browse/FEDIZ-256
> Project: CXF-Fediz
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.6.1
>Reporter: Tomas Milian
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 1.6.2
>
>
> Hello,
> I was configuring Fediz 1.6.1 on Tomcat 9.0.74 and found the following issue.
> Tomcat 9.0.74 introduced a new FORM authenticator Valve attribute
> (authenticationSessionTimeout) that breaks Fediz authentication process.
> {color:#172b4d}Fediz uses FormAuthenticator to save the request, the change
> introduced in Tomcat 9.0.74 replaces the original session timeout with the
> authenticationSessionTimeout default value (120 seconds).{color}
> {code:java}
> if (session instanceof HttpSession && ((HttpSession)
> session).isNew()) {
> int originalMaxInactiveInterval =
> session.getMaxInactiveInterval();
> if (originalMaxInactiveInterval >
> getAuthenticationSessionTimeout()) {
>
> saved.setOriginalMaxInactiveInterval(originalMaxInactiveInterval);
>
> session.setMaxInactiveInterval(getAuthenticationSessionTimeout());
> }
> } {code}
> {color:#172b4d}Once the Fediz authentication is resumed, the original session
> maxInactiveInterval is not restored, so authenticated session always ends up
> with a 120 second maxInactiveInterval{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FEDIZ-256) Tomcat authenticationSessionTimeout
[
https://issues.apache.org/jira/browse/FEDIZ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782173#comment-17782173
]
Colm O hEigeartaigh commented on FEDIZ-256:
---
We have a new fix in Tomcat - maybe this fixes the problem?
[https://github.com/apache/tomcat/commit/cd58739d64cba52dfc96a3aba6a180adea1ab020]
> Tomcat authenticationSessionTimeout
> ---
>
> Key: FEDIZ-256
> URL: https://issues.apache.org/jira/browse/FEDIZ-256
> Project: CXF-Fediz
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.6.1
>Reporter: Tomas Milian
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> Hello,
> I was configuring Fediz 1.6.1 on Tomcat 9.0.74 and found the following issue.
> Tomcat 9.0.74 introduced a new FORM authenticator Valve attribute
> (authenticationSessionTimeout) that breaks Fediz authentication process.
> {color:#172b4d}Fediz uses FormAuthenticator to save the request, the change
> introduced in Tomcat 9.0.74 replaces the original session timeout with the
> authenticationSessionTimeout default value (120 seconds).{color}
> {code:java}
> if (session instanceof HttpSession && ((HttpSession)
> session).isNew()) {
> int originalMaxInactiveInterval =
> session.getMaxInactiveInterval();
> if (originalMaxInactiveInterval >
> getAuthenticationSessionTimeout()) {
>
> saved.setOriginalMaxInactiveInterval(originalMaxInactiveInterval);
>
> session.setMaxInactiveInterval(getAuthenticationSessionTimeout());
> }
> } {code}
> {color:#172b4d}Once the Fediz authentication is resumed, the original session
> maxInactiveInterval is not restored, so authenticated session always ends up
> with a 120 second maxInactiveInterval{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8952) HttpClientHTTPConduit in CXF doesn't support TLSv1.3 along with other protocols
[
https://issues.apache.org/jira/browse/CXF-8952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782106#comment-17782106
]
Colm O hEigeartaigh commented on CXF-8952:
--
Is it supported by undertow? We don't have TLS v1.3 here either:
https://github.com/apache/cxf/blob/8b205c8086aeb1f5514472f0802c1fb7d510a50e/rt/transports/http-undertow/src/main/java/org/apache/cxf/transport/http_undertow/UndertowHTTPServerEngine.java#L302
> HttpClientHTTPConduit in CXF doesn't support TLSv1.3 along with other
> protocols
> ---
>
> Key: CXF-8952
> URL: https://issues.apache.org/jira/browse/CXF-8952
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.6.2, 4.0.3
>Reporter: Sebastian Violet
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: 3.6.3, 4.0.4
>
> Attachments: image-2023-10-30-17-30-19-307.png
>
>
> *HttpClientHTTPConduit* does't have support for TLSv1.3 out of the box.
> [Look at line #253
> here|https://github.com/apache/cxf/blob/ee4244116cb49c007bde3ee7ee6a06a4cfb26027/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpClientHTTPConduit.java#L253].
> !image-2023-10-30-17-30-19-307.png|width=821,height=227!
> This means that any endpoint which solely supports *TLSv1.3* and has turned
> off other lower protocols will fail SSL Handshake.
> One can pass in a singular {*}secureSocketProtocol{*}, but that doesn't
> support passing in a list for negotiation fallback.
> I.e. We can do the following:
> {code:java}
> ClientConfiguration config = WebClient.getConfig(service);
> final TLSClientParameters tlsClientParameters =
> ObjectUtils.firstNonNull(config.getHttpConduit().getTlsClientParameters(),
> new TLSClientParameters());
> tlsClientParameters.setSecureSocketProtocol("TLSv1.3");
> {code}
> However, this will not work with endpoints that do now support {*}TLSv1.3{*};
> it works great for endpoints that only have *TLSv1.3* though.
>
> {*}Solution{*}:
> {*}Option 1{*}({color:#FF}Ideal; *recommended*{color}): Add *TLSv1.3* to
> the list of protocols when creating the HttpClient through the builder.
> {*}Option 2{*}: Allow *setSecureSocketProtocol* to take in an *array* of
> protocols.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8949) Move CxfMessageHeadersRelayTest to camel-cxf-soap
[ https://issues.apache.org/jira/browse/CXF-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779069#comment-17779069 ] Colm O hEigeartaigh commented on CXF-8949: -- [~ppalaga] - did you mean to create this in the Camel Jira project? > Move CxfMessageHeadersRelayTest to camel-cxf-soap > - > > Key: CXF-8949 > URL: https://issues.apache.org/jira/browse/CXF-8949 > Project: CXF > Issue Type: Bug >Reporter: Peter Palaga >Priority: Major > > The named test currently lives under > [camel-cxf-spring-soap|https://github.com/apache/camel/blob/0e26ffa824b7529fb916a53c327d7daeb78205ed/components/camel-cxf/camel-cxf-spring-soap/src/test/java/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest.java#L731CxfMessageHeadersRelayTest] > but there does not seem to be anything Spring specific in the test. Moreover > it is cited on the CXF component page > https://camel.apache.org/components/4.0.x/cxf-component.html#_how_to_get_and_set_soap_headers_in_pojo_mode. > > We should attempt to move the test to > [camel-cxf-soap|https://github.com/apache/camel/tree/main/components/camel-cxf/camel-cxf-soap] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FEDIZ-256) Tomcat authenticationSessionTimeout
[
https://issues.apache.org/jira/browse/FEDIZ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned FEDIZ-256:
-
Assignee: Colm O hEigeartaigh
> Tomcat authenticationSessionTimeout
> ---
>
> Key: FEDIZ-256
> URL: https://issues.apache.org/jira/browse/FEDIZ-256
> Project: CXF-Fediz
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.6.1
>Reporter: Tomas Milian
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> Hello,
> I was configuring Fediz 1.6.1 on Tomcat 9.0.74 and found the following issue.
> Tomcat 9.0.74 introduced a new FORM authenticator Valve attribute
> (authenticationSessionTimeout) that breaks Fediz authentication process.
> {color:#172b4d}Fediz uses FormAuthenticator to save the request, the change
> introduced in Tomcat 9.0.74 replaces the original session timeout with the
> authenticationSessionTimeout default value (120 seconds).{color}
> {code:java}
> if (session instanceof HttpSession && ((HttpSession)
> session).isNew()) {
> int originalMaxInactiveInterval =
> session.getMaxInactiveInterval();
> if (originalMaxInactiveInterval >
> getAuthenticationSessionTimeout()) {
>
> saved.setOriginalMaxInactiveInterval(originalMaxInactiveInterval);
>
> session.setMaxInactiveInterval(getAuthenticationSessionTimeout());
> }
> } {code}
> {color:#172b4d}Once the Fediz authentication is resumed, the original session
> maxInactiveInterval is not restored, so authenticated session always ends up
> with a 120 second maxInactiveInterval{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CXF-8930) Example showing enabling HTTPS programmatically through code.
[ https://issues.apache.org/jira/browse/CXF-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8930: Assignee: Colm O hEigeartaigh > Example showing enabling HTTPS programmatically through code. > - > > Key: CXF-8930 > URL: https://issues.apache.org/jira/browse/CXF-8930 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.3.13 >Reporter: George McCone >Assignee: Colm O hEigeartaigh >Priority: Minor > > In our system, we dynamically standup multiple Endpoints programmatically and > do not use any of the bean xml configuration. > We have been successfully using CXF for open HTTP enpoints, but recently have > been switching over to HTTPS. > All the documentation and examples we can find in the [Apache CXF -- Jetty > Configuration|https://cxf.apache.org/docs/jetty-configuration.html] and > examples at > [wsdl_first_https|https://github.com/apache/cxf/blob/main/distribution/src/main/release/samples/wsdl_first_https/src/main/java/demo/hw_https/server/Server.java] > are all using spring configuration files. > Looking to have an example that shows HTTPS configuration without the use of > any external configuration files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8930) Example showing enabling HTTPS programmatically through code.
[ https://issues.apache.org/jira/browse/CXF-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8930. -- Resolution: Information Provided > Example showing enabling HTTPS programmatically through code. > - > > Key: CXF-8930 > URL: https://issues.apache.org/jira/browse/CXF-8930 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.3.13 >Reporter: George McCone >Assignee: Colm O hEigeartaigh >Priority: Minor > > In our system, we dynamically standup multiple Endpoints programmatically and > do not use any of the bean xml configuration. > We have been successfully using CXF for open HTTP enpoints, but recently have > been switching over to HTTPS. > All the documentation and examples we can find in the [Apache CXF -- Jetty > Configuration|https://cxf.apache.org/docs/jetty-configuration.html] and > examples at > [wsdl_first_https|https://github.com/apache/cxf/blob/main/distribution/src/main/release/samples/wsdl_first_https/src/main/java/demo/hw_https/server/Server.java] > are all using spring configuration files. > Looking to have an example that shows HTTPS configuration without the use of > any external configuration files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8930) Example showing enabling HTTPS programmatically through code.
[ https://issues.apache.org/jira/browse/CXF-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766830#comment-17766830 ] Colm O hEigeartaigh commented on CXF-8930: -- This might be what you want? [https://github.com/apache/cxf/blob/2b8a745b4087609166c3fcfa8946da1adca16d76/systests/transports/src/test/java/org/apache/cxf/systest/https/trust/TrustServerNoSpring.java#L4] > Example showing enabling HTTPS programmatically through code. > - > > Key: CXF-8930 > URL: https://issues.apache.org/jira/browse/CXF-8930 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.3.13 >Reporter: George McCone >Priority: Minor > > In our system, we dynamically standup multiple Endpoints programmatically and > do not use any of the bean xml configuration. > We have been successfully using CXF for open HTTP enpoints, but recently have > been switching over to HTTPS. > All the documentation and examples we can find in the [Apache CXF -- Jetty > Configuration|https://cxf.apache.org/docs/jetty-configuration.html] and > examples at > [wsdl_first_https|https://github.com/apache/cxf/blob/main/distribution/src/main/release/samples/wsdl_first_https/src/main/java/demo/hw_https/server/Server.java] > are all using spring configuration files. > Looking to have an example that shows HTTPS configuration without the use of > any external configuration files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8817) Add support for Micrometer Observation
[ https://issues.apache.org/jira/browse/CXF-8817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764974#comment-17764974 ] Colm O hEigeartaigh commented on CXF-8817: -- [~reta] Should the fix version be bumped? > Add support for Micrometer Observation > -- > > Key: CXF-8817 > URL: https://issues.apache.org/jira/browse/CXF-8817 > Project: CXF > Issue Type: New Feature > Components: Core >Reporter: Marcin Grzejszczak >Priority: Major > Fix For: 4.0.3 > > > I'm a co-maintainer of Spring Cloud Sleuth and Micrometer projects (together > with Tommy Ludwig and Jonatan Ivanov). > [Micrometer Observation|https://micrometer.io/docs/observation] is coming as > part of the Micrometer 1.10 release and [Micrometer > Tracing|https://micrometer.io/docs/tracing] is a new project. The idea of > Micrometer Observation is that you instrument code once but you get multiple > benefits out of it - e.g. you can get tracing, metrics, logging or whatever > you see fit). > Since this project already supports Micrometer I was curious if there's > interest in adding Micrometer Observation support so that automatically (when > on classpath) except for metrics, spans could be created and tracing context > propagation could happen too. In other words metrics and tracing of this > project could be created + if there are Micrometer Observation compatible > projects, then they will join the whole graph (e.g. whole Spring Framework 6 > is, Apache Dubbo, Resilience4j etc.). > If there's interest in adding that feature, I can provide a PR. > Documentation: > * > [https://cwiki.apache.org/confluence/display/CXF20DOC/Using+Micrometer+Observation] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8916) Replacement for StaxUtils.setInnerElementCountThreshold
[
https://issues.apache.org/jira/browse/CXF-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned CXF-8916:
Assignee: Colm O hEigeartaigh
> Replacement for StaxUtils.setInnerElementCountThreshold
> ---
>
> Key: CXF-8916
> URL: https://issues.apache.org/jira/browse/CXF-8916
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
>Affects Versions: 3.4.0
>Reporter: Rich M
>Assignee: Colm O hEigeartaigh
>Priority: Minor
>
> This is related to CXF-8273, where following method was removed from code:
> public static void setInnerElementCountThreshold(int i)
> Description also states - "Instead, set the system properties to customize
> how we restrict XML."
> If I set property just like this, would it be effective ?
> {color:#1d1c1d}System.setProperty("com.ctc.wstx.maxChildrenPerElement",
> "10");{color}
> {color:#1d1c1d}or should it be:{color}
> {color:#1d1c1d}{color:#1d1c1d}System.setProperty("org.apache.cxf.stax.maxChildElements",
> "10");{color}{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8916) Replacement for StaxUtils.setInnerElementCountThreshold
[
https://issues.apache.org/jira/browse/CXF-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-8916.
--
Resolution: Not A Problem
> Replacement for StaxUtils.setInnerElementCountThreshold
> ---
>
> Key: CXF-8916
> URL: https://issues.apache.org/jira/browse/CXF-8916
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
>Affects Versions: 3.4.0
>Reporter: Rich M
>Priority: Minor
>
> This is related to CXF-8273, where following method was removed from code:
> public static void setInnerElementCountThreshold(int i)
> Description also states - "Instead, set the system properties to customize
> how we restrict XML."
> If I set property just like this, would it be effective ?
> {color:#1d1c1d}System.setProperty("com.ctc.wstx.maxChildrenPerElement",
> "10");{color}
> {color:#1d1c1d}or should it be:{color}
> {color:#1d1c1d}{color:#1d1c1d}System.setProperty("org.apache.cxf.stax.maxChildElements",
> "10");{color}{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8916) Replacement for StaxUtils.setInnerElementCountThreshold
[
https://issues.apache.org/jira/browse/CXF-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762122#comment-17762122
]
Colm O hEigeartaigh commented on CXF-8916:
--
Please see here
[https://cxf.apache.org/docs/security.html#Security-ControllingLargeRequestPayloads]
"These settings can be set as Bus level properties, endpoint level properties,
or even per request via an interceptor."
Here's an example I think
[https://github.com/apache/cxf/blob/d1396f4ce4ffb890b2434930402a8890094d7079/systests/forked/src/test/java/org/apache/cxf/systests/forked/dispatch/DispatchClientServerWithHugeResponseTest.java#L93]
> Replacement for StaxUtils.setInnerElementCountThreshold
> ---
>
> Key: CXF-8916
> URL: https://issues.apache.org/jira/browse/CXF-8916
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
>Affects Versions: 3.4.0
>Reporter: Rich M
>Priority: Minor
>
> This is related to CXF-8273, where following method was removed from code:
> public static void setInnerElementCountThreshold(int i)
> Description also states - "Instead, set the system properties to customize
> how we restrict XML."
> If I set property just like this, would it be effective ?
> {color:#1d1c1d}System.setProperty("com.ctc.wstx.maxChildrenPerElement",
> "10");{color}
> {color:#1d1c1d}or should it be:{color}
> {color:#1d1c1d}{color:#1d1c1d}System.setProperty("org.apache.cxf.stax.maxChildElements",
> "10");{color}{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8922) @Multipart for type java.lang.Integer returning null
[
https://issues.apache.org/jira/browse/CXF-8922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761948#comment-17761948
]
Colm O hEigeartaigh commented on CXF-8922:
--
Can you create a test-case to reproduce the problem?
> @Multipart for type java.lang.Integer returning null
>
>
> Key: CXF-8922
> URL: https://issues.apache.org/jira/browse/CXF-8922
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.5
>Reporter: Lef
>Priority: Major
>
> In version 3.3.5 this code was working fine (index & total were returned as
> Integer)
> {code:java}
> @Path("/uploadFiles")
> @POST
> @Consumes({MediaType.MULTIPART_FORM_DATA})
> public void uploadFile(@Context HttpServletRequest httpServletRequest,
>@Context HttpServletResponse httpServletResponse,
>@Multipart(value = "file", required = false)
> Attachment file,
>@Multipart(value = "dzchunkindex", required = false)
> Integer index,
>@Multipart(value = "dztotalchunkcount", required =
> false) Integer total,
>@QueryParam(value = "path") String path) {code}
> after upgrading to 3.5.5 index and total are always returned null.
> Changing the type from Integer to String fixes my issue. Is this expected
> functionality?
> I've debugged this down to MultipartProvider#fromAttachment line 233 where
> MessageBodyReader is null
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8913) Avoid 3rd party maven repository for OpenSAML
[ https://issues.apache.org/jira/browse/CXF-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755823#comment-17755823 ] Colm O hEigeartaigh commented on CXF-8913: -- I'll experiment [~reta] to see if I can isolate OpenSAML to a separate module in WSS4J, it'll be a couple of weeks though before I can get around to it. > Avoid 3rd party maven repository for OpenSAML > - > > Key: CXF-8913 > URL: https://issues.apache.org/jira/browse/CXF-8913 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 4.0.2 >Reporter: Claus Ibsen >Priority: Major > > Apache CXF depends on OpenSAML from Apache WSSJ project > However this commit causes wss4j to download JARs from NOT maven central but > from > https://build.shibboleth.net/nexus/content/groups/public > https://github.com/apache/ws-wss4j/commit/e4a33efcb2b474a1da2b2c08f815b2718e111823 > Is there a way for Apache CXF to only use JARs from maven central. There is a > trust issue when JARs are NOT downloaded from central. > At Apache Camel we only download from maven central - except for camel-jira > which sadly had to download from Atlassian. We are considering deprecating > and removing this component for that reason. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8835) Upgrade to Spring 5.3.26
[
https://issues.apache.org/jira/browse/CXF-8835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-8835:
-
Fix Version/s: 3.5.6
(was: 3.5.5)
> Upgrade to Spring 5.3.26
>
>
> Key: CXF-8835
> URL: https://issues.apache.org/jira/browse/CXF-8835
> Project: CXF
> Issue Type: Improvement
>Reporter: Ashok Pai
>Priority: Major
> Fix For: 3.5.6
>
>
> Spring framework contains a security bypass vulnerability when {{**}} is used
> as a pattern in Spring Security configuration with the {{mvcRequestMatcher}}
> component. The potential for security bypass exists due to the mismatch in
> pattern matching between Spring Security and Spring MVC and this has been
> fixed in 5.3.26.
> Apache cxf 3.5.5 is present with spring version 5.3.22. Please provide
> updated Apache CXF with latest (5.3.26) spring framework jars/classes.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8837) Allow P11 RSA Keys within JwsUtils
[ https://issues.apache.org/jira/browse/CXF-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8837. -- Resolution: Fixed > Allow P11 RSA Keys within JwsUtils > -- > > Key: CXF-8837 > URL: https://issues.apache.org/jira/browse/CXF-8837 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.3.4, 4.0.0 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.6.0, 4.0.1, 3.5.6 > > > As discussed on the [mailing > list|[https://lists.apache.org/thread/95hcbjqy7z7m7qhz407y9o36gw2ql2xo],] the > current implementation within `JwsUtils` only accepts RSA keys coming from a > local keystore file. RSA keys from other resources like a HSM via PKCS11 > interface are getting rejected currently for no reason. > The code needs some refactoring to not limit the support to local keystores. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8837) Allow P11 RSA Keys within JwsUtils
[ https://issues.apache.org/jira/browse/CXF-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8837: - Fix Version/s: 3.6.0 3.5.6 > Allow P11 RSA Keys within JwsUtils > -- > > Key: CXF-8837 > URL: https://issues.apache.org/jira/browse/CXF-8837 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.3.4, 4.0.0 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.6.0, 4.0.1, 3.5.6 > > > As discussed on the [mailing > list|[https://lists.apache.org/thread/95hcbjqy7z7m7qhz407y9o36gw2ql2xo],] the > current implementation within `JwsUtils` only accepts RSA keys coming from a > local keystore file. RSA keys from other resources like a HSM via PKCS11 > interface are getting rejected currently for no reason. > The code needs some refactoring to not limit the support to local keystores. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8837) Allow P11 RSA Keys within JwsUtils
[ https://issues.apache.org/jira/browse/CXF-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8837: Assignee: Colm O hEigeartaigh (was: Jan Bernhardt) > Allow P11 RSA Keys within JwsUtils > -- > > Key: CXF-8837 > URL: https://issues.apache.org/jira/browse/CXF-8837 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.3.4, 4.0.0 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 4.0.1 > > > As discussed on the [mailing > list|[https://lists.apache.org/thread/95hcbjqy7z7m7qhz407y9o36gw2ql2xo],] the > current implementation within `JwsUtils` only accepts RSA keys coming from a > local keystore file. RSA keys from other resources like a HSM via PKCS11 > interface are getting rejected currently for no reason. > The code needs some refactoring to not limit the support to local keystores. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8835) Upgrade to Spring 5.3.26
[ https://issues.apache.org/jira/browse/CXF-8835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8835. -- Resolution: Fixed We have already updated to 5.3.27 which will be in the next release, which we are wrapping up soon https://github.com/apache/cxf/commit/39b3a4d4a996307db7a1228a2ec0ff5ca8e0e7b7 > Upgrade to Spring 5.3.26 > > > Key: CXF-8835 > URL: https://issues.apache.org/jira/browse/CXF-8835 > Project: CXF > Issue Type: Improvement >Reporter: Ashok Pai >Priority: Major > Fix For: 3.5.5 > > > There are few vulnerabilities been reported with Spring 5.3.23. Apache cxf > 3.5.5 is present with spring version 5.3.22. Please provide updated Apache > CXF with latest (5.3.26) spring framework jars/classes. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8835) Upgrade to Spring 5.3.26
[ https://issues.apache.org/jira/browse/CXF-8835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8835: - Fix Version/s: 3.5.5 > Upgrade to Spring 5.3.26 > > > Key: CXF-8835 > URL: https://issues.apache.org/jira/browse/CXF-8835 > Project: CXF > Issue Type: Improvement >Reporter: Ashok Pai >Priority: Major > Fix For: 3.5.5 > > > There are few vulnerabilities been reported with Spring 5.3.23. Apache cxf > 3.5.5 is present with spring version 5.3.22. Please provide updated Apache > CXF with latest (5.3.26) spring framework jars/classes. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8823) Integrating Apache-CXF into OSS-Fuzz
[ https://issues.apache.org/jira/browse/CXF-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697533#comment-17697533 ] Colm O hEigeartaigh commented on CXF-8823: -- [~hlin] Apache CXF uses Apache Santuario for XML Security - [https://santuario.apache.org/] I'm the PMC chair of that project, IMO it would be a very good candidate for fuzzing, as the API is quite straightforward. The WS-Security stack could also be tested in CXF, see this unit test: [https://github.com/apache/cxf/blob/main/rt/ws/security/src/test/java/org/apache/cxf/ws/security/wss4j/WSS4JInOutTest.java] > Integrating Apache-CXF into OSS-Fuzz > > > Key: CXF-8823 > URL: https://issues.apache.org/jira/browse/CXF-8823 > Project: CXF > Issue Type: Improvement >Reporter: Henry Lin >Priority: Major > > Hi all, > We have prepared the [initial > integration|https://github.com/google/oss-fuzz/pull/9853] of Apache-CXF into > [Google OSS-Fuzz|https://github.com/google/oss-fuzz] which will provide more > security for your project. > > *Why do you need Fuzzing?* > The Code Intelligence JVM fuzzer > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer] has already found > [hundreds of bugs|https://github.com/CodeIntelligenceTesting/jazzer#findings] > in open source projects including for example > [OpenJDK|https://nvd.nist.gov/vuln/detail/CVE-2022-21360], > [Protobuf|https://nvd.nist.gov/vuln/detail/CVE-2021-22569] or > [jsoup|https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c]. > Fuzzing proved to be very effective having no false positives. It provides a > crashing input which helps you to reproduce and debug any finding easily. The > integration of your project into the OSS-Fuzz platform will enable continuous > fuzzing of your project by > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer]. > > *What do you need to do?* > The integration requires the maintainer or one established project committer > to deal with the bug reports. > You need to create or provide one email address that is associated with a > google account as per > [here|https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/]. > When a bug is found, you will receive an email that will provide you with > access to ClusterFuzz, crash reports, code coverage reports and fuzzer > statistics. More than 1 person can be included. > > *How can Code Intelligence support you?* > We will continue to add more fuzz targets to improve code coverage over time. > Furthermore, we are permanently enhancing fuzzing technologies by developing > new fuzzers and bug detectors. > > Please let me know if you have any questions regarding fuzzing or the > OSS-Fuzz integration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8823) Integrating Apache-CXF into OSS-Fuzz
[ https://issues.apache.org/jira/browse/CXF-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696694#comment-17696694 ] Colm O hEigeartaigh commented on CXF-8823: -- [~hlin] Any issues found should be submitted to priv...@cxf.apache.org. > Integrating Apache-CXF into OSS-Fuzz > > > Key: CXF-8823 > URL: https://issues.apache.org/jira/browse/CXF-8823 > Project: CXF > Issue Type: Improvement >Reporter: Henry Lin >Priority: Major > > Hi all, > We have prepared the [initial > integration|https://github.com/google/oss-fuzz/pull/9853] of Apache-CXF into > [Google OSS-Fuzz|https://github.com/google/oss-fuzz] which will provide more > security for your project. > > *Why do you need Fuzzing?* > The Code Intelligence JVM fuzzer > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer] has already found > [hundreds of bugs|https://github.com/CodeIntelligenceTesting/jazzer#findings] > in open source projects including for example > [OpenJDK|https://nvd.nist.gov/vuln/detail/CVE-2022-21360], > [Protobuf|https://nvd.nist.gov/vuln/detail/CVE-2021-22569] or > [jsoup|https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c]. > Fuzzing proved to be very effective having no false positives. It provides a > crashing input which helps you to reproduce and debug any finding easily. The > integration of your project into the OSS-Fuzz platform will enable continuous > fuzzing of your project by > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer]. > > *What do you need to do?* > The integration requires the maintainer or one established project committer > to deal with the bug reports. > You need to create or provide one email address that is associated with a > google account as per > [here|https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/]. > When a bug is found, you will receive an email that will provide you with > access to ClusterFuzz, crash reports, code coverage reports and fuzzer > statistics. More than 1 person can be included. > > *How can Code Intelligence support you?* > We will continue to add more fuzz targets to improve code coverage over time. > Furthermore, we are permanently enhancing fuzzing technologies by developing > new fuzzers and bug detectors. > > Please let me know if you have any questions regarding fuzzing or the > OSS-Fuzz integration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8823) Integrating Apache-CXF into OSS-Fuzz
[ https://issues.apache.org/jira/browse/CXF-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696693#comment-17696693 ] Colm O hEigeartaigh commented on CXF-8823: -- [~reta] Any ideas here for unit tests we could point to? I'm more used to working with the system tests, which maybe aren't appropriate here. > Integrating Apache-CXF into OSS-Fuzz > > > Key: CXF-8823 > URL: https://issues.apache.org/jira/browse/CXF-8823 > Project: CXF > Issue Type: Improvement >Reporter: Henry Lin >Priority: Major > > Hi all, > We have prepared the [initial > integration|https://github.com/google/oss-fuzz/pull/9853] of Apache-CXF into > [Google OSS-Fuzz|https://github.com/google/oss-fuzz] which will provide more > security for your project. > > *Why do you need Fuzzing?* > The Code Intelligence JVM fuzzer > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer] has already found > [hundreds of bugs|https://github.com/CodeIntelligenceTesting/jazzer#findings] > in open source projects including for example > [OpenJDK|https://nvd.nist.gov/vuln/detail/CVE-2022-21360], > [Protobuf|https://nvd.nist.gov/vuln/detail/CVE-2021-22569] or > [jsoup|https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c]. > Fuzzing proved to be very effective having no false positives. It provides a > crashing input which helps you to reproduce and debug any finding easily. The > integration of your project into the OSS-Fuzz platform will enable continuous > fuzzing of your project by > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer]. > > *What do you need to do?* > The integration requires the maintainer or one established project committer > to deal with the bug reports. > You need to create or provide one email address that is associated with a > google account as per > [here|https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/]. > When a bug is found, you will receive an email that will provide you with > access to ClusterFuzz, crash reports, code coverage reports and fuzzer > statistics. More than 1 person can be included. > > *How can Code Intelligence support you?* > We will continue to add more fuzz targets to improve code coverage over time. > Furthermore, we are permanently enhancing fuzzing technologies by developing > new fuzzers and bug detectors. > > Please let me know if you have any questions regarding fuzzing or the > OSS-Fuzz integration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8823) Integrating Apache-CXF into OSS-Fuzz
[ https://issues.apache.org/jira/browse/CXF-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696181#comment-17696181 ] Colm O hEigeartaigh commented on CXF-8823: -- Thanks [~hlin] . Looking at the Pr it seems the JsonMapObjectReaderWriter and AttachmentSerializer were selected, why these two in particular? It would be cool if we could fuzz the process of parsing a complete REST and/or SOAP request as well. > Integrating Apache-CXF into OSS-Fuzz > > > Key: CXF-8823 > URL: https://issues.apache.org/jira/browse/CXF-8823 > Project: CXF > Issue Type: Improvement >Reporter: Henry Lin >Priority: Major > > Hi all, > We have prepared the [initial > integration|https://github.com/google/oss-fuzz/pull/9853] of Apache-CXF into > [Google OSS-Fuzz|https://github.com/google/oss-fuzz] which will provide more > security for your project. > > *Why do you need Fuzzing?* > The Code Intelligence JVM fuzzer > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer] has already found > [hundreds of bugs|https://github.com/CodeIntelligenceTesting/jazzer#findings] > in open source projects including for example > [OpenJDK|https://nvd.nist.gov/vuln/detail/CVE-2022-21360], > [Protobuf|https://nvd.nist.gov/vuln/detail/CVE-2021-22569] or > [jsoup|https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c]. > Fuzzing proved to be very effective having no false positives. It provides a > crashing input which helps you to reproduce and debug any finding easily. The > integration of your project into the OSS-Fuzz platform will enable continuous > fuzzing of your project by > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer]. > > *What do you need to do?* > The integration requires the maintainer or one established project committer > to deal with the bug reports. > You need to create or provide one email address that is associated with a > google account as per > [here|https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/]. > When a bug is found, you will receive an email that will provide you with > access to ClusterFuzz, crash reports, code coverage reports and fuzzer > statistics. More than 1 person can be included. > > *How can Code Intelligence support you?* > We will continue to add more fuzz targets to improve code coverage over time. > Furthermore, we are permanently enhancing fuzzing technologies by developing > new fuzzers and bug detectors. > > Please let me know if you have any questions regarding fuzzing or the > OSS-Fuzz integration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8818) wsdl2java fails in 4.0.0 due to incorrect versions in Manifest
[
https://issues.apache.org/jira/browse/CXF-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-8818.
--
Resolution: Fixed
> wsdl2java fails in 4.0.0 due to incorrect versions in Manifest
> --
>
> Key: CXF-8818
> URL: https://issues.apache.org/jira/browse/CXF-8818
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Critical
> Fix For: 4.0.1
>
>
> wsdl2java fails in 4.0.0 due to incorrect versions in Manifest
> {code:java}
> aused by: java.lang.ClassNotFoundException: jakarta.xml.ws.Service
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-8818) wsdl2java fails in 4.0.0 due to incorrect versions in Manifest
Colm O hEigeartaigh created CXF-8818:
Summary: wsdl2java fails in 4.0.0 due to incorrect versions in
Manifest
Key: CXF-8818
URL: https://issues.apache.org/jira/browse/CXF-8818
Project: CXF
Issue Type: Bug
Affects Versions: 4.0.0
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 4.0.1
wsdl2java fails in 4.0.0 due to incorrect versions in Manifest
{code:java}
aused by: java.lang.ClassNotFoundException: jakarta.xml.ws.Service
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8767) Not expected behavior with java2ws-plugin
[
https://issues.apache.org/jira/browse/CXF-8767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649601#comment-17649601
]
Colm O hEigeartaigh commented on CXF-8767:
--
[~ffang] - Can you check this please, as the description references a commit
you made?
> Not expected behavior with java2ws-plugin
> -
>
> Key: CXF-8767
> URL: https://issues.apache.org/jira/browse/CXF-8767
> Project: CXF
> Issue Type: Bug
> Components: Documentation, Tooling
>Affects Versions: 3.2.8, 3.5.3
>Reporter: Thomas Sergent
>Priority: Major
>
> Hi, after upgrading from CXF 3.0.16 to 3.5.3 I found an issue with
> {code}
> org.apache.cxf
> cxf-java2ws-plugin
> {code}
> The attach wsdl feature is now broken and/or not ok according to the
> documentation. The artifcat type is no more wlsdl but the file name of the
> output wsdl.
> This bug has been introduced by this commit :
> https://github.com/apache/cxf/commit/9597cfb0fe57b55cffd6569efd98c69108e7befe
> (https://issues.apache.org/jira/browse/CXF-7924)
> Please update the documentation to precise the real artifact type or change
> the implementation / plugin to be able to customize it ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8808) broken link at guide page
[ https://issues.apache.org/jira/browse/CXF-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8808. -- Resolution: Fixed Thanks for reporting, should be fixed now. > broken link at guide page > - > > Key: CXF-8808 > URL: https://issues.apache.org/jira/browse/CXF-8808 > Project: CXF > Issue Type: Bug > Components: Documentation >Reporter: Gernot Hueller >Assignee: Colm O hEigeartaigh >Priority: Trivial > > on > [https://cxf.apache.org/docs/application-server-specific-configuration-guide.html] > there is "rely on JBossWS integration and the Apache CXF libraries included > in the application server > ([documentation|https://docs.jboss.org/author/display/AS71/Webservices+reference+guide]): > " > link leads to > [https://docs.jboss.org/author/display/AS71/Webservices+reference+guide] > which is dead > in fact, all the links in this paragraph are dead. Would be nice if they > weren't -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8804) Fix org.apache.cxf.systest.jaxrs.failover.FailoverTest.testSequentialStrategyWithDiffBaseAddresses
[ https://issues.apache.org/jira/browse/CXF-8804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649563#comment-17649563 ] Colm O hEigeartaigh commented on CXF-8804: -- [~reta] Should this and the other open 4.0.0 tasks be moved to 4.0.1? > Fix > org.apache.cxf.systest.jaxrs.failover.FailoverTest.testSequentialStrategyWithDiffBaseAddresses > -- > > Key: CXF-8804 > URL: https://issues.apache.org/jira/browse/CXF-8804 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > h1. Regression > Build / Matrix - JAVA_VERSION = 'jdk_17_latest' / JDK specific build / Build > & Test / > org.apache.cxf.systest.jaxrs.failover.FailoverTest.testSequentialStrategyWithDiffBaseAddresses > > h3. Error Message > Illegal status value : -1 > h3. Stacktrace > java.lang.IllegalArgumentException: Illegal status value : -1 at > org.apache.cxf.jaxrs.impl.ResponseBuilderImpl.validateStatusCode(ResponseBuilderImpl.java:94) > at > org.apache.cxf.jaxrs.impl.ResponseBuilderImpl.status(ResponseBuilderImpl.java:78) > at > org.apache.cxf.jaxrs.utils.JAXRSUtils.toResponseBuilder(JAXRSUtils.java:1974) > at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:434) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:1022) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:932) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:347) > at > org.apache.cxf.common.util.CglibProxyHelper$1.intercept(CglibProxyHelper.java:67) > at > org.apache.cxf.systest.jaxrs.BookStore$$EnhancerByCGLIB$$ad035b93.echoBookElementJson() > at > org.apache.cxf.systest.jaxrs.failover.AbstractFailoverTest.strategyTest(AbstractFailoverTest.java:245) > at > org.apache.cxf.systest.jaxrs.failover.AbstractFailoverTest.testSequentialStrategyWithDiffBaseAddresses(AbstractFailoverTest.java:144) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at > org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at > org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at > org.junit.runners.ParentRunner.run(ParentRunner.java:413) at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456) > at > org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169) > at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8808) broken link at guide page
[ https://issues.apache.org/jira/browse/CXF-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8808: Assignee: Colm O hEigeartaigh > broken link at guide page > - > > Key: CXF-8808 > URL: https://issues.apache.org/jira/browse/CXF-8808 > Project: CXF > Issue Type: Bug > Components: Documentation >Reporter: Gernot Hueller >Assignee: Colm O hEigeartaigh >Priority: Trivial > > on > [https://cxf.apache.org/docs/application-server-specific-configuration-guide.html] > there is "rely on JBossWS integration and the Apache CXF libraries included > in the application server > ([documentation|https://docs.jboss.org/author/display/AS71/Webservices+reference+guide]): > " > link leads to > [https://docs.jboss.org/author/display/AS71/Webservices+reference+guide] > which is dead > in fact, all the links in this paragraph are dead. Would be nice if they > weren't -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8777. -- Resolution: Fixed > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5, 3.4.10 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8755) Update to Slf4j 2.0
[ https://issues.apache.org/jira/browse/CXF-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626507#comment-17626507 ] Colm O hEigeartaigh commented on CXF-8755: -- Makes sense, thanks [~reta] > Update to Slf4j 2.0 > --- > > Key: CXF-8755 > URL: https://issues.apache.org/jira/browse/CXF-8755 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > [https://mvnrepository.com/artifact/org.slf4j/slf4j-api/2.0.0] > https://www.slf4j.org/faq.html#changesInVersion200 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CXF-8779) Vulnerabilities from dependencies - jackson-databind & commons-text
[ https://issues.apache.org/jira/browse/CXF-8779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8779. Resolution: Not A Problem > Vulnerabilities from dependencies - jackson-databind & commons-text > --- > > Key: CXF-8779 > URL: https://issues.apache.org/jira/browse/CXF-8779 > Project: CXF > Issue Type: Bug >Reporter: Ragul >Priority: Critical > > Version 1.11.1 of avro-compiler contains the apache commons-text vulnerable > library (1.9) & > Jackson-databind (2.12.7) > > Vulnerabilities from dependencies: > [CVE-2022-42889|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42889] > [CVE-2022-42004|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42004] > [CVE-2022-42003|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42003] > > Is there any plan to upgrade dependency and address this issue? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17625047#comment-17625047 ] Colm O hEigeartaigh commented on CXF-8777: -- Likely mid-December > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5, 3.4.10 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8755) Update to Slf4j 2.0
[ https://issues.apache.org/jira/browse/CXF-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17625044#comment-17625044 ] Colm O hEigeartaigh commented on CXF-8755: -- Maybe we could update as well 3.5.x? SLF4J 1.7.x is EOL afaik. Colm. > Update to Slf4j 2.0 > --- > > Key: CXF-8755 > URL: https://issues.apache.org/jira/browse/CXF-8755 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.6.0 > > > [https://mvnrepository.com/artifact/org.slf4j/slf4j-api/2.0.0] > https://www.slf4j.org/faq.html#changesInVersion200 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8777: - Fix Version/s: 3.4.10 > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5, 3.4.10 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8778) Upgrade commons-text to address CVE-2022-42889
[ https://issues.apache.org/jira/browse/CXF-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8778. -- Resolution: Duplicate > Upgrade commons-text to address CVE-2022-42889 > -- > > Key: CXF-8778 > URL: https://issues.apache.org/jira/browse/CXF-8778 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.4, 3.4.9 >Reporter: Ragul >Priority: Critical > > Version 3.5.4 & 3.4.9 of CXF contains the apache commons-text vulnerable > library (1.9) > [CVE - CVE-2022-42889 > (mitre.org)|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42889] > Fix was available in 1.10.0 commons-text > Is there any plan to upgrade and address this issue? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8777: Assignee: Colm O hEigeartaigh > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8777. -- Resolution: Fixed We have already update commons-text, will be released in 3.5.5 > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8777: - Fix Version/s: 3.5.5 (was: 3.5.4) > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Priority: Major > Fix For: 3.5.5 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17624944#comment-17624944 ] Colm O hEigeartaigh commented on CXF-8777: -- Can you give a sample project to reproduce the issue? > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Priority: Major > Fix For: 3.5.4 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8776) Version 3.5.4 contains security vulnerable woodstox version
[ https://issues.apache.org/jira/browse/CXF-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17624541#comment-17624541 ] Colm O hEigeartaigh commented on CXF-8776: -- We normally release every 2 months, so mid-December. > Version 3.5.4 contains security vulnerable woodstox version > --- > > Key: CXF-8776 > URL: https://issues.apache.org/jira/browse/CXF-8776 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.4 >Reporter: Shalom Yaish >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5 > > > Version 3.5.4 contains the security vulnerable woodstox-core- 6.2.8 > containing this CVE: > CVE-2022-40151 - CVE-2022-40156 > [https://www.mend.io/vulnerability-database/CVE-2022-40151] > The fix existed at woodstox-core-6.4.0 > > Any chance this will be released quickly ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8776) Version 3.5.4 contains security vulnerable woodstox version
[ https://issues.apache.org/jira/browse/CXF-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8776. -- Resolution: Fixed > Version 3.5.4 contains security vulnerable woodstox version > --- > > Key: CXF-8776 > URL: https://issues.apache.org/jira/browse/CXF-8776 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.4 >Reporter: Shalom Yaish >Priority: Major > Fix For: 3.5.5 > > > Version 3.5.4 contains the security vulnerable woodstox-core- 6.2.8 > containing this CVE: > CVE-2022-40151 - CVE-2022-40156 > [https://www.mend.io/vulnerability-database/CVE-2022-40151] > The fix existed at woodstox-core-6.4.0 > > Any chance this will be released quickly ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8776) Version 3.5.4 contains security vulnerable woodstox version
[ https://issues.apache.org/jira/browse/CXF-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8776: - Fix Version/s: 3.5.5 > Version 3.5.4 contains security vulnerable woodstox version > --- > > Key: CXF-8776 > URL: https://issues.apache.org/jira/browse/CXF-8776 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.4 >Reporter: Shalom Yaish >Priority: Major > Fix For: 3.5.5 > > > Version 3.5.4 contains the security vulnerable woodstox-core- 6.2.8 > containing this CVE: > CVE-2022-40151 - CVE-2022-40156 > [https://www.mend.io/vulnerability-database/CVE-2022-40151] > The fix existed at woodstox-core-6.4.0 > > Any chance this will be released quickly ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8776) Version 3.5.4 contains security vulnerable woodstox version
[ https://issues.apache.org/jira/browse/CXF-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8776: Assignee: Colm O hEigeartaigh > Version 3.5.4 contains security vulnerable woodstox version > --- > > Key: CXF-8776 > URL: https://issues.apache.org/jira/browse/CXF-8776 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.4 >Reporter: Shalom Yaish >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5 > > > Version 3.5.4 contains the security vulnerable woodstox-core- 6.2.8 > containing this CVE: > CVE-2022-40151 - CVE-2022-40156 > [https://www.mend.io/vulnerability-database/CVE-2022-40151] > The fix existed at woodstox-core-6.4.0 > > Any chance this will be released quickly ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8776) Version 3.5.4 contains security vulnerable woodstox version
[ https://issues.apache.org/jira/browse/CXF-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17624424#comment-17624424 ] Colm O hEigeartaigh commented on CXF-8776: -- We have already updated to Woodstox 6.4.0 - [https://github.com/apache/cxf/commit/a615cc34ee974469e94c8a0086ec2ed0c84991fa] According to [https://github.com/advisories/GHSA-3f7h-mf4q-vrm4,] it only impacts DTD parsing, which we don't do in CXF. Colm. > Version 3.5.4 contains security vulnerable woodstox version > --- > > Key: CXF-8776 > URL: https://issues.apache.org/jira/browse/CXF-8776 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.4 >Reporter: Shalom Yaish >Priority: Major > > Version 3.5.4 contains the security vulnerable woodstox-core- 6.2.8 > containing this CVE: > CVE-2022-40151 - CVE-2022-40156 > [https://www.mend.io/vulnerability-database/CVE-2022-40151] > The fix existed at woodstox-core-6.4.0 > > Any chance this will be released quickly ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8773) Use https links in website navigation
[ https://issues.apache.org/jira/browse/CXF-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8773. -- Resolution: Fixed Thanks for reporting, it should be fixed now. > Use https links in website navigation > - > > Key: CXF-8773 > URL: https://issues.apache.org/jira/browse/CXF-8773 > Project: CXF > Issue Type: Wish > Components: Documentation >Reporter: Arnout Engelen >Assignee: Colm O hEigeartaigh >Priority: Minor > > Some of the links in the website navigation are still 'http' while they can > be 'https'. This can be updated at > [https://cwiki.apache.org/confluence/display/CXF/Navigation] (but I think I > don't have the necessary permissions). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CXF-8773) Use https links in website navigation
[ https://issues.apache.org/jira/browse/CXF-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8773. > Use https links in website navigation > - > > Key: CXF-8773 > URL: https://issues.apache.org/jira/browse/CXF-8773 > Project: CXF > Issue Type: Wish > Components: Documentation >Reporter: Arnout Engelen >Assignee: Colm O hEigeartaigh >Priority: Minor > > Some of the links in the website navigation are still 'http' while they can > be 'https'. This can be updated at > [https://cwiki.apache.org/confluence/display/CXF/Navigation] (but I think I > don't have the necessary permissions). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8773) Use https links in website navigation
[ https://issues.apache.org/jira/browse/CXF-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8773: Assignee: Colm O hEigeartaigh > Use https links in website navigation > - > > Key: CXF-8773 > URL: https://issues.apache.org/jira/browse/CXF-8773 > Project: CXF > Issue Type: Wish > Components: Documentation >Reporter: Arnout Engelen >Assignee: Colm O hEigeartaigh >Priority: Minor > > Some of the links in the website navigation are still 'http' while they can > be 'https'. This can be updated at > [https://cwiki.apache.org/confluence/display/CXF/Navigation] (but I think I > don't have the necessary permissions). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CXF-8770) ClassCastException with com.sun.org.apache.xerces.internal.dom.ElementNSImpl in Java 11 and cxf-bundle:2.7.18
[
https://issues.apache.org/jira/browse/CXF-8770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8770.
Resolution: Won't Fix
> ClassCastException with com.sun.org.apache.xerces.internal.dom.ElementNSImpl
> in Java 11 and cxf-bundle:2.7.18
> --
>
> Key: CXF-8770
> URL: https://issues.apache.org/jira/browse/CXF-8770
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, JAX-WS Runtime, JAXB Databinding
>Affects Versions: 3.4.2
>Reporter: Retheesh
>Priority: Blocker
>
> When upgrading Java 8 to 11, I am getting javax.xml dependency not found
> error. We are also generating java class from wsdl and xsd, using cxf-codegen
> plugin. That classes also uses these dependency. When tried adding the
> javax.xml dependency explicitly, the build was success but getting the
> following error while we are hitting the service.
> {code:java}
> unwinding now
> java.lang.ClassCastException: class
> com.sun.org.apache.xerces.internal.dom.ElementNSImpl cannot be cast to class
> javax.xml.soap.SOAPElement
> (com.sun.org.apache.xerces.internal.dom.ElementNSImpl is in module java.xml
> of loader 'bootstrap'; javax.xml.soap.SOAPElement is in unnamed module of
> loader 'app')
> at
> org.apache.cxf.binding.soap.saaj.SAAJStreamWriter.adjustOverlaidNode(SAAJStreamWriter.java:67)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.staxutils.OverlayW3CDOMStreamWriter.writeStartElement(OverlayW3CDOMStreamWriter.java:188)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:127)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:86)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:66)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:570)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:479)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> {code}
> I am using cxf-bundle 2.7.18 and cxf-codegen 3.4.2. Also I am using
> org.jvnet.jaxb2.maven2:maven-jaxb2-plugin:0.14.0.
> Java version : open-jdk 11.0.5
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8770) ClassCastException with com.sun.org.apache.xerces.internal.dom.ElementNSImpl in Java 11 and cxf-bundle:2.7.18
[
https://issues.apache.org/jira/browse/CXF-8770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611476#comment-17611476
]
Colm O hEigeartaigh commented on CXF-8770:
--
CXF 2.7.18 was released back in 2015, please try with a more recent version.
> ClassCastException with com.sun.org.apache.xerces.internal.dom.ElementNSImpl
> in Java 11 and cxf-bundle:2.7.18
> --
>
> Key: CXF-8770
> URL: https://issues.apache.org/jira/browse/CXF-8770
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, JAX-WS Runtime, JAXB Databinding
>Affects Versions: 3.4.2
>Reporter: Retheesh
>Priority: Blocker
>
> When upgrading Java 8 to 11, I am getting javax.xml dependency not found
> error. We are also generating java class from wsdl and xsd, using cxf-codegen
> plugin. That classes also uses these dependency. When tried adding the
> javax.xml dependency explicitly, the build was success but getting the
> following error while we are hitting the service.
> {code:java}
> unwinding now
> java.lang.ClassCastException: class
> com.sun.org.apache.xerces.internal.dom.ElementNSImpl cannot be cast to class
> javax.xml.soap.SOAPElement
> (com.sun.org.apache.xerces.internal.dom.ElementNSImpl is in module java.xml
> of loader 'bootstrap'; javax.xml.soap.SOAPElement is in unnamed module of
> loader 'app')
> at
> org.apache.cxf.binding.soap.saaj.SAAJStreamWriter.adjustOverlaidNode(SAAJStreamWriter.java:67)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.staxutils.OverlayW3CDOMStreamWriter.writeStartElement(OverlayW3CDOMStreamWriter.java:188)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:127)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:86)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:66)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:570)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:479)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
> ~[cxf-bundle-2.7.11.jar:2.7.11]
> {code}
> I am using cxf-bundle 2.7.18 and cxf-codegen 3.4.2. Also I am using
> org.jvnet.jaxb2.maven2:maven-jaxb2-plugin:0.14.0.
> Java version : open-jdk 11.0.5
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8754) Update to Jetty 10
[ https://issues.apache.org/jira/browse/CXF-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8754. -- Resolution: Duplicate > Update to Jetty 10 > -- > > Key: CXF-8754 > URL: https://issues.apache.org/jira/browse/CXF-8754 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8749) Existing handler file fails the compile generated java source files
[
https://issues.apache.org/jira/browse/CXF-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610987#comment-17610987
]
Colm O hEigeartaigh commented on CXF-8749:
--
[~ema] Can the Jira be closed? Are all fixes backported to 3.5.x-fixes?
> Existing handler file fails the compile generated java source files
> ---
>
> Key: CXF-8749
> URL: https://issues.apache.org/jira/browse/CXF-8749
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 3.5.3
>Reporter: Jim Ma
>Assignee: Jim Ma
>Priority: Major
> Fix For: 4.0.0, 3.5.4
>
>
> Use wsdl2java to generate code for two wsdls , and passing the same "-d" and
> "-classdir" flags to put the source files and compiled classes to one
> directory. The first wsdl file generated handler files always fails compiler
> the source files by the second wsdl.
> {code:java}
> org.apache.cxf.tools.common.ToolException:
> FAIL_TO_COPY_GENERATED_RESOURCE_FILE
> at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:104)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:295)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:156)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:402)
> at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> at
> org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:303)
> at org.jboss.ws.tools.cmd.WSConsume.importServices(WSConsume.java:298)
> at org.jboss.ws.tools.cmd.WSConsume.mainInternal(WSConsume.java:108)
> at org.jboss.ws.tools.cmd.WSConsume.main(WSConsume.java:96)
> Caused by: java.nio.file.FileAlreadyExistsException:
> /Users/jimma/classes/generated-classes/Endpoint_handler.xml
> at sun.nio.fs.UnixCopyFile.copy(UnixCopyFile.java:551)
> at
> sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:253)
> at java.nio.file.Files.copy(Files.java:1274)
> at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:99)
> ... 9 more{code}
>
> This issue is introduced by：
> {code:java}
> commit f5f08c838e1d52f17bcc8422fac38831a63e6e30
> Author: Alexey Markevich
> Date: Mon Nov 16 10:44:36 2020 +0300
> cxf-tools-common: use Files.copy
> {code}
> [https://github.com/apache/cxf/commit/f5f08c838e1d52f17bcc8422fac38831a63e6e30]
>
> It's better to add a warning message instead of throwing exception which
> fails the compiling generated files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8712) RetryStrategy tries one time too often
[
https://issues.apache.org/jira/browse/CXF-8712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-8712:
-
Fix Version/s: (was: 4.0.0)
(was: 3.6.0)
(was: 3.5.4)
(was: 3.4.9)
> RetryStrategy tries one time too often
> --
>
> Key: CXF-8712
> URL: https://issues.apache.org/jira/browse/CXF-8712
> Project: CXF
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 3.4.7
>Reporter: Konrad Windszus
>Priority: Major
>
> The maxNumberOfRetries is not correctly evaluated in the RetryStrategy. If it
> is set to 3, the amount of retries is actually 4.
> This is due to the fact that {{getNextAlternate()}} will return the same
> result for both {{stillTheSameAddress}} returning either {{false}} or
> {{true}}.
> Although the break condition in
> https://github.com/apache/cxf/blob/75fb6bb56d82f72771a9ee6ecab5d36168303f51/rt/features/clustering/src/main/java/org/apache/cxf/clustering/RetryStrategy.java#L55
> is correct, the logic in
> https://github.com/apache/cxf/blob/75fb6bb56d82f72771a9ee6ecab5d36168303f51/rt/features/clustering/src/main/java/org/apache/cxf/clustering/RetryStrategy.java#L45
> is flawed, as it will not return the next alternate in case
> {{stillTheSameAddress}} returns false.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8737) XSDs imported in wsdl has schema location starting with http even though wsdl is accessible over htts url
[ https://issues.apache.org/jira/browse/CXF-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597694#comment-17597694 ] Colm O hEigeartaigh commented on CXF-8737: -- Can you create a test-case that reproduces the problem? > XSDs imported in wsdl has schema location starting with http even though wsdl > is accessible over htts url > - > > Key: CXF-8737 > URL: https://issues.apache.org/jira/browse/CXF-8737 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Reporter: Amit Anand >Priority: Major > > XSDs imported in wsdl has schema location starting with http even though wsdl > is accessible over htts url > > Wsdl url: https: url-Mapping>//?wsdl > xsd url: http: url-Mapping>//?xsd=.xsd > xsd is imported in wsdl with a namespace and relative schemaLocation. > Deployed as Spring Boot application with CXF servlet bean registration and > jaxws endpoint -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8745) MemoryLeak when using SpringBus in a spring context which has a reusable parent context
[
https://issues.apache.org/jira/browse/CXF-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597639#comment-17597639
]
Colm O hEigeartaigh commented on CXF-8745:
--
Hi, can you consider opening a pull request for this issue?
> MemoryLeak when using SpringBus in a spring context which has a reusable
> parent context
> ---
>
> Key: CXF-8745
> URL: https://issues.apache.org/jira/browse/CXF-8745
> Project: CXF
> Issue Type: Bug
> Components: Bus
>Affects Versions: 3.5.3
>Reporter: Eric
>Priority: Minor
>
> SpringBus automatically registers itself as an ApplicationListener in the
> SpringContext and recursively also in all its parents:
>
> {code:java}
> public void setApplicationContext(ApplicationContext applicationContext) {
> ctx = (AbstractApplicationContext)applicationContext;
> @SuppressWarnings("rawtypes")
> ApplicationListener listener = new ApplicationListener() {
> public void onApplicationEvent(ApplicationEvent event) {
> SpringBus.this.onApplicationEvent(event);
> }
> };
> ctx.addApplicationListener(listener);
> ApplicationContext ac = applicationContext.getParent();
> while (ac != null) {
> if (ac instanceof AbstractApplicationContext) {
>
> ((AbstractApplicationContext)ac).addApplicationListener(listener);
> }
> ac = ac.getParent();
> }
> }{code}
> This leads to a MemoryLeak when the current SpringContext is closed but the
> ParentContext is reused for another child context, because the
> ApplicationListener references the SpringBus and the SpringBus references the
> old ApplicationContext.
>
> A very simple approach to solve this problem would be to deregister the
> listener in a destroy-block or to just use a WeakReference. The later is also
> used by spring itself when they register a listener in the parent to
> automatically close all related child contexts.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8708) org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR when requesting a WSFED security token
[ https://issues.apache.org/jira/browse/CXF-8708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17555438#comment-17555438 ] Colm O hEigeartaigh commented on CXF-8708: -- Is there a way to create a test-case to reproduce the problem? > org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR when requesting a WSFED security > token > --- > > Key: CXF-8708 > URL: https://issues.apache.org/jira/browse/CXF-8708 > Project: CXF > Issue Type: Bug > Components: STS >Affects Versions: 3.4.4 > Environment: Windows Server 2019 datacenter > > openjdk version "1.8.0_322" > OpenJDK Runtime Environment (build 1.8.0_322-b06) > OpenJDK 64-Bit Server VM (build 25.322-b06, mixed mode) > > JBoss EAP 7.3.10.GA (WildFly Core 10.1.25.Final-redhat-1) >Reporter: David Leruse >Priority: Blocker > Attachments: STSCustomClient.java > > > Migrating a project from cxf 3.0.3 (on java 7 with jboss 6.3.3 ) to cxf 3.4.4 > (on java 8 with jboss 7.3.10 ), i've now the following issue when trying to > request a security token from an identical ADFS. > > Could you please advice ? > > David L. > 2022-06-01 13:27:07,415 ERROR [org.riziv.wsfed.STSCustomClient] (default > task-5) an error has occurred in the STSCustomClient connectWithUser method: > org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a different > document than the one that created it. > at > com.sun.org.apache.xerces.internal.dom.ParentNode.internalInsertBefore(ParentNode.java:356) > at > com.sun.org.apache.xerces.internal.dom.ParentNode.insertBefore(ParentNode.java:287) > at > org.apache.wss4j.dom.util.WSSecurityUtil.prependChildElement(WSSecurityUtil.java:370) > at > org.apache.wss4j.dom.util.WSSecurityUtil.findWsseSecurityHeaderBlock(WSSecurityUtil.java:490) > at > org.apache.wss4j.dom.message.WSSecHeader.insertSecurityHeader(WSSecHeader.java:167) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessageInternal(PolicyBasedWSS4JOutInterceptor.java:145) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:110) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:97) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:356) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314) > at > org.apache.cxf.ws.security.trust.AbstractSTSClient.issue(AbstractSTSClient.java:874) > at > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:71) > at > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:65) > at > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:61) > at org.riziv.wsfed.STSCustomClient.connectWithUser(Unknown Source) > at org.riziv.wsfed.STSCustomClient.requestSecurityToken(Unknown Source) > at > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:65) > at > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:61) > at > org.apache.cxf.ws.security.trust.STSTokenRetriever.getTokenFromSTS(STSTokenRetriever.java:267) > at > org.apache.cxf.ws.security.trust.STSTokenRetriever.getToken(STSTokenRetriever.java:111) > at > org.apache.cxf.ws.security.policy.interceptors.IssuedTokenInterceptorProvider$IssuedTokenOutInterceptor.handleMessage(IssuedTokenInterceptorProvider.java:147) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:356) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140) > at com.sun.proxy.$Proxy203.searchOrganisation(Unknown Source) > at > com.eistream.sonora.grammar.extended.OpDoContactConsultationSearchOrganisation.doRequest(Unknown > Source) > at > com.eistream.sonora.grammar.extended.OpDoContactConsultationSearchOrganisation.doRequest(Unknown > Source) > at >
[jira] [Resolved] (CXF-8705) Multiple encrypted XML elements fail crypto coverage check
[
https://issues.apache.org/jira/browse/CXF-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-8705.
--
Resolution: Cannot Reproduce
Feel free to re-open if you can answer the questions in the comment.
> Multiple encrypted XML elements fail crypto coverage check
> --
>
> Key: CXF-8705
> URL: https://issues.apache.org/jira/browse/CXF-8705
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.5.2
> Environment: * Apache Maven 3.8.5
> * Java version: 11.0.12, vendor: Eclipse Foundation
> * Apache Tomcat 9.0.62
> * openSUSE Tumbleweed 20220509
>Reporter: David Lakatos
>Priority: Major
>
> Hello colleagues,
> I probably found a bug in
> {{org.apache.cxf.ws.security.wss4j.CryptoCoverageChecker}}.
> * Issue: SOAP XML message encryption coverage checking for more than 1 XML
> elements does not work. If only 1 XML element encryption coverage is checked,
> everything works fine.
> * Symptoms: [CryptoCoverageUtil.matchElement(Collection,
> CoverageScope,
> Element)|https://github.com/apache/cxf/blob/cxf-3.5.2/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/CryptoCoverageUtil.java#L381]
> compares objects via references ({{r.getProtectedElement() == el}}) but they
> are always different objects
> * Reproducer JUnit tests are provided on GitHub:
> [greatit/crypto-coverage-test|https://github.com/greatit/crypto-coverage-test]
> Fixing the issue would be much appreciated. Thank you.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (CXFXJC-41) Regression with JAXB 2.3.5 / 3.x: "http://schemas.xmlsoap.org/wsdl/" is not a part of this compilation
[
https://issues.apache.org/jira/browse/CXFXJC-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXFXJC-41.
-
> Regression with JAXB 2.3.5 / 3.x: "http://schemas.xmlsoap.org/wsdl/; is not a
> part of this compilation
> --
>
> Key: CXFXJC-41
> URL: https://issues.apache.org/jira/browse/CXFXJC-41
> Project: CXF XJC Utils
> Issue Type: Bug
>Affects Versions: 3.3.1
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.0, 3.3.2
>
>
> Interesting regression has been observed with JAXB 2.3.5 and 3.x: the CXF
> builds are failing with :
>
> {noformat}
> [ERROR] rt\wsdl\src\test\resources\schemas\wsdl\test-conf.xjb [25:88]:
> "http://schemas.xmlsoap.org/wsdl/; is not a part of this compilation. Is this
> a mistake for "file:core/src/main/resources/schemas/wsdl/wsdl.xsd"?
>
> com.sun.istack.SAXParseException2; systemId:
> file:/rt/wsdl/src/test/resources/schemas/wsdl/test-conf.xjb; lineNumber: 25;
> columnNumber: 88; "http://schemas.xmlsoap.org/wsdl/; is not a part of this
> compilation. Is this a mistake for
> "file:core/src/main/resources/schemas/wsdl/wsdl.xsd"?
> at
> com.sun.tools.xjc.reader.internalizer.Internalizer.reportError(Internalizer.java:570)
>
>
> at
> com.sun.tools.xjc.reader.internalizer.Internalizer.reportError(Internalizer.java:563)
>
>
> at
> com.sun.tools.xjc.reader.internalizer.Internalizer.buildTargetNodeMap(Internalizer.java:206)
>
>
> at
> com.sun.tools.xjc.reader.internalizer.Internalizer.buildTargetNodeMap(Internalizer.java:335)
>
>
> at
> com.sun.tools.xjc.reader.internalizer.Internalizer.transform(Internalizer.java:116)
>
>
> at
> com.sun.tools.xjc.reader.internalizer.Internalizer.transform(Internalizer.java:77)
>
>
> at
> com.sun.tools.xjc.reader.internalizer.DOMForest.transform(DOMForest.java:429)
>
>
> at com.sun.tools.xjc.ModelLoader.buildDOMForest(ModelLoader.java:286)
>
>
> at com.sun.tools.xjc.ModelLoader.loadXMLSchema(ModelLoader.java:318)
>
>
> at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:121)
>
>
> at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:76)
>
>
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>
>
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
>
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>
>
> at
> org.apache.cxf.maven_plugin.XSDToJavaRunner.loadModel(XSDToJavaRunner.java:224)
>
>
> at
> org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:174)
>
[jira] [Closed] (CXFXJC-40) Support Jakarta EE 9.0+
[ https://issues.apache.org/jira/browse/CXFXJC-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXFXJC-40. - > Support Jakarta EE 9.0+ > --- > > Key: CXFXJC-40 > URL: https://issues.apache.org/jira/browse/CXFXJC-40 > Project: CXF XJC Utils > Issue Type: New Feature >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > The `xjc-utils` use the `javax` artifacts for code generation, it would make > sense to branch off 4.0.0 to support Jakarka artifacts and align with CXF > plans to support Jakarta as well. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (CXF-8567) AdviceBean in CXF STS using SAMLTokenProvider
[
https://issues.apache.org/jira/browse/CXF-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned CXF-8567:
Assignee: Colm O hEigeartaigh
> AdviceBean in CXF STS using SAMLTokenProvider
> -
>
> Key: CXF-8567
> URL: https://issues.apache.org/jira/browse/CXF-8567
> Project: CXF
> Issue Type: New Feature
> Components: JAX-WS Runtime, STS
>Affects Versions: 3.4.4
>Reporter: subigre
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> In the context of a new project, I need to implement a STS that generates
> some SAML tokens for users already authenticated.
> As a result, the SAML assertion returns by the STS must contain reference to
> the SAML assertion sent in the request.
>
> {code:java}
> IssueInstant="2021-07-22T21:02:16.176Z" Version="2.0"
> xsi:type="saml2:AssertionType"
> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
> ...
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">fPzBicjKXtADawasyp1d1w==
> Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"/>
>
> NotOnOrAfter="2021-07-13T14:07:58.417Z"/>
>
>
> _2c84dd7b-728c-4a35-95ed-dc36aeda731e
>
>
>
>
> urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession
>
>
> ...
>
> {code}
>
> Currently, I implement my own providers using the following interfaces to
> populate/customize the rest of the SAML assertion:
> * {{AttributeStatementProvider}}
> * {{AuthDecisionStatementProvider}}
> * {{AuthenticationStatementProvider}}
> * {{ConditionsProvider}}
> However, I do not find a mechanism to populate the {{AdviceBean.}}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CXF-8705) Multiple encrypted XML elements fail crypto coverage check
[
https://issues.apache.org/jira/browse/CXF-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17543938#comment-17543938
]
Colm O hEigeartaigh commented on CXF-8705:
--
Hi,
How can I run the tests - does it require the server to be running somehow?
Are you checking that you aren't signing the encrypted values on the outbound
side?
> Multiple encrypted XML elements fail crypto coverage check
> --
>
> Key: CXF-8705
> URL: https://issues.apache.org/jira/browse/CXF-8705
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.5.2
> Environment: * Apache Maven 3.8.5
> * Java version: 11.0.12, vendor: Eclipse Foundation
> * Apache Tomcat 9.0.62
> * openSUSE Tumbleweed 20220509
>Reporter: David Lakatos
>Priority: Major
>
> Hello colleagues,
> I probably found a bug in
> {{org.apache.cxf.ws.security.wss4j.CryptoCoverageChecker}}.
> * Issue: SOAP XML message encryption coverage checking for more than 1 XML
> elements does not work. If only 1 XML element encryption coverage is checked,
> everything works fine.
> * Symptoms: [CryptoCoverageUtil.matchElement(Collection,
> CoverageScope,
> Element)|https://github.com/apache/cxf/blob/cxf-3.5.2/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/CryptoCoverageUtil.java#L381]
> compares objects via references ({{r.getProtectedElement() == el}}) but they
> are always different objects
> * Reproducer JUnit tests are provided on GitHub:
> [greatit/crypto-coverage-test|https://github.com/greatit/crypto-coverage-test]
> Fixing the issue would be much appreciated. Thank you.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CXFXJC-42) cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc dependency
[
https://issues.apache.org/jira/browse/CXFXJC-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17541318#comment-17541318
]
Colm O hEigeartaigh commented on CXFXJC-42:
---
3.3.2 is now available on Maven Central.
> cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc
> dependency
> ---
>
> Key: CXFXJC-42
> URL: https://issues.apache.org/jira/browse/CXFXJC-42
> Project: CXF XJC Utils
> Issue Type: Bug
> Components: Maven Plugin
>Affects Versions: 3.3.1
> Environment: Windows 10
> Java 17.0.3 (Bellsoft Liberica)
>Reporter: Falko Modler
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.3.2
>
>
> Latest 3.3.1 of the plugin started to fail on Windows (not on Linux!) after
> updating from Java 17.0.2 to 17.0.3:
> {noformat}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.772 s (Wall Clock)
> [INFO] Finished at: 2022-04-26T17:28:54+02:00
> [INFO]
>
> [ERROR] Failed to execute goal org.apache.cxf:cxf-xjc-plugin:3.3.1:xsdtojava
> (xjc) on project register-something:
> [ERROR] Exit code: 1
> [ERROR] Command line was:
> C:\Users\foo\.sdkman\candidates\java\17.0.3-librca\bin\java.exe
> --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
> C:\Develop\Temp\cxf-xjc-plugin11678367863192748736.jar -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-tools/0.12.0/jaxb2-basics-tools-0.12.0.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/annox/annox/1.0.2/annox-1.0.2.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/apache/commons/commons-lang3/3.2.1/commons-lang3-3.2.1.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/slf4j/jcl-over-slf4j/1.7.7/jcl-over-slf4j-1.7.7.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-annotate/1.1.0/jaxb2-basics-annotate-1.1.0.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/com/google/code/javaparser/javaparser/1.0.11/javaparser-1.0.11.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar
> -b
> file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xjc-bindings.xjb
> -extension -Xannotate -encoding UTF-8 -d
> C:\Develop\project\dev2\register.git\something\target/generated-sources/xsd/
> file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xml-data-1.0.xsd
> [ERROR]
> {noformat}
> {{mvn -X}} reveals:
> {noformat}
> [DEBUG] Exception in thread "main" com.sun.tools.xjc.BadCommandLineException:
> "file:\C:\Users\foo\.m2\repository\org\jvnet\jaxb2_commons\jaxb2-basics-tools\0.12.0\jaxb2-basics-tools-0.12.0.jar"
> ist kein gültiger Dateiname: {1}
> [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:515)
> [DEBUG] at com.sun.tools.xjc.Options.parseArguments(Options.java:827)
> [DEBUG] at
> org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:170)
> [DEBUG] at
> org.apache.cxf.maven_plugin.XSDToJavaRunner.main(XSDToJavaRunner.java:360)
> [DEBUG] Caused by: java.net.MalformedURLException: Invalid file path
> [DEBUG] at java.base/java.io.File.toURL(File.java:695)
> [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:512)
> {noformat}
> ("ist kein gültiger Dateiname:" is something like "is not a valid file name")
> This config is triggering the issue:
> {code:xml}
>
>
>
> org.jvnet.jaxb2_commons:jaxb2-basics-annotate:${jaxb2-basics-annotate.version}
>
>
> {code}
> Turns out that updating {{jaxb-xjc}} and {{jaxb-runtime}} dependencies of the
> plugin to 2.3.3 or newer fixes the issue (2.3.6 is latest 2.3.x).
> Ironically, that update was done already a year ago via
> https://github.com/apache/cxf-xjc-utils/commit/5d8724057f1298816573ab59f2100356a7d669d0#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R49
> but there hasn't been a release since then.
> PS: Latest {{cxf-codegen-plugin}} 3.5.2
[jira] [Updated] (CXFXJC-42) cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc dependency
[
https://issues.apache.org/jira/browse/CXFXJC-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXFXJC-42:
--
Fix Version/s: 3.3.2
> cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc
> dependency
> ---
>
> Key: CXFXJC-42
> URL: https://issues.apache.org/jira/browse/CXFXJC-42
> Project: CXF XJC Utils
> Issue Type: Bug
> Components: Maven Plugin
>Affects Versions: 3.3.1
> Environment: Windows 10
> Java 17.0.3 (Bellsoft Liberica)
>Reporter: Falko Modler
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.3.2
>
>
> Latest 3.3.1 of the plugin started to fail on Windows (not on Linux!) after
> updating from Java 17.0.2 to 17.0.3:
> {noformat}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.772 s (Wall Clock)
> [INFO] Finished at: 2022-04-26T17:28:54+02:00
> [INFO]
>
> [ERROR] Failed to execute goal org.apache.cxf:cxf-xjc-plugin:3.3.1:xsdtojava
> (xjc) on project register-something:
> [ERROR] Exit code: 1
> [ERROR] Command line was:
> C:\Users\foo\.sdkman\candidates\java\17.0.3-librca\bin\java.exe
> --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
> C:\Develop\Temp\cxf-xjc-plugin11678367863192748736.jar -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-tools/0.12.0/jaxb2-basics-tools-0.12.0.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/annox/annox/1.0.2/annox-1.0.2.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/apache/commons/commons-lang3/3.2.1/commons-lang3-3.2.1.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/slf4j/jcl-over-slf4j/1.7.7/jcl-over-slf4j-1.7.7.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-annotate/1.1.0/jaxb2-basics-annotate-1.1.0.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/com/google/code/javaparser/javaparser/1.0.11/javaparser-1.0.11.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar
> -b
> file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xjc-bindings.xjb
> -extension -Xannotate -encoding UTF-8 -d
> C:\Develop\project\dev2\register.git\something\target/generated-sources/xsd/
> file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xml-data-1.0.xsd
> [ERROR]
> {noformat}
> {{mvn -X}} reveals:
> {noformat}
> [DEBUG] Exception in thread "main" com.sun.tools.xjc.BadCommandLineException:
> "file:\C:\Users\foo\.m2\repository\org\jvnet\jaxb2_commons\jaxb2-basics-tools\0.12.0\jaxb2-basics-tools-0.12.0.jar"
> ist kein gültiger Dateiname: {1}
> [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:515)
> [DEBUG] at com.sun.tools.xjc.Options.parseArguments(Options.java:827)
> [DEBUG] at
> org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:170)
> [DEBUG] at
> org.apache.cxf.maven_plugin.XSDToJavaRunner.main(XSDToJavaRunner.java:360)
> [DEBUG] Caused by: java.net.MalformedURLException: Invalid file path
> [DEBUG] at java.base/java.io.File.toURL(File.java:695)
> [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:512)
> {noformat}
> ("ist kein gültiger Dateiname:" is something like "is not a valid file name")
> This config is triggering the issue:
> {code:xml}
>
>
>
> org.jvnet.jaxb2_commons:jaxb2-basics-annotate:${jaxb2-basics-annotate.version}
>
>
> {code}
> Turns out that updating {{jaxb-xjc}} and {{jaxb-runtime}} dependencies of the
> plugin to 2.3.3 or newer fixes the issue (2.3.6 is latest 2.3.x).
> Ironically, that update was done already a year ago via
> https://github.com/apache/cxf-xjc-utils/commit/5d8724057f1298816573ab59f2100356a7d669d0#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R49
> but there hasn't been a release since then.
> PS: Latest {{cxf-codegen-plugin}} 3.5.2 is using 2.3.5 of {{jaxb-runtime}}.
--
This message was
[jira] [Resolved] (CXFXJC-42) cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc dependency
[
https://issues.apache.org/jira/browse/CXFXJC-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXFXJC-42.
---
Resolution: Fixed
> cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc
> dependency
> ---
>
> Key: CXFXJC-42
> URL: https://issues.apache.org/jira/browse/CXFXJC-42
> Project: CXF XJC Utils
> Issue Type: Bug
> Components: Maven Plugin
>Affects Versions: 3.3.1
> Environment: Windows 10
> Java 17.0.3 (Bellsoft Liberica)
>Reporter: Falko Modler
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.3.2
>
>
> Latest 3.3.1 of the plugin started to fail on Windows (not on Linux!) after
> updating from Java 17.0.2 to 17.0.3:
> {noformat}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.772 s (Wall Clock)
> [INFO] Finished at: 2022-04-26T17:28:54+02:00
> [INFO]
>
> [ERROR] Failed to execute goal org.apache.cxf:cxf-xjc-plugin:3.3.1:xsdtojava
> (xjc) on project register-something:
> [ERROR] Exit code: 1
> [ERROR] Command line was:
> C:\Users\foo\.sdkman\candidates\java\17.0.3-librca\bin\java.exe
> --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
> C:\Develop\Temp\cxf-xjc-plugin11678367863192748736.jar -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-tools/0.12.0/jaxb2-basics-tools-0.12.0.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/annox/annox/1.0.2/annox-1.0.2.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/apache/commons/commons-lang3/3.2.1/commons-lang3-3.2.1.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/slf4j/jcl-over-slf4j/1.7.7/jcl-over-slf4j-1.7.7.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-annotate/1.1.0/jaxb2-basics-annotate-1.1.0.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/com/google/code/javaparser/javaparser/1.0.11/javaparser-1.0.11.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar
> -b
> file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xjc-bindings.xjb
> -extension -Xannotate -encoding UTF-8 -d
> C:\Develop\project\dev2\register.git\something\target/generated-sources/xsd/
> file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xml-data-1.0.xsd
> [ERROR]
> {noformat}
> {{mvn -X}} reveals:
> {noformat}
> [DEBUG] Exception in thread "main" com.sun.tools.xjc.BadCommandLineException:
> "file:\C:\Users\foo\.m2\repository\org\jvnet\jaxb2_commons\jaxb2-basics-tools\0.12.0\jaxb2-basics-tools-0.12.0.jar"
> ist kein gültiger Dateiname: {1}
> [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:515)
> [DEBUG] at com.sun.tools.xjc.Options.parseArguments(Options.java:827)
> [DEBUG] at
> org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:170)
> [DEBUG] at
> org.apache.cxf.maven_plugin.XSDToJavaRunner.main(XSDToJavaRunner.java:360)
> [DEBUG] Caused by: java.net.MalformedURLException: Invalid file path
> [DEBUG] at java.base/java.io.File.toURL(File.java:695)
> [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:512)
> {noformat}
> ("ist kein gültiger Dateiname:" is something like "is not a valid file name")
> This config is triggering the issue:
> {code:xml}
>
>
>
> org.jvnet.jaxb2_commons:jaxb2-basics-annotate:${jaxb2-basics-annotate.version}
>
>
> {code}
> Turns out that updating {{jaxb-xjc}} and {{jaxb-runtime}} dependencies of the
> plugin to 2.3.3 or newer fixes the issue (2.3.6 is latest 2.3.x).
> Ironically, that update was done already a year ago via
> https://github.com/apache/cxf-xjc-utils/commit/5d8724057f1298816573ab59f2100356a7d669d0#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R49
> but there hasn't been a release since then.
> PS: Latest {{cxf-codegen-plugin}} 3.5.2 is using 2.3.5 of {{jaxb-runtime}}.
--
This message was
[jira] [Assigned] (CXFXJC-42) cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc dependency
[
https://issues.apache.org/jira/browse/CXFXJC-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned CXFXJC-42:
-
Assignee: Colm O hEigeartaigh
> cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc
> dependency
> ---
>
> Key: CXFXJC-42
> URL: https://issues.apache.org/jira/browse/CXFXJC-42
> Project: CXF XJC Utils
> Issue Type: Bug
> Components: Maven Plugin
>Affects Versions: 3.3.1
> Environment: Windows 10
> Java 17.0.3 (Bellsoft Liberica)
>Reporter: Falko Modler
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> Latest 3.3.1 of the plugin started to fail on Windows (not on Linux!) after
> updating from Java 17.0.2 to 17.0.3:
> {noformat}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.772 s (Wall Clock)
> [INFO] Finished at: 2022-04-26T17:28:54+02:00
> [INFO]
>
> [ERROR] Failed to execute goal org.apache.cxf:cxf-xjc-plugin:3.3.1:xsdtojava
> (xjc) on project register-something:
> [ERROR] Exit code: 1
> [ERROR] Command line was:
> C:\Users\foo\.sdkman\candidates\java\17.0.3-librca\bin\java.exe
> --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
> C:\Develop\Temp\cxf-xjc-plugin11678367863192748736.jar -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-tools/0.12.0/jaxb2-basics-tools-0.12.0.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/annox/annox/1.0.2/annox-1.0.2.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/apache/commons/commons-lang3/3.2.1/commons-lang3-3.2.1.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/slf4j/jcl-over-slf4j/1.7.7/jcl-over-slf4j-1.7.7.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-annotate/1.1.0/jaxb2-basics-annotate-1.1.0.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/com/google/code/javaparser/javaparser/1.0.11/javaparser-1.0.11.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar
> -b
> file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xjc-bindings.xjb
> -extension -Xannotate -encoding UTF-8 -d
> C:\Develop\project\dev2\register.git\something\target/generated-sources/xsd/
> file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xml-data-1.0.xsd
> [ERROR]
> {noformat}
> {{mvn -X}} reveals:
> {noformat}
> [DEBUG] Exception in thread "main" com.sun.tools.xjc.BadCommandLineException:
> "file:\C:\Users\foo\.m2\repository\org\jvnet\jaxb2_commons\jaxb2-basics-tools\0.12.0\jaxb2-basics-tools-0.12.0.jar"
> ist kein gültiger Dateiname: {1}
> [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:515)
> [DEBUG] at com.sun.tools.xjc.Options.parseArguments(Options.java:827)
> [DEBUG] at
> org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:170)
> [DEBUG] at
> org.apache.cxf.maven_plugin.XSDToJavaRunner.main(XSDToJavaRunner.java:360)
> [DEBUG] Caused by: java.net.MalformedURLException: Invalid file path
> [DEBUG] at java.base/java.io.File.toURL(File.java:695)
> [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:512)
> {noformat}
> ("ist kein gültiger Dateiname:" is something like "is not a valid file name")
> This config is triggering the issue:
> {code:xml}
>
>
>
> org.jvnet.jaxb2_commons:jaxb2-basics-annotate:${jaxb2-basics-annotate.version}
>
>
> {code}
> Turns out that updating {{jaxb-xjc}} and {{jaxb-runtime}} dependencies of the
> plugin to 2.3.3 or newer fixes the issue (2.3.6 is latest 2.3.x).
> Ironically, that update was done already a year ago via
> https://github.com/apache/cxf-xjc-utils/commit/5d8724057f1298816573ab59f2100356a7d669d0#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R49
> but there hasn't been a release since then.
> PS: Latest {{cxf-codegen-plugin}} 3.5.2 is using 2.3.5 of {{jaxb-runtime}}.
--
This message was sent by
[jira] [Commented] (CXF-8699) Abillity to set sensitive filters on LoggingFeature
[
https://issues.apache.org/jira/browse/CXF-8699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536510#comment-17536510
]
Colm O hEigeartaigh commented on CXF-8699:
--
Hi [~jgreffe] ,
Yes please just submit a new PR for it. We can use the same JIRA.
> Abillity to set sensitive filters on LoggingFeature
> ---
>
> Key: CXF-8699
> URL: https://issues.apache.org/jira/browse/CXF-8699
> Project: CXF
> Issue Type: Improvement
> Components: logging
>Affects Versions: 3.4.7
>Reporter: Julien Greffe
>Priority: Major
> Fix For: 4.0.0, 3.6.0, 3.5.3, 3.4.8
>
>
> Hello,
> class {{LoggingFeature}} has new methods to add sensitive filters on custom
> LoggingFeature:
> {code}
> addSensitiveElementNames
> addSensitiveProtocolHeaderNames
> {code}
> Currently, we can't configure the default LoggingFeature to filter sensitive
> informations from scratch through configuration.
> More, we can't change configuration to update filters and have them reflected
> on default LoggingFeature.
> Idea is to:
> - add two methods
> {code}
> setSensitiveElementNames
> setSensitiveProtocolHeaderNames
> {code}
> - add two configuration keys:
> {code}
> sensitiveElementNames
> sensitiveProtocolHeaderNames
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CXFXJC-42) cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc dependency
[
https://issues.apache.org/jira/browse/CXFXJC-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17534167#comment-17534167
]
Colm O hEigeartaigh commented on CXFXJC-42:
---
[~reta] Yes, no problem for me.
> cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc
> dependency
> ---
>
> Key: CXFXJC-42
> URL: https://issues.apache.org/jira/browse/CXFXJC-42
> Project: CXF XJC Utils
> Issue Type: Bug
> Components: Maven Plugin
>Affects Versions: 3.3.1
> Environment: Windows 10
> Java 17.0.3 (Bellsoft Liberica)
>Reporter: Falko Modler
>Priority: Major
>
> Latest 3.3.1 of the plugin started to fail on Windows (not on Linux!) after
> updating from Java 17.0.2 to 17.0.3:
> {noformat}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.772 s (Wall Clock)
> [INFO] Finished at: 2022-04-26T17:28:54+02:00
> [INFO]
>
> [ERROR] Failed to execute goal org.apache.cxf:cxf-xjc-plugin:3.3.1:xsdtojava
> (xjc) on project register-something:
> [ERROR] Exit code: 1
> [ERROR] Command line was:
> C:\Users\foo\.sdkman\candidates\java\17.0.3-librca\bin\java.exe
> --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
> C:\Develop\Temp\cxf-xjc-plugin11678367863192748736.jar -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-tools/0.12.0/jaxb2-basics-tools-0.12.0.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/annox/annox/1.0.2/annox-1.0.2.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/apache/commons/commons-lang3/3.2.1/commons-lang3-3.2.1.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/slf4j/jcl-over-slf4j/1.7.7/jcl-over-slf4j-1.7.7.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-annotate/1.1.0/jaxb2-basics-annotate-1.1.0.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/com/google/code/javaparser/javaparser/1.0.11/javaparser-1.0.11.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.jar
> -classpath
> file:/C:/Users/foo/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar
> -b
> file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xjc-bindings.xjb
> -extension -Xannotate -encoding UTF-8 -d
> C:\Develop\project\dev2\register.git\something\target/generated-sources/xsd/
> file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xml-data-1.0.xsd
> [ERROR]
> {noformat}
> {{mvn -X}} reveals:
> {noformat}
> [DEBUG] Exception in thread "main" com.sun.tools.xjc.BadCommandLineException:
> "file:\C:\Users\foo\.m2\repository\org\jvnet\jaxb2_commons\jaxb2-basics-tools\0.12.0\jaxb2-basics-tools-0.12.0.jar"
> ist kein gültiger Dateiname: {1}
> [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:515)
> [DEBUG] at com.sun.tools.xjc.Options.parseArguments(Options.java:827)
> [DEBUG] at
> org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:170)
> [DEBUG] at
> org.apache.cxf.maven_plugin.XSDToJavaRunner.main(XSDToJavaRunner.java:360)
> [DEBUG] Caused by: java.net.MalformedURLException: Invalid file path
> [DEBUG] at java.base/java.io.File.toURL(File.java:695)
> [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:512)
> {noformat}
> ("ist kein gültiger Dateiname:" is something like "is not a valid file name")
> This config is triggering the issue:
> {code:xml}
>
>
>
> org.jvnet.jaxb2_commons:jaxb2-basics-annotate:${jaxb2-basics-annotate.version}
>
>
> {code}
> Turns out that updating {{jaxb-xjc}} and {{jaxb-runtime}} dependencies of the
> plugin to 2.3.3 or newer fixes the issue (2.3.6 is latest 2.3.x).
> Ironically, that update was done already a year ago via
> https://github.com/apache/cxf-xjc-utils/commit/5d8724057f1298816573ab59f2100356a7d669d0#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R49
> but there hasn't been a release since then.
> PS: Latest {{cxf-codegen-plugin}} 3.5.2 is using 2.3.5 of {{jaxb-runtime}}.
--
This message was sent by Atlassian Jira
[jira] [Commented] (CXF-8696) Improve build performance of modules
[
https://issues.apache.org/jira/browse/CXF-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528181#comment-17528181
]
Colm O hEigeartaigh commented on CXF-8696:
--
Hi, from what I can see the frontend jaxrs module still needs the aegis module
as a test dependency?
{code:java}
[ERROR]
/Users/coheigea/src/apache/cxf/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/resources/Tags.java:[27,39]
package org.apache.cxf.aegis.type.java5 does not exist
[ERROR]
/Users/coheigea/src/apache/cxf/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/resources/Tags.java:[45,6]
cannot find symbol
[ERROR] symbol: class XmlFlattenedArray
[ERROR] location: class org.apache.cxf.jaxrs.resources.Tags
[ERROR] -> [Help 1] {code}
> Improve build performance of modules
>
>
> Key: CXF-8696
> URL: https://issues.apache.org/jira/browse/CXF-8696
> Project: CXF
> Issue Type: Improvement
> Components: Build system
>Affects Versions: 4.0.0
>Reporter: Bing-ok
>Priority: Major
>
> Hi, I'm now using {*}cxf{*}. I found that the build time of the project is
> not very fast when I used *mvn -T 1C install -DskipTests* command to build
> the project during Github Actions. So I try to speed up the build performance
> of the project. The goal here is to clean up dependencies between maven
> modules in the project in order to improve the build performance.
> Using *mvn dependency:analyze* command I managed to have an overview of the
> unused dependencies of every module. I focused only on the dependencies
> between modules. The following dependencies can be cleaned up:
> {noformat}
> org.apache.cxf:cxf-rt-frontend-jaxrs(cxf\rt\frontend\jaxrs) ->
> org.apache.cxf:cxf-rt-databinding-aegis(cxf\rt\databinding\aegis){noformat}
> After clean up, the build time has been reduced by 3 minutes when I use
> parallel build during Github Actions.
> Could you help me review this issue? I can submit a PR to improve build
> performance of the project.
> Thank you very much for your attention.
> Best regards.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (CXF-8579) Upgrade wss4j to v3.0.0 and OpenSAML to 4.x
[
https://issues.apache.org/jira/browse/CXF-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-8579.
--
Resolution: Fixed
> Upgrade wss4j to v3.0.0 and OpenSAML to 4.x
> ---
>
> Key: CXF-8579
> URL: https://issues.apache.org/jira/browse/CXF-8579
> Project: CXF
> Issue Type: Task
> Components: STS, WS-* Components
>Affects Versions: 3.5.0
>Reporter: Misagh Moayyed
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 4.0.0
>
>
> The next release of wss4j has switched to support OpenSAML v4. This release
> as of this writing is in SNAPSHOT mode. When testing wss4j against CXF, it
> turns out that SAMLTokenProvider is not compatible with the latest wss4j and
> opensaml v4, mainly due to the following:
>
> {code:java}
> DateTime validFrom = null;
> DateTime validTill = null;
> if (assertion.getSamlVersion().equals(SAMLVersion.VERSION_20)) {
> validFrom = assertion.getSaml2().getConditions().getNotBefore();
> validTill = assertion.getSaml2().getConditions().getNotOnOrAfter();
> } else {
> validFrom = assertion.getSaml1().getConditions().getNotBefore();
> validTill = assertion.getSaml1().getConditions().getNotOnOrAfter();
> }
> {code}
> There may be other areas that require attention.
> This Jira focuses on upgrading wss4j to the next 2.5.x line, while making
> sure opensaml v4 continues to work correctly. If possible, it would be great
> to publish a SNAPSHOT version of CXF that contains an updated 2.5.0-SNAPSHOT
> version for wss4j, and allow the user community to test it.
>
> I can surely submit a patch or pull request that attempts to handle the
> upgrade on GH, etc.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CXF-8579) Upgrade wss4j to v3.0.0 and OpenSAML to 4.x
[
https://issues.apache.org/jira/browse/CXF-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-8579:
-
Summary: Upgrade wss4j to v3.0.0 and OpenSAML to 4.x (was: Upgrade wss4j
to v2.5.0 and OpenSAML to 4.x)
> Upgrade wss4j to v3.0.0 and OpenSAML to 4.x
> ---
>
> Key: CXF-8579
> URL: https://issues.apache.org/jira/browse/CXF-8579
> Project: CXF
> Issue Type: Task
> Components: STS, WS-* Components
>Affects Versions: 3.5.0
>Reporter: Misagh Moayyed
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 4.0.0
>
>
> The next release of wss4j has switched to support OpenSAML v4. This release
> as of this writing is in SNAPSHOT mode. When testing wss4j against CXF, it
> turns out that SAMLTokenProvider is not compatible with the latest wss4j and
> opensaml v4, mainly due to the following:
>
> {code:java}
> DateTime validFrom = null;
> DateTime validTill = null;
> if (assertion.getSamlVersion().equals(SAMLVersion.VERSION_20)) {
> validFrom = assertion.getSaml2().getConditions().getNotBefore();
> validTill = assertion.getSaml2().getConditions().getNotOnOrAfter();
> } else {
> validFrom = assertion.getSaml1().getConditions().getNotBefore();
> validTill = assertion.getSaml1().getConditions().getNotOnOrAfter();
> }
> {code}
> There may be other areas that require attention.
> This Jira focuses on upgrading wss4j to the next 2.5.x line, while making
> sure opensaml v4 continues to work correctly. If possible, it would be great
> to publish a SNAPSHOT version of CXF that contains an updated 2.5.0-SNAPSHOT
> version for wss4j, and allow the user community to test it.
>
> I can surely submit a patch or pull request that attempts to handle the
> upgrade on GH, etc.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CXF-8579) Upgrade wss4j to v2.5.0 and OpenSAML to 4.x
[
https://issues.apache.org/jira/browse/CXF-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-8579:
-
Fix Version/s: 4.0.0
> Upgrade wss4j to v2.5.0 and OpenSAML to 4.x
> ---
>
> Key: CXF-8579
> URL: https://issues.apache.org/jira/browse/CXF-8579
> Project: CXF
> Issue Type: Task
> Components: STS, WS-* Components
>Affects Versions: 3.5.0
>Reporter: Misagh Moayyed
>Priority: Minor
> Fix For: 4.0.0
>
>
> The next release of wss4j has switched to support OpenSAML v4. This release
> as of this writing is in SNAPSHOT mode. When testing wss4j against CXF, it
> turns out that SAMLTokenProvider is not compatible with the latest wss4j and
> opensaml v4, mainly due to the following:
>
> {code:java}
> DateTime validFrom = null;
> DateTime validTill = null;
> if (assertion.getSamlVersion().equals(SAMLVersion.VERSION_20)) {
> validFrom = assertion.getSaml2().getConditions().getNotBefore();
> validTill = assertion.getSaml2().getConditions().getNotOnOrAfter();
> } else {
> validFrom = assertion.getSaml1().getConditions().getNotBefore();
> validTill = assertion.getSaml1().getConditions().getNotOnOrAfter();
> }
> {code}
> There may be other areas that require attention.
> This Jira focuses on upgrading wss4j to the next 2.5.x line, while making
> sure opensaml v4 continues to work correctly. If possible, it would be great
> to publish a SNAPSHOT version of CXF that contains an updated 2.5.0-SNAPSHOT
> version for wss4j, and allow the user community to test it.
>
> I can surely submit a patch or pull request that attempts to handle the
> upgrade on GH, etc.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (CXF-8579) Upgrade wss4j to v2.5.0 and OpenSAML to 4.x
[
https://issues.apache.org/jira/browse/CXF-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned CXF-8579:
Assignee: Colm O hEigeartaigh
> Upgrade wss4j to v2.5.0 and OpenSAML to 4.x
> ---
>
> Key: CXF-8579
> URL: https://issues.apache.org/jira/browse/CXF-8579
> Project: CXF
> Issue Type: Task
> Components: STS, WS-* Components
>Affects Versions: 3.5.0
>Reporter: Misagh Moayyed
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 4.0.0
>
>
> The next release of wss4j has switched to support OpenSAML v4. This release
> as of this writing is in SNAPSHOT mode. When testing wss4j against CXF, it
> turns out that SAMLTokenProvider is not compatible with the latest wss4j and
> opensaml v4, mainly due to the following:
>
> {code:java}
> DateTime validFrom = null;
> DateTime validTill = null;
> if (assertion.getSamlVersion().equals(SAMLVersion.VERSION_20)) {
> validFrom = assertion.getSaml2().getConditions().getNotBefore();
> validTill = assertion.getSaml2().getConditions().getNotOnOrAfter();
> } else {
> validFrom = assertion.getSaml1().getConditions().getNotBefore();
> validTill = assertion.getSaml1().getConditions().getNotOnOrAfter();
> }
> {code}
> There may be other areas that require attention.
> This Jira focuses on upgrading wss4j to the next 2.5.x line, while making
> sure opensaml v4 continues to work correctly. If possible, it would be great
> to publish a SNAPSHOT version of CXF that contains an updated 2.5.0-SNAPSHOT
> version for wss4j, and allow the user community to test it.
>
> I can surely submit a patch or pull request that attempts to handle the
> upgrade on GH, etc.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CXF-8687) Version 3.4.6 contains vulnerable spring version
[ https://issues.apache.org/jira/browse/CXF-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520933#comment-17520933 ] Colm O hEigeartaigh commented on CXF-8687: -- [https://repo1.maven.org/maven2/org/apache/cxf/apache-cxf/3.4.7/] > Version 3.4.6 contains vulnerable spring version > > > Key: CXF-8687 > URL: https://issues.apache.org/jira/browse/CXF-8687 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.4.6 >Reporter: Mathieu Veurman >Priority: Critical > > Version 3.4.6 contains the vulnerable spring core version 5.2.19, containing > this CVE: > CVE-2022-22965: Spring Framework RCE via Data Binding on JDK 9+ > > I do see this commit where the proper version of spring is referenced: > [https://github.com/apache/cxf/commit/0f8b5a2c2a66ab62c931096aaf512390d58fef3d] > > Any chance this will be released quickly as 3.4.7? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CXF-8686) JWT role claim incorrectly parsed if not tokenized as string
[
https://issues.apache.org/jira/browse/CXF-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-8686.
--
Resolution: Fixed
> JWT role claim incorrectly parsed if not tokenized as string
>
>
> Key: CXF-8686
> URL: https://issues.apache.org/jira/browse/CXF-8686
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
>Affects Versions: 3.4.6, 3.5.1
>Reporter: Oliver Wulff
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.5.2, 4.0.0
>
> Attachments: image-2022-04-05-14-08-09-726.png
>
>
> The JwtTokenSecurityContext class expects a tokenized string for the role
> claim. If the JWT contains an array of strings to represent the roles the
> role claim is incorrectly parsed.
> The following line shows that it always first tokenize the array:
> [https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/JwtTokenSecurityContext.java#L48]
> Here is a snippet of the sample JWT:
>
> {\{{}}
> {{ "sub": "myid",}}
> {{ "jti": "f42150ef-2743-4ca0-ae06-a23b307edaca",}}
> {{ "iss": "STS INT",}}
> {{ "roles": [}}
> {{ "READ",}}
> {{ "UPDATE"}}
> {{ ],}}
> {{ "iat": 1649079679,}}
> {{ "nbf": 1649079679,}}
> {{ "exp": 1649086879,}}
> {{ "aud": [}}
> {{ "urn:mycompany:application:foo"}}
> {{ ]}}
> {{}}}
>
> I propose to improve this logic thus both roles in tokenized string as well
> as a propery array list are properly parsed.
>
> Here a snippet of the debugger. The above example ends-up with two roles
> "[READ" and " UPDATE]".
>
> !image-2022-04-05-14-08-09-726.png!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CXF-8686) JWT role claim incorrectly parsed if not tokenized as string
[
https://issues.apache.org/jira/browse/CXF-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-8686:
-
Fix Version/s: 3.5.2
(was: 3.5.3)
> JWT role claim incorrectly parsed if not tokenized as string
>
>
> Key: CXF-8686
> URL: https://issues.apache.org/jira/browse/CXF-8686
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
>Affects Versions: 3.4.6, 3.5.1
>Reporter: Oliver Wulff
>Priority: Major
> Fix For: 3.5.2, 4.0.0
>
> Attachments: image-2022-04-05-14-08-09-726.png
>
>
> The JwtTokenSecurityContext class expects a tokenized string for the role
> claim. If the JWT contains an array of strings to represent the roles the
> role claim is incorrectly parsed.
> The following line shows that it always first tokenize the array:
> [https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/JwtTokenSecurityContext.java#L48]
> Here is a snippet of the sample JWT:
>
> {\{{}}
> {{ "sub": "myid",}}
> {{ "jti": "f42150ef-2743-4ca0-ae06-a23b307edaca",}}
> {{ "iss": "STS INT",}}
> {{ "roles": [}}
> {{ "READ",}}
> {{ "UPDATE"}}
> {{ ],}}
> {{ "iat": 1649079679,}}
> {{ "nbf": 1649079679,}}
> {{ "exp": 1649086879,}}
> {{ "aud": [}}
> {{ "urn:mycompany:application:foo"}}
> {{ ]}}
> {{}}}
>
> I propose to improve this logic thus both roles in tokenized string as well
> as a propery array list are properly parsed.
>
> Here a snippet of the debugger. The above example ends-up with two roles
> "[READ" and " UPDATE]".
>
> !image-2022-04-05-14-08-09-726.png!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (CXF-8686) JWT role claim incorrectly parsed if not tokenized as string
[
https://issues.apache.org/jira/browse/CXF-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned CXF-8686:
Assignee: Colm O hEigeartaigh
> JWT role claim incorrectly parsed if not tokenized as string
>
>
> Key: CXF-8686
> URL: https://issues.apache.org/jira/browse/CXF-8686
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
>Affects Versions: 3.4.6, 3.5.1
>Reporter: Oliver Wulff
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.5.2, 4.0.0
>
> Attachments: image-2022-04-05-14-08-09-726.png
>
>
> The JwtTokenSecurityContext class expects a tokenized string for the role
> claim. If the JWT contains an array of strings to represent the roles the
> role claim is incorrectly parsed.
> The following line shows that it always first tokenize the array:
> [https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/JwtTokenSecurityContext.java#L48]
> Here is a snippet of the sample JWT:
>
> {\{{}}
> {{ "sub": "myid",}}
> {{ "jti": "f42150ef-2743-4ca0-ae06-a23b307edaca",}}
> {{ "iss": "STS INT",}}
> {{ "roles": [}}
> {{ "READ",}}
> {{ "UPDATE"}}
> {{ ],}}
> {{ "iat": 1649079679,}}
> {{ "nbf": 1649079679,}}
> {{ "exp": 1649086879,}}
> {{ "aud": [}}
> {{ "urn:mycompany:application:foo"}}
> {{ ]}}
> {{}}}
>
> I propose to improve this logic thus both roles in tokenized string as well
> as a propery array list are properly parsed.
>
> Here a snippet of the debugger. The above example ends-up with two roles
> "[READ" and " UPDATE]".
>
> !image-2022-04-05-14-08-09-726.png!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CXF-8687) Version 3.4.6 contains vulnerable spring version
[ https://issues.apache.org/jira/browse/CXF-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518241#comment-17518241 ] Colm O hEigeartaigh commented on CXF-8687: -- [~ggregory] Mailing list thread - [https://lists.apache.org/thread/cs6l6f47sgxp73twb33wlvzrk1sqbx32] > Version 3.4.6 contains vulnerable spring version > > > Key: CXF-8687 > URL: https://issues.apache.org/jira/browse/CXF-8687 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.4.6 >Reporter: Mathieu Veurman >Priority: Critical > > Version 3.4.6 contains the vulnerable spring core version 5.2.19, containing > this CVE: > CVE-2022-22965: Spring Framework RCE via Data Binding on JDK 9+ > > I do see this commit where the proper version of spring is referenced: > [https://github.com/apache/cxf/commit/0f8b5a2c2a66ab62c931096aaf512390d58fef3d] > > Any chance this will be released quickly as 3.4.7? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CXF-8686) JWT role claim incorrectly parsed if not tokenized as string
[
https://issues.apache.org/jira/browse/CXF-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-8686:
-
Fix Version/s: 3.5.3
(was: 3.5.2)
> JWT role claim incorrectly parsed if not tokenized as string
>
>
> Key: CXF-8686
> URL: https://issues.apache.org/jira/browse/CXF-8686
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
>Affects Versions: 3.4.6, 3.5.1
>Reporter: Oliver Wulff
>Priority: Major
> Fix For: 4.0.0, 3.5.3
>
> Attachments: image-2022-04-05-14-08-09-726.png
>
>
> The JwtTokenSecurityContext class expects a tokenized string for the role
> claim. If the JWT contains an array of strings to represent the roles the
> role claim is incorrectly parsed.
> The following line shows that it always first tokenize the array:
> [https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/JwtTokenSecurityContext.java#L48]
> Here is a snippet of the sample JWT:
>
> {\{{}}
> {{ "sub": "myid",}}
> {{ "jti": "f42150ef-2743-4ca0-ae06-a23b307edaca",}}
> {{ "iss": "STS INT",}}
> {{ "roles": [}}
> {{ "READ",}}
> {{ "UPDATE"}}
> {{ ],}}
> {{ "iat": 1649079679,}}
> {{ "nbf": 1649079679,}}
> {{ "exp": 1649086879,}}
> {{ "aud": [}}
> {{ "urn:mycompany:application:foo"}}
> {{ ]}}
> {{}}}
>
> I propose to improve this logic thus both roles in tokenized string as well
> as a propery array list are properly parsed.
>
> Here a snippet of the debugger. The above example ends-up with two roles
> "[READ" and " UPDATE]".
>
> !image-2022-04-05-14-08-09-726.png!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
