[jira] [Commented] (CXF-8193) upgrade to jetty 9.4.25.v20191220
[
https://issues.apache.org/jira/browse/CXF-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016638#comment-17016638
]
Alexey Markevich commented on CXF-8193:
---
Missing test resource added
> upgrade to jetty 9.4.25.v20191220
> -
>
> Key: CXF-8193
> URL: https://issues.apache.org/jira/browse/CXF-8193
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.4.0, 3.3.6
>
> Attachments: testGetBookHTMLInclude.log
>
>
> 9.4.25 will break JAXRSRequestDispatcherTest.testGetBookHTMLInclude, this is
> caused by the recent change in org.eclipse.jetty.server.Dispatcher.forward
> method.
> However, I took a close look at the
> JAXRSRequestDispatcherTest.testGetBookHTMLInclude, the server bean has
> configuration like
> {code}
>
> {code}
> So I think the test servlet configuration should also have parameter like
> {code}
>
> redirect-with-include
> true
>
> {code}
> accordingly, and this can fix the failure test.
> Seems the change in Jetty just expose a test configuration issue in CXF
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CXF-8187) Codegen-Plugin failed when maven is executed on jdk9+ with Toolchains specifying jdk 8
[
https://issues.apache.org/jira/browse/CXF-8187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016630#comment-17016630
]
JANTON commented on CXF-8187:
-
[~coheigea] Work like a charm. Good job. Thanks a lot !
> Codegen-Plugin failed when maven is executed on jdk9+ with Toolchains
> specifying jdk 8
> --
>
> Key: CXF-8187
> URL: https://issues.apache.org/jira/browse/CXF-8187
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 3.3.4
>Reporter: JANTON
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.3.5
>
>
> Codegen-Plugin failed when :
> # maven is executed on jdk9+ (ex : JAVA_HOME on a JDK 11)
> # JDK 8 is asked through toolchain plugin
> Sample of execution result :
> {code}
> [INFO] --- cxf-codegen-plugin:3.3.4:wsdl2java (x) @ x ---
> [INFO] Running code generation in fork mode...
> [INFO] Using toolchain JDK[c:/jdk1.8] to find the java executable
> [INFO] The java executable is c:\jdk1.8\bin\java.exe
> [INFO] Building jar:
> C:\tmp\cxf-tmp-13126677158727590310\cxf-codegen13282347933764786924.jar
> [WARNING] Error: Could not create the Java Virtual Machine.
> [WARNING] Error: A fatal exception has occurred. Program will exit.
> [WARNING] Unrecognized option:
> --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED
> []
> [ERROR] Failed to execute goal
> org.apache.cxf:cxf-codegen-plugin:3.3.4:wsdl2java (x) on project x:
> [ERROR] Exit code: 1
> [ERROR] Command line was: cmd.exe /X /C "c:\jdk1.8\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:\tmp\cxf-tmp-13126677158727590310\cxf-codegen13282347933764786924.jar
> C:\tmp\cxf-tmp-13126677158727590310\cxf-w2j10127470885320069515args"
> {code}
> The error seems to come from the additionalJvmArgs for java 9
> (--add-exports=..., --add-opens=...) : the command line manually executed
> failled with these args but succeed whithout). It seems that
> [AbstractCodegenMojo#execute()|https://github.com/apache/cxf/blob/cxf-3.3.4/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/AbstractCodegenMoho.java]
> doesn't test the right JDK to detect if the java 9 additionalJvmArgs should
> be add : the test is currently on the JDK used by maven instead of the one
> that will be run by Codegen-Plugin.
> Regards
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CXF-8193) upgrade to jetty 9.4.25.v20191220
[
https://issues.apache.org/jira/browse/CXF-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016591#comment-17016591
]
Alexey Markevich commented on CXF-8193:
---
The test is still failing [^testGetBookHTMLInclude.log]
> upgrade to jetty 9.4.25.v20191220
> -
>
> Key: CXF-8193
> URL: https://issues.apache.org/jira/browse/CXF-8193
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.4.0, 3.3.6
>
> Attachments: testGetBookHTMLInclude.log
>
>
> 9.4.25 will break JAXRSRequestDispatcherTest.testGetBookHTMLInclude, this is
> caused by the recent change in org.eclipse.jetty.server.Dispatcher.forward
> method.
> However, I took a close look at the
> JAXRSRequestDispatcherTest.testGetBookHTMLInclude, the server bean has
> configuration like
> {code}
>
> {code}
> So I think the test servlet configuration should also have parameter like
> {code}
>
> redirect-with-include
> true
>
> {code}
> accordingly, and this can fix the failure test.
> Seems the change in Jetty just expose a test configuration issue in CXF
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CXF-8193) upgrade to jetty 9.4.25.v20191220
[
https://issues.apache.org/jira/browse/CXF-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Markevich updated CXF-8193:
--
Attachment: testGetBookHTMLInclude.log
> upgrade to jetty 9.4.25.v20191220
> -
>
> Key: CXF-8193
> URL: https://issues.apache.org/jira/browse/CXF-8193
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.4.0, 3.3.6
>
> Attachments: testGetBookHTMLInclude.log
>
>
> 9.4.25 will break JAXRSRequestDispatcherTest.testGetBookHTMLInclude, this is
> caused by the recent change in org.eclipse.jetty.server.Dispatcher.forward
> method.
> However, I took a close look at the
> JAXRSRequestDispatcherTest.testGetBookHTMLInclude, the server bean has
> configuration like
> {code}
>
> {code}
> So I think the test servlet configuration should also have parameter like
> {code}
>
> redirect-with-include
> true
>
> {code}
> accordingly, and this can fix the failure test.
> Seems the change in Jetty just expose a test configuration issue in CXF
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CXF-8190) UriBuilder / HttpUtils replaces 127.0.0.1 by localhost
[
https://issues.apache.org/jira/browse/CXF-8190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016337#comment-17016337
]
Andriy Redko commented on CXF-8190:
---
Hey [~coheigea], we finally have a Jenkins TCK build job: [1] (I will drop a
message tonight on the list)! Here is the latest report [2]against
3.4.0-SNAPSHOT. To compare, we could do the change and merge into the master
(and rerun the TCK tests ones the 3.4.0-SNAPSHOT are available). In general, we
could run it against the PR builds but it needs a bit more work.
[1] [https://builds.apache.org/view/C/view/Apache%20CXF/job/CXF-JAXRS-TCK/]
[2]
[https://builds.apache.org/view/C/view/Apache%20CXF/job/CXF-JAXRS-TCK/65/artifact/JTreport/html/report.html]
Best Regards,
Andriy Redko
> UriBuilder / HttpUtils replaces 127.0.0.1 by localhost
> --
>
> Key: CXF-8190
> URL: https://issues.apache.org/jira/browse/CXF-8190
> Project: CXF
> Issue Type: Bug
>Reporter: Markus Rathgeb
>Priority: Major
>
> If you access a locally running REST endpoint in the brower using the IP
> address 127.0.0.1 and the REST endpoint implementation is using the UriInfo
> to build a new URL by the URI builder (e.g. a created resource), the reply
> will not use the host as accessed (127.0.0.1) but replaces the host by
> "localhost".
> If the web application then tries to access the location, the browsers will
> block that request because of a cross origin access.
>
> Assume a very simple REST endpoint:
> {code:java}
> @Component(service = { Resource.class }, scope = ServiceScope.PROTOTYPE)
> @JaxrsResource
> public class Resource {
> @POST
> @Path("create")
> @Produces(MediaType.APPLICATION_JSON)
> public Object createTest(@Context final UriInfo uriInfo) {
> final URI uri =
> uriInfo.getBaseUriBuilder().path("foo").path("bar").build();
> return Response.created(uri).build();
> }
> }{code}
> If I call the post method of that endpoint using the URL
> "[http://localhost:8080/create]; I get a created location that looks like
> "[http://localhost:8080/foo/bar];.
> All fine.
> {noformat}
> $ curl -v -X POST http://localhost:8080/create
> * Trying ::1:8080...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 8080 (#0)
> > POST /create HTTP/1.1
> > Host: localhost:8080
> > User-Agent: curl/7.67.0
> > Accept: */*
> >
> * Mark bundle as not supporting multiuse
> < HTTP/1.1 201 Created
> < Date: Tue, 10 Dec 2019 17:41:47 GMT
> < Location: http://localhost:8080/foo/bar
> < Content-Length: 0
> <
> * Connection #0 to host localhost left intact{noformat}
> But, I would expect if I access the endpoint using the IP instead of the
> hostname "[http://127.0.0.1:8080/create]; the created response's location
> should look like "[http://127.0.0.1:8080/foo/bar];.
> But that is not the case...
> The response provides "[http://localhost:8080/foo/bar];
> {noformat}
> curl -v -X POST http://127.0.0.1:8080/create
> * Trying 127.0.0.1:8080...
> * TCP_NODELAY set
> * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> > POST /create HTTP/1.1
> > Host: 127.0.0.1:8080
> > User-Agent: curl/7.67.0
> > Accept: */*
> >
> * Mark bundle as not supporting multiuse
> < HTTP/1.1 201 Created
> < Date: Tue, 10 Dec 2019 17:44:00 GMT
> < Location: http://localhost:8080/foo/bar
> < Content-Length: 0
> <
> * Connection #0 to host 127.0.0.1 left intact{noformat}
> If the website that is accessed using 127.0.0.1 provides a location using
> localhost and that one is used by the browser, the browser fails because of
> CORS.
>
> I already looked at the sources who is causing the change from 127.0.0.1 to
> localhost and found it:
> After the line
> [https://github.com/apache/cxf/blob/cxf-3.2.5/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/UriInfoImpl.java#L83]
> has been executed the variable u looks like [http://127.0.0.1:8080/]
> After that "toAbsoluteUri" of HttpUtils is called.
> That's the part of the code that replaces 127.0.0.1 by localhost
> [https://github.com/apache/cxf/blob/cxf-3.2.5/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java#L388-L391]
> The commit that added that part of code is
> [https://github.com/apache/cxf/commit/ebc910780b2b9b971a7c1c2e4019bdf9ec35e460#diff-1e4a62a6414e4007d2f5be9f0313c8c0R311-R314]
> The git commit referenced the wrong Jira (2007) - it should have been
> https://issues.apache.org/jira/browse/CXF-5007
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CXF-8190) UriBuilder / HttpUtils replaces 127.0.0.1 by localhost
[
https://issues.apache.org/jira/browse/CXF-8190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016337#comment-17016337
]
Andriy Redko edited comment on CXF-8190 at 1/15/20 9:24 PM:
Hey [~coheigea], we finally have a Jenkins TCK build job: [1] (I will drop a
message tonight on the list)! Here is the latest report [2]against
3.4.0-SNAPSHOT. To compare, we could do the change and merge into the master
(and rerun the TCK tests ones the 3.4.0-SNAPSHOT are available). In general, we
could run it against the PR builds but it needs a bit more work.
[1] [https://builds.apache.org/view/C/view/Apache%20CXF/job/CXF-JAXRS-TCK/]
[2]
[https://builds.apache.org/view/C/view/Apache%20CXF/job/CXF-JAXRS-TCK/65/artifact/JTreport/html/report.html]
Best Regards,
Andriy Redko
was (Author: reta):
Hey [~coheigea], we finally have a Jenkins TCK build job: [1] (I will drop a
message tonight on the list)! Here is the latest report [2]against
3.4.0-SNAPSHOT. To compare, we could do the change and merge into the master
(and rerun the TCK tests ones the 3.4.0-SNAPSHOT are available). In general, we
could run it against the PR builds but it needs a bit more work.
[1] [https://builds.apache.org/view/C/view/Apache%20CXF/job/CXF-JAXRS-TCK/]
[2]
[https://builds.apache.org/view/C/view/Apache%20CXF/job/CXF-JAXRS-TCK/65/artifact/JTreport/html/report.html]
Best Regards,
Andriy Redko
> UriBuilder / HttpUtils replaces 127.0.0.1 by localhost
> --
>
> Key: CXF-8190
> URL: https://issues.apache.org/jira/browse/CXF-8190
> Project: CXF
> Issue Type: Bug
>Reporter: Markus Rathgeb
>Priority: Major
>
> If you access a locally running REST endpoint in the brower using the IP
> address 127.0.0.1 and the REST endpoint implementation is using the UriInfo
> to build a new URL by the URI builder (e.g. a created resource), the reply
> will not use the host as accessed (127.0.0.1) but replaces the host by
> "localhost".
> If the web application then tries to access the location, the browsers will
> block that request because of a cross origin access.
>
> Assume a very simple REST endpoint:
> {code:java}
> @Component(service = { Resource.class }, scope = ServiceScope.PROTOTYPE)
> @JaxrsResource
> public class Resource {
> @POST
> @Path("create")
> @Produces(MediaType.APPLICATION_JSON)
> public Object createTest(@Context final UriInfo uriInfo) {
> final URI uri =
> uriInfo.getBaseUriBuilder().path("foo").path("bar").build();
> return Response.created(uri).build();
> }
> }{code}
> If I call the post method of that endpoint using the URL
> "[http://localhost:8080/create]; I get a created location that looks like
> "[http://localhost:8080/foo/bar];.
> All fine.
> {noformat}
> $ curl -v -X POST http://localhost:8080/create
> * Trying ::1:8080...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 8080 (#0)
> > POST /create HTTP/1.1
> > Host: localhost:8080
> > User-Agent: curl/7.67.0
> > Accept: */*
> >
> * Mark bundle as not supporting multiuse
> < HTTP/1.1 201 Created
> < Date: Tue, 10 Dec 2019 17:41:47 GMT
> < Location: http://localhost:8080/foo/bar
> < Content-Length: 0
> <
> * Connection #0 to host localhost left intact{noformat}
> But, I would expect if I access the endpoint using the IP instead of the
> hostname "[http://127.0.0.1:8080/create]; the created response's location
> should look like "[http://127.0.0.1:8080/foo/bar];.
> But that is not the case...
> The response provides "[http://localhost:8080/foo/bar];
> {noformat}
> curl -v -X POST http://127.0.0.1:8080/create
> * Trying 127.0.0.1:8080...
> * TCP_NODELAY set
> * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> > POST /create HTTP/1.1
> > Host: 127.0.0.1:8080
> > User-Agent: curl/7.67.0
> > Accept: */*
> >
> * Mark bundle as not supporting multiuse
> < HTTP/1.1 201 Created
> < Date: Tue, 10 Dec 2019 17:44:00 GMT
> < Location: http://localhost:8080/foo/bar
> < Content-Length: 0
> <
> * Connection #0 to host 127.0.0.1 left intact{noformat}
> If the website that is accessed using 127.0.0.1 provides a location using
> localhost and that one is used by the browser, the browser fails because of
> CORS.
>
> I already looked at the sources who is causing the change from 127.0.0.1 to
> localhost and found it:
> After the line
> [https://github.com/apache/cxf/blob/cxf-3.2.5/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/UriInfoImpl.java#L83]
> has been executed the variable u looks like [http://127.0.0.1:8080/]
> After that "toAbsoluteUri" of HttpUtils is called.
> That's the part of the code that replaces 127.0.0.1 by localhost
>
[jira] [Comment Edited] (CXF-8190) UriBuilder / HttpUtils replaces 127.0.0.1 by localhost
[
https://issues.apache.org/jira/browse/CXF-8190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016337#comment-17016337
]
Andriy Redko edited comment on CXF-8190 at 1/15/20 9:24 PM:
Hey [~coheigea], we finally have a Jenkins TCK build job: [1] (I will drop a
message tonight on the list)! Here is the latest report [2] against
3.4.0-SNAPSHOT. To compare, we could do the change and merge into the master
(and rerun the TCK tests ones the 3.4.0-SNAPSHOT are available). In general, we
could run it against the PR builds but it needs a bit more work.
[1] [https://builds.apache.org/view/C/view/Apache%20CXF/job/CXF-JAXRS-TCK/]
[2]
[https://builds.apache.org/view/C/view/Apache%20CXF/job/CXF-JAXRS-TCK/65/artifact/JTreport/html/report.html]
Best Regards,
Andriy Redko
was (Author: reta):
Hey [~coheigea], we finally have a Jenkins TCK build job: [1] (I will drop a
message tonight on the list)! Here is the latest report [2]against
3.4.0-SNAPSHOT. To compare, we could do the change and merge into the master
(and rerun the TCK tests ones the 3.4.0-SNAPSHOT are available). In general, we
could run it against the PR builds but it needs a bit more work.
[1] [https://builds.apache.org/view/C/view/Apache%20CXF/job/CXF-JAXRS-TCK/]
[2]
[https://builds.apache.org/view/C/view/Apache%20CXF/job/CXF-JAXRS-TCK/65/artifact/JTreport/html/report.html]
Best Regards,
Andriy Redko
> UriBuilder / HttpUtils replaces 127.0.0.1 by localhost
> --
>
> Key: CXF-8190
> URL: https://issues.apache.org/jira/browse/CXF-8190
> Project: CXF
> Issue Type: Bug
>Reporter: Markus Rathgeb
>Priority: Major
>
> If you access a locally running REST endpoint in the brower using the IP
> address 127.0.0.1 and the REST endpoint implementation is using the UriInfo
> to build a new URL by the URI builder (e.g. a created resource), the reply
> will not use the host as accessed (127.0.0.1) but replaces the host by
> "localhost".
> If the web application then tries to access the location, the browsers will
> block that request because of a cross origin access.
>
> Assume a very simple REST endpoint:
> {code:java}
> @Component(service = { Resource.class }, scope = ServiceScope.PROTOTYPE)
> @JaxrsResource
> public class Resource {
> @POST
> @Path("create")
> @Produces(MediaType.APPLICATION_JSON)
> public Object createTest(@Context final UriInfo uriInfo) {
> final URI uri =
> uriInfo.getBaseUriBuilder().path("foo").path("bar").build();
> return Response.created(uri).build();
> }
> }{code}
> If I call the post method of that endpoint using the URL
> "[http://localhost:8080/create]; I get a created location that looks like
> "[http://localhost:8080/foo/bar];.
> All fine.
> {noformat}
> $ curl -v -X POST http://localhost:8080/create
> * Trying ::1:8080...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 8080 (#0)
> > POST /create HTTP/1.1
> > Host: localhost:8080
> > User-Agent: curl/7.67.0
> > Accept: */*
> >
> * Mark bundle as not supporting multiuse
> < HTTP/1.1 201 Created
> < Date: Tue, 10 Dec 2019 17:41:47 GMT
> < Location: http://localhost:8080/foo/bar
> < Content-Length: 0
> <
> * Connection #0 to host localhost left intact{noformat}
> But, I would expect if I access the endpoint using the IP instead of the
> hostname "[http://127.0.0.1:8080/create]; the created response's location
> should look like "[http://127.0.0.1:8080/foo/bar];.
> But that is not the case...
> The response provides "[http://localhost:8080/foo/bar];
> {noformat}
> curl -v -X POST http://127.0.0.1:8080/create
> * Trying 127.0.0.1:8080...
> * TCP_NODELAY set
> * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> > POST /create HTTP/1.1
> > Host: 127.0.0.1:8080
> > User-Agent: curl/7.67.0
> > Accept: */*
> >
> * Mark bundle as not supporting multiuse
> < HTTP/1.1 201 Created
> < Date: Tue, 10 Dec 2019 17:44:00 GMT
> < Location: http://localhost:8080/foo/bar
> < Content-Length: 0
> <
> * Connection #0 to host 127.0.0.1 left intact{noformat}
> If the website that is accessed using 127.0.0.1 provides a location using
> localhost and that one is used by the browser, the browser fails because of
> CORS.
>
> I already looked at the sources who is causing the change from 127.0.0.1 to
> localhost and found it:
> After the line
> [https://github.com/apache/cxf/blob/cxf-3.2.5/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/UriInfoImpl.java#L83]
> has been executed the variable u looks like [http://127.0.0.1:8080/]
> After that "toAbsoluteUri" of HttpUtils is called.
> That's the part of the code that replaces 127.0.0.1 by localhost
>
[jira] [Commented] (CXF-8190) UriBuilder / HttpUtils replaces 127.0.0.1 by localhost
[
https://issues.apache.org/jira/browse/CXF-8190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016164#comment-17016164
]
Colm O hEigeartaigh commented on CXF-8190:
--
[~reta] - If
[https://github.com/apache/cxf/blob/cxf-3.2.5/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java#L421-L424]
defaults to false, do any of the TCK tests break?
> UriBuilder / HttpUtils replaces 127.0.0.1 by localhost
> --
>
> Key: CXF-8190
> URL: https://issues.apache.org/jira/browse/CXF-8190
> Project: CXF
> Issue Type: Bug
>Reporter: Markus Rathgeb
>Priority: Major
>
> If you access a locally running REST endpoint in the brower using the IP
> address 127.0.0.1 and the REST endpoint implementation is using the UriInfo
> to build a new URL by the URI builder (e.g. a created resource), the reply
> will not use the host as accessed (127.0.0.1) but replaces the host by
> "localhost".
> If the web application then tries to access the location, the browsers will
> block that request because of a cross origin access.
>
> Assume a very simple REST endpoint:
> {code:java}
> @Component(service = { Resource.class }, scope = ServiceScope.PROTOTYPE)
> @JaxrsResource
> public class Resource {
> @POST
> @Path("create")
> @Produces(MediaType.APPLICATION_JSON)
> public Object createTest(@Context final UriInfo uriInfo) {
> final URI uri =
> uriInfo.getBaseUriBuilder().path("foo").path("bar").build();
> return Response.created(uri).build();
> }
> }{code}
> If I call the post method of that endpoint using the URL
> "[http://localhost:8080/create]; I get a created location that looks like
> "[http://localhost:8080/foo/bar];.
> All fine.
> {noformat}
> $ curl -v -X POST http://localhost:8080/create
> * Trying ::1:8080...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 8080 (#0)
> > POST /create HTTP/1.1
> > Host: localhost:8080
> > User-Agent: curl/7.67.0
> > Accept: */*
> >
> * Mark bundle as not supporting multiuse
> < HTTP/1.1 201 Created
> < Date: Tue, 10 Dec 2019 17:41:47 GMT
> < Location: http://localhost:8080/foo/bar
> < Content-Length: 0
> <
> * Connection #0 to host localhost left intact{noformat}
> But, I would expect if I access the endpoint using the IP instead of the
> hostname "[http://127.0.0.1:8080/create]; the created response's location
> should look like "[http://127.0.0.1:8080/foo/bar];.
> But that is not the case...
> The response provides "[http://localhost:8080/foo/bar];
> {noformat}
> curl -v -X POST http://127.0.0.1:8080/create
> * Trying 127.0.0.1:8080...
> * TCP_NODELAY set
> * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> > POST /create HTTP/1.1
> > Host: 127.0.0.1:8080
> > User-Agent: curl/7.67.0
> > Accept: */*
> >
> * Mark bundle as not supporting multiuse
> < HTTP/1.1 201 Created
> < Date: Tue, 10 Dec 2019 17:44:00 GMT
> < Location: http://localhost:8080/foo/bar
> < Content-Length: 0
> <
> * Connection #0 to host 127.0.0.1 left intact{noformat}
> If the website that is accessed using 127.0.0.1 provides a location using
> localhost and that one is used by the browser, the browser fails because of
> CORS.
>
> I already looked at the sources who is causing the change from 127.0.0.1 to
> localhost and found it:
> After the line
> [https://github.com/apache/cxf/blob/cxf-3.2.5/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/UriInfoImpl.java#L83]
> has been executed the variable u looks like [http://127.0.0.1:8080/]
> After that "toAbsoluteUri" of HttpUtils is called.
> That's the part of the code that replaces 127.0.0.1 by localhost
> [https://github.com/apache/cxf/blob/cxf-3.2.5/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java#L388-L391]
> The commit that added that part of code is
> [https://github.com/apache/cxf/commit/ebc910780b2b9b971a7c1c2e4019bdf9ec35e460#diff-1e4a62a6414e4007d2f5be9f0313c8c0R311-R314]
> The git commit referenced the wrong Jira (2007) - it should have been
> https://issues.apache.org/jira/browse/CXF-5007
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CXF-8193) upgrade to jetty 9.4.25.v20191220
[
https://issues.apache.org/jira/browse/CXF-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-8193.
---
Resolution: Fixed
> upgrade to jetty 9.4.25.v20191220
> -
>
> Key: CXF-8193
> URL: https://issues.apache.org/jira/browse/CXF-8193
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.4.0, 3.3.6
>
>
> 9.4.25 will break JAXRSRequestDispatcherTest.testGetBookHTMLInclude, this is
> caused by the recent change in org.eclipse.jetty.server.Dispatcher.forward
> method.
> However, I took a close look at the
> JAXRSRequestDispatcherTest.testGetBookHTMLInclude, the server bean has
> configuration like
> {code}
>
> {code}
> So I think the test servlet configuration should also have parameter like
> {code}
>
> redirect-with-include
> true
>
> {code}
> accordingly, and this can fix the failure test.
> Seems the change in Jetty just expose a test configuration issue in CXF
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CXF-8193) upgrade to jetty 9.4.25.v20191220
[
https://issues.apache.org/jira/browse/CXF-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang updated CXF-8193:
--
Description:
9.4.25 will break JAXRSRequestDispatcherTest.testGetBookHTMLInclude, this is
caused by the recent change in org.eclipse.jetty.server.Dispatcher.forward
method.
However, I took a close look at the
JAXRSRequestDispatcherTest.testGetBookHTMLInclude, the server bean has
configuration like
{code}
{code}
So I think the test servlet configuration should also have parameter like
{code}
redirect-with-include
true
{code}
accordingly, and this can fix the failure test.
Seems the change in Jetty just expose a test configuration issue in CXF
was:
9.4.25 will break JAXRSRequestDispatcherTest.testGetBookHTMLInclude, this is
caused by the recent change in org.eclipse.jetty.server.Dispatcher.forward
method.
However, I took a close look at the
JAXRSRequestDispatcherTest.testGetBookHTMLInclude, the server bean has
configuration like
{code}
{code}
So I think the servlet configuration should also have parameter like
{code}
redirect-with-include
true
{code}
accordingly, and this can fix the failure test
> upgrade to jetty 9.4.25.v20191220
> -
>
> Key: CXF-8193
> URL: https://issues.apache.org/jira/browse/CXF-8193
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.4.0, 3.3.6
>
>
> 9.4.25 will break JAXRSRequestDispatcherTest.testGetBookHTMLInclude, this is
> caused by the recent change in org.eclipse.jetty.server.Dispatcher.forward
> method.
> However, I took a close look at the
> JAXRSRequestDispatcherTest.testGetBookHTMLInclude, the server bean has
> configuration like
> {code}
>
> {code}
> So I think the test servlet configuration should also have parameter like
> {code}
>
> redirect-with-include
> true
>
> {code}
> accordingly, and this can fix the failure test.
> Seems the change in Jetty just expose a test configuration issue in CXF
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CXF-8193) upgrade to jetty 9.4.25.v20191220
[
https://issues.apache.org/jira/browse/CXF-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang updated CXF-8193:
--
Fix Version/s: 3.3.6
3.4.0
> upgrade to jetty 9.4.25.v20191220
> -
>
> Key: CXF-8193
> URL: https://issues.apache.org/jira/browse/CXF-8193
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.4.0, 3.3.6
>
>
> 9.4.25 will break JAXRSRequestDispatcherTest.testGetBookHTMLInclude, this is
> caused by the recent change in org.eclipse.jetty.server.Dispatcher.forward
> method.
> However, I took a close look at the
> JAXRSRequestDispatcherTest.testGetBookHTMLInclude, the server bean has
> configuration like
> {code}
>
> {code}
> So I think the servlet configuration should also have parameter like
> {code}
>
> redirect-with-include
> true
>
> {code}
> accordingly, and this can fix the failure test
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CXF-8193) upgrade to jetty 9.4.25.v20191220
[
https://issues.apache.org/jira/browse/CXF-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang reassigned CXF-8193:
-
Assignee: Freeman Yue Fang
> upgrade to jetty 9.4.25.v20191220
> -
>
> Key: CXF-8193
> URL: https://issues.apache.org/jira/browse/CXF-8193
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
>
> 9.4.25 will break JAXRSRequestDispatcherTest.testGetBookHTMLInclude, this is
> caused by the recent change in org.eclipse.jetty.server.Dispatcher.forward
> method.
> However, I took a close look at the
> JAXRSRequestDispatcherTest.testGetBookHTMLInclude, the server bean has
> configuration like
> {code}
>
> {code}
> So I think the servlet configuration should also have parameter like
> {code}
>
> redirect-with-include
> true
>
> {code}
> accordingly, and this can fix the failure test
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CXF-8193) upgrade to jetty 9.4.25.v20191220
Freeman Yue Fang created CXF-8193:
-
Summary: upgrade to jetty 9.4.25.v20191220
Key: CXF-8193
URL: https://issues.apache.org/jira/browse/CXF-8193
Project: CXF
Issue Type: Improvement
Reporter: Freeman Yue Fang
9.4.25 will break JAXRSRequestDispatcherTest.testGetBookHTMLInclude, this is
caused by the recent change in org.eclipse.jetty.server.Dispatcher.forward
method.
However, I took a close look at the
JAXRSRequestDispatcherTest.testGetBookHTMLInclude, the server bean has
configuration like
{code}
{code}
So I think the servlet configuration should also have parameter like
{code}
redirect-with-include
true
{code}
accordingly, and this can fix the failure test
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CXF-7949) Update Servlet dependency to 4.x, Tomcat to 9.x and Jetty to 10.x
[
https://issues.apache.org/jira/browse/CXF-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17015864#comment-17015864
]
Dennis Kieselhorst commented on CXF-7949:
-
Do we still need {{cxf.servlet-api-2.5.artifact}} and
{{cxf.servlet-api-2.5.version}} or can we get rid of it?
> Update Servlet dependency to 4.x, Tomcat to 9.x and Jetty to 10.x
> -
>
> Key: CXF-7949
> URL: https://issues.apache.org/jira/browse/CXF-7949
> Project: CXF
> Issue Type: Task
>Reporter: Dennis Kieselhorst
>Priority: Minor
> Fix For: 3.4.0
>
>
> Use Jakarta Servlet release https://github.com/eclipse-ee4j/servlet-api
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8168) Wadl2java maven plugin not allows mapping to array types
[ https://issues.apache.org/jira/browse/CXF-8168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8168. > Wadl2java maven plugin not allows mapping to array types > > > Key: CXF-8168 > URL: https://issues.apache.org/jira/browse/CXF-8168 > Project: CXF > Issue Type: Wish > Components: JAX-RS >Affects Versions: 3.3.4 >Reporter: Vjacheslav Borisov >Assignee: Alexey Markevich >Priority: Minor > Fix For: 3.4.0, 3.3.5 > > > Wadl2java maven plugin not allows mapping to array types, like > > -repMap > application/octet-stream=byte[] > > Error: > org.apache.cxf.tools.common.toolspec.parser.BadUsageException: -repMap has > invalid character! > > [link example project|https://github.com/slavb18/wadlarray] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8174) Incorrect service method resolution
[
https://issues.apache.org/jira/browse/CXF-8174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8174.
> Incorrect service method resolution
> ---
>
> Key: CXF-8174
> URL: https://issues.apache.org/jira/browse/CXF-8174
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.8, 3.3.0
>Reporter: Rafał Kopka
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.4.0, 3.3.5, 3.2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Assume JAX-RS resource classes:
> {code}
> public interface TestService com.test.BaseResponse> {
> RES process(REQ request);
> }
> {code}
> {code}
> public interface MyTestService extends
> TestService {
> @Override
> @POST
> @Path("record")
> @Valid
> com.test.MyTestServiceResponse process(com.test.MyTestServiceRequest
> request);
> }
> {code}
> When we call MyTestService, CXF resolves method from TestService
> {code}
> com.test.BaseResponse process(com.test.BaseRequest request)
> {code}
> This causes Jackson deserialization error due to unknown properties sent in
> {code}
> com.test.MyTestServiceResponse
> {code}
> This occurs due to changes in OperationResourceInfoComparator (CXF-7946)
> where parameter class names are compared.
> Explicit package in the sample is due to the fact that there is an easy
> workaround - remove all extends from parent interface. This won't work if
> your package is anything after java.lang
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8157) Update to Jackson Databind 2.9.10.1
[ https://issues.apache.org/jira/browse/CXF-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8157. > Update to Jackson Databind 2.9.10.1 > --- > > Key: CXF-8157 > URL: https://issues.apache.org/jira/browse/CXF-8157 > Project: CXF > Issue Type: Task >Affects Versions: 3.3.4 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.4.0, 3.3.5 > > Time Spent: 20m > Remaining Estimate: 0h > > 2.9.10.1 (20-Oct-2019) > #2478: Block two more gadget types (commons-dbcp, p6spy, CVE-2019-16942 / > CVE-2019-16943) (reported by b5mali4 / r...@codersec.net) > #2498: Block one more gadget type (log4j-extras/1.2, CVE-2019-17531) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8153) @Path with REGEX in path parameter and checkMethodsForInvalidURITemplates(userType, methods);
[
https://issues.apache.org/jira/browse/CXF-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8153.
> @Path with REGEX in path parameter and
> checkMethodsForInvalidURITemplates(userType, methods);
> --
>
> Key: CXF-8153
> URL: https://issues.apache.org/jira/browse/CXF-8153
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.3.4
>Reporter: Luís Alves
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 3.4.0, 3.3.5
>
>
> I have an API jar provided by the server, with the interface with all the
> JAX-RS annotations.
> One of then has an REGEX. Something like:
> {code:java}
> @Path("{ resoureUUID :
> [0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}}}")
> {code}
> I can't create a proxy because the validation fails. Analyzing the code I get
> to
> org.apache.cxf.microprofile.client.Validator#checkMethodsForInvalidURITemplates(Class,
> Method[]), more specifically to this part (with comments):
> {code:java}
> for (Parameter p : method.getParameters()) {
> PathParam pathParam = p.getAnnotation(PathParam.class);
> if (pathParam != null) {
> // don't know the spec, but setting this to "x" cause
> the URITemplate to
>// throw new IllegalArgumentException("Value '" + sval
> + "' does not match variable " + var.getName() + " with pattern " +
> var.getPattern());
> paramMap.put(pathParam.value(), "x");
> }
> }
> try {
> template.substitute(paramMap,
> Collections.emptySet(), false);
> } catch (IllegalArgumentException ex) {
> throwException("VALIDATION_UNRESOLVED_PATH_PARAMS",
> userType, method);
> }
> {code}
> Not sure if this is a bug or by spec, but this prevents to use path params
> with regex, as the only regex that works must match "x".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8140) setAccessible(true) before reflection method java.security.acl.Group#members invocation in DefaultSecurityContext
[ https://issues.apache.org/jira/browse/CXF-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8140. > setAccessible(true) before reflection method java.security.acl.Group#members > invocation in DefaultSecurityContext > - > > Key: CXF-8140 > URL: https://issues.apache.org/jira/browse/CXF-8140 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.3.4 >Reporter: Jim Ma >Assignee: Jim Ma >Priority: Major > Fix For: 3.4.0, 3.3.5 > > Time Spent: 40m > Remaining Estimate: 0h > > When the invocation target Group is defined in a private static class or some > nested class, > the reflection invocation for java.security.acl.Group#members fails. > Add a setAcessible(true) in DefaultSecurityContext to improve this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8163) javax.ws.rs.core.Response#getCookies() fails when cookie has no value
[ https://issues.apache.org/jira/browse/CXF-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8163. > javax.ws.rs.core.Response#getCookies() fails when cookie has no value > - > > Key: CXF-8163 > URL: https://issues.apache.org/jira/browse/CXF-8163 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.11, 3.3.4 >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko >Priority: Major > Fix For: 3.4.0, 3.3.5, 3.2.12 > > Time Spent: 20m > Remaining Estimate: 0h > > It is common for a server to bypass the cookie value to reset the cookie, > there the jax-rs client fails to parse it with an exception whereas I think > it should ignore the cookie entry. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8187) Codegen-Plugin failed when maven is executed on jdk9+ with Toolchains specifying jdk 8
[
https://issues.apache.org/jira/browse/CXF-8187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8187.
> Codegen-Plugin failed when maven is executed on jdk9+ with Toolchains
> specifying jdk 8
> --
>
> Key: CXF-8187
> URL: https://issues.apache.org/jira/browse/CXF-8187
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 3.3.4
>Reporter: JANTON
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.3.5
>
>
> Codegen-Plugin failed when :
> # maven is executed on jdk9+ (ex : JAVA_HOME on a JDK 11)
> # JDK 8 is asked through toolchain plugin
> Sample of execution result :
> {code}
> [INFO] --- cxf-codegen-plugin:3.3.4:wsdl2java (x) @ x ---
> [INFO] Running code generation in fork mode...
> [INFO] Using toolchain JDK[c:/jdk1.8] to find the java executable
> [INFO] The java executable is c:\jdk1.8\bin\java.exe
> [INFO] Building jar:
> C:\tmp\cxf-tmp-13126677158727590310\cxf-codegen13282347933764786924.jar
> [WARNING] Error: Could not create the Java Virtual Machine.
> [WARNING] Error: A fatal exception has occurred. Program will exit.
> [WARNING] Unrecognized option:
> --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED
> []
> [ERROR] Failed to execute goal
> org.apache.cxf:cxf-codegen-plugin:3.3.4:wsdl2java (x) on project x:
> [ERROR] Exit code: 1
> [ERROR] Command line was: cmd.exe /X /C "c:\jdk1.8\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:\tmp\cxf-tmp-13126677158727590310\cxf-codegen13282347933764786924.jar
> C:\tmp\cxf-tmp-13126677158727590310\cxf-w2j10127470885320069515args"
> {code}
> The error seems to come from the additionalJvmArgs for java 9
> (--add-exports=..., --add-opens=...) : the command line manually executed
> failled with these args but succeed whithout). It seems that
> [AbstractCodegenMojo#execute()|https://github.com/apache/cxf/blob/cxf-3.3.4/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/AbstractCodegenMoho.java]
> doesn't test the right JDK to detect if the java 9 additionalJvmArgs should
> be add : the test is currently on the JDK used by maven instead of the one
> that will be run by Codegen-Plugin.
> Regards
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8139) SecurityToken, parsing the lifetime may cause a NullPointerException
[ https://issues.apache.org/jira/browse/CXF-8139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8139. > SecurityToken, parsing the lifetime may cause a NullPointerException > > > Key: CXF-8139 > URL: https://issues.apache.org/jira/browse/CXF-8139 > Project: CXF > Issue Type: Bug > Components: STS >Affects Versions: 3.1.6 >Reporter: Daniel Baumann >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.4.0, 3.3.5, 3.2.12 > > > According to > [http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html] the > wsu:Created and wsu:Expires are optional elements in > /wst:RequestSecurityToken/wst:Lifetime. > When creating the org.apache.cxf.ws.security.tokenstore.SecurityToken using a > lifetime Element where not both (created and expired) elements are set, a > NullPointerException is thrown as there is no null-check on the child > elements of the lifetime element. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8097) Equal candidates for handling the current request (HEAD / GET)
[
https://issues.apache.org/jira/browse/CXF-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8097.
> Equal candidates for handling the current request (HEAD / GET)
> --
>
> Key: CXF-8097
> URL: https://issues.apache.org/jira/browse/CXF-8097
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.3.2, 3.3.3, 3.3.4
>Reporter: Carsten D
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.4.0, 3.3.5, 3.2.12
>
> Attachments: Screenshot 2019-12-17 at 08.44.29.png, cxf-8097-mcve.zip
>
>
> I have just migrated a very outdated Spring backend to Spring 5 and with it
> upgraded CXF to first 3.3.2 and just now 3.3.3. I have a REST service class
> defining two different methods with the same path defined via
> {{javax.ws.rs.Path}} annotation, differentiated by {{javax.ws.rs.HEAD}} and
> {{javax.ws.rs.GET}} annotations. Both methods are annotated with
> {{@Produces(MediaType.APPLICATION_OCTET_STREAM)}}.
> When this method is called I get (redacted):
> {{WARN [JAXRSUtils.compare:129] Both ServiceRestImpl#getFile and
> ServiceRestImpl#getFileAsHeadRequest are equal candidates for handling the
> current request which can lead to unpredictable results}}
> The differentiation works: HEAD requests are handled by the {{@HEAD}}
> annotated method and GET requests by the {{@GET}} annotated one (this has
> always worked). Therefore the warning is false but will severely clutter
> production log output, possibly affect performance.
> Relevant dependencies:
> * Spring framework 5.1.8
> * "org.apache.cxf", "cxf-rt-rs-service-description", "3.3.3"
> * "javax.servlet", "javax.servlet-api", "4.0.1"
> * "javax.ws.rs", "javax.ws.rs-api", "2.0.1"
> I'd appreciate support. May be linked to:
> * CXF-7670
> * CXF-6684
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8155) Update to Jackson 2.10.1
[
https://issues.apache.org/jira/browse/CXF-8155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8155.
> Update to Jackson 2.10.1
>
>
> Key: CXF-8155
> URL: https://issues.apache.org/jira/browse/CXF-8155
> Project: CXF
> Issue Type: Task
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.4.0, 3.3.5
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The 2.10.x fails to be processed by pax-exam 4.13.1 (OSGi dependencies, more
> precisely by biz.aQute.bnd/bndlib/2.4.0 on JDK8 at least), sadly there are no
> new pax releases to try out.
>
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 19
> at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:576)
> at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:494)
> at aQute.bnd.osgi.Clazz.parseClassFileWithCollector(Clazz.java:483)
> at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:473)
> at aQute.bnd.osgi.Analyzer.analyzeJar(Analyzer.java:2177)
> at aQute.bnd.osgi.Analyzer.analyzeBundleClasspath(Analyzer.java:2083)
> at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:138)
> at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:616)
> at org.ops4j.pax.swissbox.bnd.BndUtils.createBundle(BndUtils.java:161)
> at
> org.ops4j.pax.url.wrap.internal.Connection.getInputStream(Connection.java:83)
> at java.net.URL.openStream(URL.java:1067)
> at
> org.apache.karaf.features.internal.download.impl.SimpleDownloadTask.download(SimpleDownloadTask.java:78)
> at
> org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:60)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
> The following changes seems to fix the issues with Jackson 2.10.x update:
> 1. Removing {{wrap}} for Jackson JAX-RS modules. The 'wrap' caused the issue
> with {{bndlib}} since Jackson 2.10.x introduces {{module-info.class}} / built
> with JDK9+. The exception in the logs:
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 19
> at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:576)
> at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:494)
> at aQute.bnd.osgi.Clazz.parseClassFileWithCollector(Clazz.java:483)
> at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:473)
> at aQute.bnd.osgi.Analyzer.analyzeJar(Analyzer.java:2177)
> at aQute.bnd.osgi.Analyzer.analyzeBundleClasspath(Analyzer.java:2083)
> at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:138)
> at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:616)
> at
> org.ops4j.pax.swissbox.bnd.BndUtils.createBundle(BndUtils.java:161){noformat}
> 2. The conflicts with 'javax.xml.bind.annotation' exports, forced to remove
> 'jackson-module-jaxb-annotations' module:
> {noformat}
> karaf@root()> find-class javax.xml.bind.annotation.XmlRootElement
> Jackson module: JAXB Annotations (22)
> javax/xml/bind/annotation/XmlRootElement.class
> jakarta.xml.bind-api (25)
> javax/xml/bind/annotation/XmlRootElement.class
> {noformat}
> It basically caused weird issues with our 'AbstractJAXBProvider' /
> 'JAXBElementProvider' which was not picked up because of 'isXmlType'
> apparently dealt with two instances of 'XmlRootElement' coming from different
> bundles.
>
> [1]
> [http://karaf.922171.n3.nabble.com/Karaf-4-2-3-uses-glassfish-jaxb-2-3-2-which-is-java-9-is-this-a-problem-td4055485.html]
> [2]
> https://stackoverflow.com/questions/57808832/apache-karaf-startup-arrayindexoutofboundsexception-19
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8144) OpenAPI v3 Feature: duplicated "getOpenApi" methods
[
https://issues.apache.org/jira/browse/CXF-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8144.
> OpenAPI v3 Feature: duplicated "getOpenApi" methods
> ---
>
> Key: CXF-8144
> URL: https://issues.apache.org/jira/browse/CXF-8144
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.3.3, 3.3.4
>Reporter: Mike Kelly
>Assignee: Andriy Redko
>Priority: Minor
> Fix For: 3.4.0, 3.3.5
>
>
> Any calls to the OpenAPI documentation, as provided by the
> {{cxf-rt-rs-service-description-openapi-v3}} artifact, cause this warning to
> be logged:
> {noformat}
> 2019-11-05 16:48:43,551 [http-nio-8080-exec-9] WARN
> org.apache.cxf.jaxrs.utils.JAXRSUtils - Both
> org.apache.cxf.jaxrs.swagger.ui.SwaggerUiService#getResource and
> org.apache.cxf.jaxrs.swagger.ui.SwaggerUiService#getResource are equal
> candidates for handling the current request which can lead to unpredictable
> results
> {noformat}
> If you're loading or refreshing the API documentation, you'll see a whole lot
> of these warnings get logged.
> This seems like something that is likely a spurious message, or a design flaw
> in the Apache CXF modules?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8186) On connection refused, XSLTOutInterceptor mangles the error
[ https://issues.apache.org/jira/browse/CXF-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8186. > On connection refused, XSLTOutInterceptor mangles the error > --- > > Key: CXF-8186 > URL: https://issues.apache.org/jira/browse/CXF-8186 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.11, 3.3.4 >Reporter: Réda Housni Alaoui >Priority: Major > Fix For: 3.4.0, 3.3.5, 3.2.12 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8178) ECDH KeyAgreement with Key Wrapping is not in line with the specification
[
https://issues.apache.org/jira/browse/CXF-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8178.
> ECDH KeyAgreement with Key Wrapping is not in line with the specification
> -
>
> Key: CXF-8178
> URL: https://issues.apache.org/jira/browse/CXF-8178
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
>Affects Versions: 3.3.4
>Reporter: Frederik Libert
>Assignee: Colm O hEigeartaigh
>Priority: Blocker
> Fix For: 3.4.0, 3.3.5
>
>
> Key Derivation for ECDH Key Agreement is different if Direct mode or KeyWrap
> mode is used: key length and algorithmid are calculated in a different way.
> However, the code of apache cxf uses the same code block for both.
> This makes it correct for Direct mode but wrong for KeyWrap mode as the
> algorithmID and keydatalen is always based on the value of the "enc" field,
> which is wrong for KeyWrap.
> See extract specs below.
> RFC JWA (https://tools.ietf.org/html/rfc7518#page-15)
> {panel}
> keydatalen
> This is set to the number of bits in the desired output key. For
> "ECDH-ES", this is length of the key used by the "enc" algorithm.
> For "ECDH-ES+A128KW", "ECDH-ES+A192KW", and "ECDH-ES+A256KW", this
> is 128, 192, and 256, respectively.
>AlgorithmID
> The AlgorithmID value is of the form Datalen || Data, where Data
> is a variable-length string of zero or more octets, and Datalen is
> a fixed-length, big-endian 32-bit counter that indicates the
> length (in octets) of Data. In the Direct Key Agreement case,
> Data is set to the octets of the ASCII representation of the "enc"
> Header Parameter value. In the Key Agreement with Key Wrapping
> case, Data is set to the octets of the ASCII representation of the
> "alg" (algorithm) Header Parameter value.
> {panel}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8169) CXF opentracing - Span#finish is never called in case of client timeouts
[ https://issues.apache.org/jira/browse/CXF-8169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8169. > CXF opentracing - Span#finish is never called in case of client timeouts > > > Key: CXF-8169 > URL: https://issues.apache.org/jira/browse/CXF-8169 > Project: CXF > Issue Type: Bug > Components: Tracing >Affects Versions: 3.2.11, 3.3.4, 3.4.0 >Reporter: Baptiste AIGLIN >Assignee: Andriy Redko >Priority: Major > Fix For: 3.4.0, 3.3.5, 3.2.12 > > Attachments: cxf-reproducer.tar.gz > > > While using the CXF opentracing feature with any CXF client, we see that in > case of connectionTimeout or receiveTimeout the span#finish is never called > by the OpenTracing client interceptors. We can clearly see that inside the > OpenTracingClientStartInterceptor from the OpenTracingClientFeature there is > no handleFault() method defined to handle such case. > I wrote the test allowing to reproduce this behavior using a JAX-RS client > and a really simplistic fix on the CustomOpenTracingClientFeature where the > current OpenTracingClientStartInterceptor is overriden in order to add such > handleFault method and using the > OpenTracingClientStopInterceptor#handleMethod in order to trigger the stop. > Thanks in advance for your feedback. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8130) Since Spring 5.1.5 Release CXFServlet application listener dissapears by context refresh
[
https://issues.apache.org/jira/browse/CXF-8130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8130.
> Since Spring 5.1.5 Release CXFServlet application listener dissapears by
> context refresh
>
>
> Key: CXF-8130
> URL: https://issues.apache.org/jira/browse/CXF-8130
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.3.2, 3.3.3
>Reporter: Roman Platonov
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.4.0, 3.3.5
>
>
> Hi,
> I have following problem after the changes in Spring Framework [commit
> there|#L606]]
> So, at the start of the application startup there is a call of
> {{prepareRefresh()}}, so it works like that:
>
> {code:java}
> this.earlyApplicationListeners = new
> LinkedHashSet<>(this.applicationListeners);
> {code}
>
> and this collection is empty.
> Then is CXFServlet I have addition of listener - [Cxf
> link|https://github.com/apache/cxf/blob/ec4423437bd7d6b63e3464761394cfafb50cacfa/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/CXFServlet.java#L90]
>
> Then it's needed to refresh the Application Context, so it provokes the
> {{refresh()}} at AbstractApplicationContext, then goes to {{prepareRefresh}}
> and then checks
> {code:java}
> this.earlyApplicationListeners == null,{code}
> but it's an empty LinkedHashSet, not null, so then it comes to
> {code:java}
> this.applicationListeners.clear(); {code}
>
> and it removes the listener from CXFServlet, so there is no event coming to
> CXFServlet.
> Is there any solution? Maybe it's better to change the logic of addition the
> listener to context?
>
> I have also add the comment to spring framework issue
> ([Issue|[https://github.com/spring-projects/spring-framework/issues/22325]])
>
> Thank you!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8180) UnsupportedOperationException in AbstractEndpointFactory
[
https://issues.apache.org/jira/browse/CXF-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8180.
> UnsupportedOperationException in AbstractEndpointFactory
>
>
> Key: CXF-8180
> URL: https://issues.apache.org/jira/browse/CXF-8180
> Project: CXF
> Issue Type: Bug
> Components: Core, JAX-RS
>Affects Versions: 3.3.4
> Environment: 3.3.4.
>Reporter: Dominik Reinarz
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.4.0, 3.3.5, 3.2.12
>
>
> h4. exception(!):
> {code:java}
> Caused by: java.lang.UnsupportedOperationException
> at java.base/java.util.AbstractList.add(AbstractList.java:153)
> at java.base/java.util.AbstractList.add(AbstractList.java:111)
> at
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:336)
> at
> org.apache.cxf.endpoint.AbstractEndpointFactory.initializeAnnotationInterceptors(AbstractEndpointFactory.java:274){code}
> h4. cause(flag):
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.getFeatures(ServletConfig,
> String)
> {code:java}
> if (featuresList == null) {
> return Collections.< Feature >emptyList();
> }{code}
> EmptyList extends AbstractList...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8171) SSE Client does not support multiple data fields
[ https://issues.apache.org/jira/browse/CXF-8171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8171. > SSE Client does not support multiple data fields > > > Key: CXF-8171 > URL: https://issues.apache.org/jira/browse/CXF-8171 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.5, 3.3.4 >Reporter: Alexander Onnikov >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.4.0, 3.3.5, 3.2.12 > > Time Spent: 20m > Remaining Estimate: 0h > > According to [Server-Sent Events > specification|https://www.w3.org/TR/eventsource/#parsing-an-event-stream] > events may contain multiple *data* fields. In this case the client should > concatenate all data field values with U+000A LINE FEED (LF) character. > Current SSE client implementation keeps only latest line. > > I provided PR with test case that demonstrates the issue and fix. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8177) JWE API does not support ECDH Direct Encryption/Decryption
[ https://issues.apache.org/jira/browse/CXF-8177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8177. > JWE API does not support ECDH Direct Encryption/Decryption > --- > > Key: CXF-8177 > URL: https://issues.apache.org/jira/browse/CXF-8177 > Project: CXF > Issue Type: Improvement > Components: JAX-RS Security >Affects Versions: 3.3.4 >Reporter: Frederik Libert >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.4.0, 3.3.5 > > Time Spent: 20m > Remaining Estimate: 0h > > Although the Apache CXF implementation of JWE supports ECDH Direct > encryption/decryption, the API is not sufficiently open for it. > A few problems: > * KeyAlgorithm.getAlgorithm(String) does not support parsing ECDH > * EcdhDirectKeyDecryptionAlgorithm is a private innerclass so cannot be used > from the clientview perspective (different approach for different algorithms, > why?) > * EcdhDirectKeyJweDecryption makes an assumption that AES GCM is used > without verifying (could be AES CBC as well) > * JweUtils.getPrivateKeyDecryptionProvider(PrivateKey,KeyAlgorithm) makes > an assumption that AESWrap is used in case of an EC Key without veryfing the > KeyAlgorithm (could be Direct as well) > The API should support proper handling of key algorithm between client and > library and should verify what is given as input to decide which key and > content decrypters to use. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8150) Update to Spring Boot 2.1.10
[ https://issues.apache.org/jira/browse/CXF-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8150. > Update to Spring Boot 2.1.10 > > > Key: CXF-8150 > URL: https://issues.apache.org/jira/browse/CXF-8150 > Project: CXF > Issue Type: Task >Affects Versions: 3.4.0, 3.3.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.4.0, 3.3.5 > > > Updating to latest Spring Boot 2.1.10 release. Also added the dedicate > systests suite for Spring Boot related tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8162) JWE with multiple recipients does not work for AES CBC Encryption
[ https://issues.apache.org/jira/browse/CXF-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8162. > JWE with multiple recipients does not work for AES CBC Encryption > - > > Key: CXF-8162 > URL: https://issues.apache.org/jira/browse/CXF-8162 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.3.4 >Reporter: Frederik Libert >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.4.0, 3.3.5 > > Time Spent: 20m > Remaining Estimate: 0h > > When encrypting for multiple recipients, the plaintext, the CEK, JWE > Initialization Vector, and JWE Protected Header are shared by all recipients > (which must be the case, since > the ciphertext and Authentication Tag are also shared). > The Apache CXF API for encrypting the content with AES GCM allows this by > initializing a ContentEncryptionProvider of type > AesGcmContentEncryptionAlgorithm which can be used as reference when > initializing the list of JweEncryptionProviders (which take a > KeyEncryptionProvider and an ContentEncryptionProvider). > When using AES CBC, the API is different. > The class AesCbcContentEncryptionAlgorithm is a private innerclass of > JweEncryptionProvider AesCbcHmacJweEncryption so you can't initialize it once > and reuse it in all JweEncryptionProviders of the list. > There is a workaround as the API allows to build the CEK and > InitializationVector yourself (not very nice), the API for AES CBC encryption > should allow the initialization of the ContentEncryptionProvider from outside > the JweEncryptionProvider so it can be referenced in all > JweEncryptionProviders. > Without that, you can only encrypt for 1 recipient or the validation will > fail (invalid authentication tag) for all but 1 recipient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8191) align dom4j bundle version to 2.1.1
[ https://issues.apache.org/jira/browse/CXF-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8191. > align dom4j bundle version to 2.1.1 > --- > > Key: CXF-8191 > URL: https://issues.apache.org/jira/browse/CXF-8191 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 3.4.0, 3.3.5 > > > So far we have > 2.1.1 > but > 1.6.1_5 > From Servicemix we already have dom4j bundle 2.1.1, so should align to this > version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8160) Workaround in the cxf-jackson feature has to be removed
[
https://issues.apache.org/jira/browse/CXF-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8160.
> Workaround in the cxf-jackson feature has to be removed
> ---
>
> Key: CXF-8160
> URL: https://issues.apache.org/jira/browse/CXF-8160
> Project: CXF
> Issue Type: Improvement
> Components: OSGi
>Affects Versions: 3.3.4
>Reporter: Xilai Dai
>Priority: Major
> Fix For: 3.4.0, 3.3.5
>
>
> The jackson-jaxrs-base/2.8.x and jackson-jaxrs-json-provider/2.8.x don's
> support jaxrs-api 2.1 from the MANIFEST.MF for OSGi installation:
> {code}
> Import-Package: javax.ws.rs.core;version="[2.0,2.1)" ...
> {code}
> Had to patch the cxf-jackson feature in this commit:
> https://github.com/apache/cxf/commit/3fe8e92229ba50dbc6758e6420b44ac16751281e#diff-f317dd8b5c6e2b464fc7873425dcb19b
> Now, the jackson-jaxrs-base/2.9.x and jackson-jaxrs-json-provider/2.9.x (used
> in the CXF 3.3.x) already support the jaxrs-api 2.1
> {code}
> Import-Package =
> javax.ws.rs.core;version="[2.0,2.2)",
> javax.ws.rs.ext;version="[2.0,2.2)",
> javax.ws.rs;version="[2.0,2.2)"
> {code}
> This workaround now can be removed from the cxf-jackson feature.
> Another good reason is the ArrayIndexOutOfBoundsException will be thrown when
> try to install the cxf-jackson feature to the latest OSGi Karaf container.
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 19
> at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:576)
> at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:494)
> at aQute.bnd.osgi.Clazz.parseClassFileWithCollector(Clazz.java:483)
> at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:473)
> at aQute.bnd.osgi.Analyzer.analyzeJar(Analyzer.java:2177)
> at aQute.bnd.osgi.Analyzer.analyzeBundleClasspath(Analyzer.java:2083)
> at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:138)
> at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:616)
> at org.ops4j.pax.swissbox.bnd.BndUtils.createBundle(BndUtils.java:161)
> at
> org.ops4j.pax.url.wrap.internal.Connection.getInputStream(Connection.java:83)
> at java.net.URL.openStream(URL.java:1045)
> at
> org.apache.karaf.features.internal.download.impl.SimpleDownloadTask.download(SimpleDownloadTask.java:78)
> at
> org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:60)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8143) ensure java2wadl-plugin m2e compatible
[ https://issues.apache.org/jira/browse/CXF-8143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8143. > ensure java2wadl-plugin m2e compatible > -- > > Key: CXF-8143 > URL: https://issues.apache.org/jira/browse/CXF-8143 > Project: CXF > Issue Type: Bug >Reporter: Freeman Yue Fang >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 3.4.0, 3.3.5, 3.2.12 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8179) JSON Jackson does not handle resource returning CompletionStage
[ https://issues.apache.org/jira/browse/CXF-8179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8179. > JSON Jackson does not handle resource returning CompletionStage > -- > > Key: CXF-8179 > URL: https://issues.apache.org/jira/browse/CXF-8179 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.11, 3.3.4 >Reporter: Baptiste AIGLIN >Assignee: Andriy Redko >Priority: Major > Fix For: 3.4.0, 3.3.5, 3.2.12 > > Attachments: cxf-mp-reproducer.zip, exception.txt > > > Hello, > > While testing to integrate the CXF Microprofile implementation in order to > perform asynchronous client calls using client proxies, I encounter the > Exception raised by the json provider due to the returned generic type being > CompletionStage. > > It is clear that MicroProfileClientProxyImpl#getReturnType(Method, Message) > is behaving correctly regarding the returnType, however inside the > ClientProxyImpl#handleResponse(Message, Class) we also compute the > genericType based on the method.getGenericReturnType() which is of type > CompletionStage, therefore the provider is not able to deserialize the String > correctly as internally it uses the genericType. > Do you think it could be possible to update the > InjectionUtils.processGenericTypeIfNeeded to add cases for CompletionStage > in order to change the genericType returned in this case ? > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8161) Memory Leak/Thread Leak in JMSDestination & PollingMessageListenerContainer
[ https://issues.apache.org/jira/browse/CXF-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8161. > Memory Leak/Thread Leak in JMSDestination & PollingMessageListenerContainer > --- > > Key: CXF-8161 > URL: https://issues.apache.org/jira/browse/CXF-8161 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.2.11, 3.3.4 >Reporter: Christian Steiner >Priority: Major > Fix For: 3.4.0, 3.3.5, 3.2.12 > > Time Spent: 40m > Remaining Estimate: 0h > > Hi, > when you create a JMS-Endpoint with concurrentConsumers > 1, > PollingMessageListenerContainer starts a ThreadPoolExecutor running > _concurrentConsumers_ instances of the class > PollingMessageListenerContainer#Poller (or XAPoller) > If a exception from the jms-connection occurs, each Poller instance triggers > JMSDestination#restartConnection, so JMSDestination creates > _concurrentConsumers_ PollingMessageListenerContainer with > _concurrentConsumers_*_concurrentConsumers_ Poller instances and threads and > jms-consumers (for each Exception). > If you have _concurrentConsumers_ set to 10, first exception causes 100 > threads, next exception 1000 etc. > Also is PollingMessageListenerContainer#stop not working, because in case of > an Exception first the running-Flag in PollingMessageListenerContainer will > be set to false. This causes old ThreadPools not to be cleaned up, the > ThreadPools stay alive. > The Garbage Collector cann't clean up old instances of > PollingMessageListenerContainer and Poller. > I think this Bug relates to CXF-7197 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8158) @BeanParam arguments not properly translated to OpenApi
[
https://issues.apache.org/jira/browse/CXF-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8158.
> @BeanParam arguments not properly translated to OpenApi
> ---
>
> Key: CXF-8158
> URL: https://issues.apache.org/jira/browse/CXF-8158
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.11, 3.3.4
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 3.4.0, 3.3.5, 3.2.12
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a method is defined as follows:
> {code}
> /**
> * @param query query parameters
> */
> Response search(@BeanParam Query query);
> {code}
> with the {{Query}} bean having more than one field, the OpenAPI description
> comes correctly with all parameters from {{Query}} but the first one shows
> the description from javadoc.
> This is due by the fact that in {{OpenApiCustomizer}} it is assumed that the
> JAX-RS parameters and OpenAPI parameters are the same, while {{@BeanParam}}
> breaks such condition.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8152) Add a property so it's possible to build cxf with posix tarLongFileMode
[ https://issues.apache.org/jira/browse/CXF-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8152. > Add a property so it's possible to build cxf with posix tarLongFileMode > > > Key: CXF-8152 > URL: https://issues.apache.org/jira/browse/CXF-8152 > Project: CXF > Issue Type: Improvement > Components: Build system >Reporter: Thomas Cunningham >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 3.4.0, 3.3.5 > > > Adding a property so we can build cxf with posix tarLongFileMode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8137) Using SecurityConstants.VALIDATE_TOKEN with WSS4JInInterceptor no longer allows skipping validation of token
[ https://issues.apache.org/jira/browse/CXF-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8137. > Using SecurityConstants.VALIDATE_TOKEN with WSS4JInInterceptor no longer > allows skipping validation of token > > > Key: CXF-8137 > URL: https://issues.apache.org/jira/browse/CXF-8137 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.10 >Reporter: Bjørn Hilstad >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.3.5, 3.2.12 > > > Have been using SecurityConstants.VALIDATE_TOKEN=false to skip validation of > UsernameToken with CXF 3.2.x successfully for a long time but this feature > broke in 3.2.10. > The reason is that the method getSecurityEngine(boolean utWithCallbacks) in > WSS4JInInterceptor returns a different SecurityEngine than before. > Up to version 3.2.9 using SecurityConstants.VALIDATE_TOKEN=false this method > gave a WSSecurityEngine which had a WSSConfig with a validatorMap where the > validator for > "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken; > was a org.apache.wss4j.dom.validate.NoOpValidator. > From 3.2.10 it gives a WSSecurityEngine that has a WSSConfig with a > validatorMap where the validator for > "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken; > was a org.apache.wss4j.dom.validate.UsernameTokenValidator and hence the > validation is NOT skipped anymore. > Should this feature still work for 3.2.10 or has it been removed on purpose? > Could probably be solved by just switching the order of the if-statements in > getSecurityEngine(boolean utWithCallbacks). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8181) CXFNonSpringJaxrsServlet Feature registration fails via javax.ws.rs.Application
[
https://issues.apache.org/jira/browse/CXF-8181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8181.
> CXFNonSpringJaxrsServlet Feature registration fails via
> javax.ws.rs.Application
> ---
>
> Key: CXF-8181
> URL: https://issues.apache.org/jira/browse/CXF-8181
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.11, 3.3.4
>Reporter: Noel Ang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.4.0, 3.3.5, 3.2.12
>
>
> *CXFNonSpringJaxrsServlet* always overwrites Features surfaced by a
> javax.ws.rs.core.Application implementation with Features specified in the
> servlet configuration, _even if the latter set is empty_.
> The server factory bean
> [created|https://github.com/apache/cxf/blob/b75830ffd90cab9cfcdc7550fdd17490dbe9c8c5/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/servlet/CXFNonSpringJaxrsServlet.java#L514-L519]
> to encapsulate the instantiated Application class has its Features list
> initialized twice.
> * The [first
> time|https://github.com/apache/cxf/blob/b75830ffd90cab9cfcdc7550fdd17490dbe9c8c5/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ResourceUtils.java#L947]
> uses the classes [that the Application
> yields|https://github.com/apache/cxf/blob/b75830ffd90cab9cfcdc7550fdd17490dbe9c8c5/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ResourceUtils.java#L903-L904].
> * The [second
> time|https://github.com/apache/cxf/blob/b75830ffd90cab9cfcdc7550fdd17490dbe9c8c5/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/servlet/CXFNonSpringJaxrsServlet.java#L529-L530]
> uses the classes that the [Servlet configuration
> describes|https://github.com/apache/cxf/blob/b75830ffd90cab9cfcdc7550fdd17490dbe9c8c5/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/servlet/CXFNonSpringJaxrsServlet.java#L323-L326].
> The features enumerated by the servlet config
> [replaces|https://github.com/apache/cxf/blob/b75830ffd90cab9cfcdc7550fdd17490dbe9c8c5/core/src/main/java/org/apache/cxf/endpoint/AbstractEndpointFactory.java#L176-L178]
> the first list.
>
> I discovered the problem while trying to get OpenAPI 3.0 / Swagger-UI support
> to work, so FWIW, an example:
> * Application implementation that registers OpenApiFeature.
>
> {code:java}
> package org.foo.service;
> import org.apache.cxf.feature.Feature;
> import org.apache.cxf.jaxrs.openapi.OpenApiFeature;
> import java.util.Collection;
> import java.util.HashSet;
> import java.util.Set;
> import javax.ws.rs.ApplicationPath;
> import javax.ws.rs.core.Application;
> import static java.util.Objects.requireNonNull;
> @ApplicationPath("FooService")
> public class FooServiceApplication extends Application
> {
> @Override
> public Set> getClasses ()
> {
> Set> classes = new HashSet<>();
> classes.add(Resource1.class);
> classes.add(Resource2.class);
> return classes;
> }
> @Override
> public Set getSingletons ()
> {
> Set singletons = new HashSet<>();
> singletons.add(openapiFeature());
> return singletons;
> }
> private Feature openapiFeature () {
> /*
> * Enables automatic Swagger document generation for the web service.
> */
> OpenApiFeature feature = new OpenApiFeature();
> feature.setTitle("FooService");
> feature.setReadAllResources(false);
> feature.setPrettyPrint(true);
> feature.setSupportSwaggerUi(true);
> return feature;
> }
> }
> {code}
> * Corresponding servlet config - Swagger-UI support does not enable unless
> the commented-out section below is enabled.
>
> {code:java}
>
> http://java.sun.com/xml/ns/javaee; version="3.0">
>
> FooService
>
>
> FooService
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
>
> javax.ws.rs.Application
> org.foo.service.FooServiceApplication
>
>
> 1
>
>
>
> SLA835Gateway
> /*
>
>
>
> 1
>
>
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8167) Restrict the URI schemes allowed when importing schemas or WSDLs
[ https://issues.apache.org/jira/browse/CXF-8167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8167. > Restrict the URI schemes allowed when importing schemas or WSDLs > > > Key: CXF-8167 > URL: https://issues.apache.org/jira/browse/CXF-8167 > Project: CXF > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.4.0, 3.3.5 > > > This task is to restrict the valid URI schemes when importing schemas or > WSDLS to: http(s), file, classpath, jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8170) Failure to parse multiple comma separated links in an HTTP Link header on a Jaxrs Response object
[
https://issues.apache.org/jira/browse/CXF-8170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8170.
> Failure to parse multiple comma separated links in an HTTP Link header on a
> Jaxrs Response object
> -
>
> Key: CXF-8170
> URL: https://issues.apache.org/jira/browse/CXF-8170
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.11, 3.3.4
> Environment: Web
>Reporter: Benjamin Marwell
>Priority: Blocker
> Labels: pull-request-available
> Fix For: 3.4.0, 3.3.5, 3.2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {color:#FF}*Blocker: Specification violation resulting in
> RuntimeException*{color}
> Dear Apache Contributors,
> Recently I authored a pull request for OpenLiberty, which was then created by
> [https://github.com/WhiteCat22.]
>
> Original issue:
> [https://github.com/OpenLiberty/open-liberty/issues/8863]
>
> Original PR:
> [https://github.com/OpenLiberty/open-liberty/pull/8956]
> h2. Description
> If a server returns HTTP link headers, it may do so with responding multiple
> link headers, or just one link header with comma separated fields.
> CXF only recognizes multiple link headers. If only one link header with
> multiple values was supplied, it will throw an unexpected RuntimeException:
> {{java.lang.IllegalArgumentException: Illegal character in query at index
> n}}: (Link header here)
> {{Caused by: java.net.URISyntaxException: Illegal character in query at
> index}}
> h2. Examples
> h3. Working Response:
> {{HTTP/1.1}}
> {{Link: ;rel="first"}}
> {{Link: ;rel="next"}}
> {{Link: ;rel="last"}}
> h3. Not working response:
> {{HTTP/1.1}}
> {{Link:
> ;rel="first",;rel="next",;rel="last"}}
> That should have worked, though.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CXF-8145) Need property for suffix-list data file
[ https://issues.apache.org/jira/browse/CXF-8145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8145. > Need property for suffix-list data file > --- > > Key: CXF-8145 > URL: https://issues.apache.org/jira/browse/CXF-8145 > Project: CXF > Issue Type: Improvement > Components: Build system, Transports >Reporter: Thomas Cunningham >Assignee: Freeman Yue Fang >Priority: Major > Fix For: 3.4.0, 3.3.5 > > > I'm trying to build behind a firewall but I'm stopped by the wget in > rt/transports/http/pom.xml. I'd like to make that a property so that when > I build, I can change it to a file url that my proxy can deal with. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CXF-8185) Generated Ephemeral Public Key missing in JWE Headers when Json Serialization is used
[ https://issues.apache.org/jira/browse/CXF-8185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8185. > Generated Ephemeral Public Key missing in JWE Headers when Json Serialization > is used > - > > Key: CXF-8185 > URL: https://issues.apache.org/jira/browse/CXF-8185 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.3.4 >Reporter: Frederik Libert >Assignee: Colm O hEigeartaigh >Priority: Blocker > Fix For: 3.3.5 > > Time Spent: 20m > Remaining Estimate: 0h > > When using Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static > (ECDH-ES), the > JWA Specification says that an Ephemeral Public Key MUST be set as "epk" > Header Parameter ( > https://tools.ietf.org/html/rfc7518#page-16). > The key is generated during the encryption process. > However, it is only added to the jwe output when using compact serialization. > When using Json serialization, the header gets lost somewhere along the way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
