[jira] [Reopened] (CXF-7907) Change jaxb-api to jakarta.xml.bind-api artifact dependency
[ https://issues.apache.org/jira/browse/CXF-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reopened CXF-7907: -- Hi Freeman, Just some minor things: a) In parent/pom.xml, in the Java9 profile we have: jakarta.xml.bind jakarta.xml.bind-api 2.3.2 Do we still need to define the JAXB API separately for Java 9 here? If yes it should use the version String instead of 2.3.2. b) In distribution/src/main/release/samples/pom.xml we define: 2.3.0 Do we need the bind-api here as well? > Change jaxb-api to jakarta.xml.bind-api artifact dependency > --- > > Key: CXF-7907 > URL: https://issues.apache.org/jira/browse/CXF-7907 > Project: CXF > Issue Type: Task >Reporter: Dennis Kieselhorst >Assignee: Freeman Fang >Priority: Minor > Fix For: 3.3.0 > > > see [https://github.com/eclipse-ee4j/jaxb-api/pull/66] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7940) FileUtils.delete dramatically slowdown WildFly server shutdown
Viacheslav created CXF-7940:
---
Summary: FileUtils.delete dramatically slowdown WildFly server
shutdown
Key: CXF-7940
URL: https://issues.apache.org/jira/browse/CXF-7940
Project: CXF
Issue Type: Bug
Components: Core
Affects Versions: 3.0.0-milestone1, 3.3.0
Environment: *OS*: Windows
*AppServer*: WildFly 10.0.0.1.Final
*CXF*: cxf-core-3.1.6
*jbossws-cxf*: jbossws-cxf-server-5.1.5.Final.jar
Reporter: Viacheslav
*Brief introduction:*
We use WildFly server.
As we know, WildFly based on JBoss Application Server.
WildFly have an integration with Apache CXF through
"[jbossws-cxf|https://github.com/jbossws/jbossws-cxf]"; project.
When WildFly server is stops we see repeated invokes of
WSDLFilePublisher.java#unpublishWsdlFiles that invoke FileUtils#removeDir
*Cause of problems:*
When the method FileUtils#removeDir is invoked then we see the invoke of
FileUtils#delete:
https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/helpers/FileUtils.java#L254.
We see some strange code:
{code:java}
public static void delete(File f, boolean inShutdown) {
if (!f.delete()) {
if (isWindows()) {
System.gc();
}
{code}
This leads to dramatically slowdown of WildFly server shutdown on Windows
systems.
For example, our WildFly server stops in 2781ms without this call AND stops in
119882ms with this call (~ 43 times slower).
*Questions:*
What is the reason of this code?
Is it bug? What are the disadvantages of removing this code?
Last changes of this code from Git Blame:
[commit|https://github.com/apache/cxf/commit/88a9451b92180609b7bb93d0314bc8384f0c24a4#diff-b620deea897fb467b6f42abd1c32b7f2R138].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-7940) FileUtils.delete dramatically slowdown WildFly server shutdown
[
https://issues.apache.org/jira/browse/CXF-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viacheslav updated CXF-7940:
Environment:
*OS*: Windows
*AppServer*: WildFly 10.0.0.1.Final
*CXF*: cxf-core-3.1.6
*jbossws-cxf*: jbossws-cxf-server-5.1.5.Final
was:
*OS*: Windows
*AppServer*: WildFly 10.0.0.1.Final
*CXF*: cxf-core-3.1.6
*jbossws-cxf*: jbossws-cxf-server-5.1.5.Final.jar
> FileUtils.delete dramatically slowdown WildFly server shutdown
> --
>
> Key: CXF-7940
> URL: https://issues.apache.org/jira/browse/CXF-7940
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.0-milestone1, 3.3.0
> Environment: *OS*: Windows
> *AppServer*: WildFly 10.0.0.1.Final
> *CXF*: cxf-core-3.1.6
> *jbossws-cxf*: jbossws-cxf-server-5.1.5.Final
>Reporter: Viacheslav
>Priority: Minor
>
> *Brief introduction:*
> We use WildFly server.
> As we know, WildFly based on JBoss Application Server.
> WildFly have an integration with Apache CXF through
> "[jbossws-cxf|https://github.com/jbossws/jbossws-cxf]"; project.
> When WildFly server is stops we see repeated invokes of
> WSDLFilePublisher.java#unpublishWsdlFiles that invoke FileUtils#removeDir
> *Cause of problems:*
> When the method FileUtils#removeDir is invoked then we see the invoke of
> FileUtils#delete:
> https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/helpers/FileUtils.java#L254.
> We see some strange code:
> {code:java}
> public static void delete(File f, boolean inShutdown) {
> if (!f.delete()) {
> if (isWindows()) {
> System.gc();
> }
> {code}
> This leads to dramatically slowdown of WildFly server shutdown on Windows
> systems.
> For example, our WildFly server stops in 2781ms without this call AND stops
> in 119882ms with this call (~ 43 times slower).
> *Questions:*
> What is the reason of this code?
> Is it bug? What are the disadvantages of removing this code?
> Last changes of this code from Git Blame:
> [commit|https://github.com/apache/cxf/commit/88a9451b92180609b7bb93d0314bc8384f0c24a4#diff-b620deea897fb467b6f42abd1c32b7f2R138].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7940) FileUtils.delete dramatically slowdown WildFly server shutdown
[
https://issues.apache.org/jira/browse/CXF-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16740360#comment-16740360
]
Colm O hEigeartaigh commented on CXF-7940:
--
I'll remove this code.
> FileUtils.delete dramatically slowdown WildFly server shutdown
> --
>
> Key: CXF-7940
> URL: https://issues.apache.org/jira/browse/CXF-7940
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.0-milestone1, 3.3.0
> Environment: *OS*: Windows
> *AppServer*: WildFly 10.0.0.1.Final
> *CXF*: cxf-core-3.1.6
> *jbossws-cxf*: jbossws-cxf-server-5.1.5.Final
>Reporter: Viacheslav
>Assignee: Colm O hEigeartaigh
>Priority: Minor
>
> *Brief introduction:*
> We use WildFly server.
> As we know, WildFly based on JBoss Application Server.
> WildFly have an integration with Apache CXF through
> "[jbossws-cxf|https://github.com/jbossws/jbossws-cxf]"; project.
> When WildFly server is stops we see repeated invokes of
> WSDLFilePublisher.java#unpublishWsdlFiles that invoke FileUtils#removeDir
> *Cause of problems:*
> When the method FileUtils#removeDir is invoked then we see the invoke of
> FileUtils#delete:
> https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/helpers/FileUtils.java#L254.
> We see some strange code:
> {code:java}
> public static void delete(File f, boolean inShutdown) {
> if (!f.delete()) {
> if (isWindows()) {
> System.gc();
> }
> {code}
> This leads to dramatically slowdown of WildFly server shutdown on Windows
> systems.
> For example, our WildFly server stops in 2781ms without this call AND stops
> in 119882ms with this call (~ 43 times slower).
> *Questions:*
> What is the reason of this code?
> Is it bug? What are the disadvantages of removing this code?
> Last changes of this code from Git Blame:
> [commit|https://github.com/apache/cxf/commit/88a9451b92180609b7bb93d0314bc8384f0c24a4#diff-b620deea897fb467b6f42abd1c32b7f2R138].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CXF-7940) FileUtils.delete dramatically slowdown WildFly server shutdown
[
https://issues.apache.org/jira/browse/CXF-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned CXF-7940:
Assignee: Colm O hEigeartaigh
> FileUtils.delete dramatically slowdown WildFly server shutdown
> --
>
> Key: CXF-7940
> URL: https://issues.apache.org/jira/browse/CXF-7940
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.0-milestone1, 3.3.0
> Environment: *OS*: Windows
> *AppServer*: WildFly 10.0.0.1.Final
> *CXF*: cxf-core-3.1.6
> *jbossws-cxf*: jbossws-cxf-server-5.1.5.Final
>Reporter: Viacheslav
>Assignee: Colm O hEigeartaigh
>Priority: Minor
>
> *Brief introduction:*
> We use WildFly server.
> As we know, WildFly based on JBoss Application Server.
> WildFly have an integration with Apache CXF through
> "[jbossws-cxf|https://github.com/jbossws/jbossws-cxf]"; project.
> When WildFly server is stops we see repeated invokes of
> WSDLFilePublisher.java#unpublishWsdlFiles that invoke FileUtils#removeDir
> *Cause of problems:*
> When the method FileUtils#removeDir is invoked then we see the invoke of
> FileUtils#delete:
> https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/helpers/FileUtils.java#L254.
> We see some strange code:
> {code:java}
> public static void delete(File f, boolean inShutdown) {
> if (!f.delete()) {
> if (isWindows()) {
> System.gc();
> }
> {code}
> This leads to dramatically slowdown of WildFly server shutdown on Windows
> systems.
> For example, our WildFly server stops in 2781ms without this call AND stops
> in 119882ms with this call (~ 43 times slower).
> *Questions:*
> What is the reason of this code?
> Is it bug? What are the disadvantages of removing this code?
> Last changes of this code from Git Blame:
> [commit|https://github.com/apache/cxf/commit/88a9451b92180609b7bb93d0314bc8384f0c24a4#diff-b620deea897fb467b6f42abd1c32b7f2R138].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-7940) FileUtils.delete dramatically slowdown WildFly server shutdown
[
https://issues.apache.org/jira/browse/CXF-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-7940:
-
Fix Version/s: 3.3.0
> FileUtils.delete dramatically slowdown WildFly server shutdown
> --
>
> Key: CXF-7940
> URL: https://issues.apache.org/jira/browse/CXF-7940
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.0-milestone1, 3.3.0
> Environment: *OS*: Windows
> *AppServer*: WildFly 10.0.0.1.Final
> *CXF*: cxf-core-3.1.6
> *jbossws-cxf*: jbossws-cxf-server-5.1.5.Final
>Reporter: Viacheslav
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 3.3.0
>
>
> *Brief introduction:*
> We use WildFly server.
> As we know, WildFly based on JBoss Application Server.
> WildFly have an integration with Apache CXF through
> "[jbossws-cxf|https://github.com/jbossws/jbossws-cxf]"; project.
> When WildFly server is stops we see repeated invokes of
> WSDLFilePublisher.java#unpublishWsdlFiles that invoke FileUtils#removeDir
> *Cause of problems:*
> When the method FileUtils#removeDir is invoked then we see the invoke of
> FileUtils#delete:
> https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/helpers/FileUtils.java#L254.
> We see some strange code:
> {code:java}
> public static void delete(File f, boolean inShutdown) {
> if (!f.delete()) {
> if (isWindows()) {
> System.gc();
> }
> {code}
> This leads to dramatically slowdown of WildFly server shutdown on Windows
> systems.
> For example, our WildFly server stops in 2781ms without this call AND stops
> in 119882ms with this call (~ 43 times slower).
> *Questions:*
> What is the reason of this code?
> Is it bug? What are the disadvantages of removing this code?
> Last changes of this code from Git Blame:
> [commit|https://github.com/apache/cxf/commit/88a9451b92180609b7bb93d0314bc8384f0c24a4#diff-b620deea897fb467b6f42abd1c32b7f2R138].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-7940) FileUtils.delete dramatically slowdown WildFly server shutdown
[
https://issues.apache.org/jira/browse/CXF-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-7940.
--
Resolution: Fixed
> FileUtils.delete dramatically slowdown WildFly server shutdown
> --
>
> Key: CXF-7940
> URL: https://issues.apache.org/jira/browse/CXF-7940
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.0-milestone1, 3.3.0
> Environment: *OS*: Windows
> *AppServer*: WildFly 10.0.0.1.Final
> *CXF*: cxf-core-3.1.6
> *jbossws-cxf*: jbossws-cxf-server-5.1.5.Final
>Reporter: Viacheslav
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 3.3.0
>
>
> *Brief introduction:*
> We use WildFly server.
> As we know, WildFly based on JBoss Application Server.
> WildFly have an integration with Apache CXF through
> "[jbossws-cxf|https://github.com/jbossws/jbossws-cxf]"; project.
> When WildFly server is stops we see repeated invokes of
> WSDLFilePublisher.java#unpublishWsdlFiles that invoke FileUtils#removeDir
> *Cause of problems:*
> When the method FileUtils#removeDir is invoked then we see the invoke of
> FileUtils#delete:
> https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/helpers/FileUtils.java#L254.
> We see some strange code:
> {code:java}
> public static void delete(File f, boolean inShutdown) {
> if (!f.delete()) {
> if (isWindows()) {
> System.gc();
> }
> {code}
> This leads to dramatically slowdown of WildFly server shutdown on Windows
> systems.
> For example, our WildFly server stops in 2781ms without this call AND stops
> in 119882ms with this call (~ 43 times slower).
> *Questions:*
> What is the reason of this code?
> Is it bug? What are the disadvantages of removing this code?
> Last changes of this code from Git Blame:
> [commit|https://github.com/apache/cxf/commit/88a9451b92180609b7bb93d0314bc8384f0c24a4#diff-b620deea897fb467b6f42abd1c32b7f2R138].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CXF-7907) Change jaxb-api to jakarta.xml.bind-api artifact dependency
[
https://issues.apache.org/jira/browse/CXF-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16740282#comment-16740282
]
Colm O hEigeartaigh edited comment on CXF-7907 at 1/11/19 3:29 PM:
---
Hi Freeman,
Just some minor things:
a) In parent/pom.xml, in the Java9 profile we have:
jakarta.xml.bind
jakarta.xml.bind-api
2.3.2
Do we still need to define the JAXB API separately for Java 9 here? If yes it
should use the version String instead of 2.3.2.
b) In distribution/src/main/release/samples/pom.xml we define:
2.3.0
Do we need the bind-api here as well?
c) When building the jaxrs system tests I get:
[WARNING]
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: org.glassfish.jaxb:jaxb-runtime:jar -> version
${cxf.jaxb.impl.version} vs ${cxf.jaxb.core.version} @
org.apache.cxf:cxf-parent:[unknown-version],
/home/coheig/src/apache/cxf/parent/pom.xml, line 2131, column 25
was (Author: coheigea):
Hi Freeman,
Just some minor things:
a) In parent/pom.xml, in the Java9 profile we have:
jakarta.xml.bind
jakarta.xml.bind-api
2.3.2
Do we still need to define the JAXB API separately for Java 9 here? If yes it
should use the version String instead of 2.3.2.
b) In distribution/src/main/release/samples/pom.xml we define:
2.3.0
Do we need the bind-api here as well?
> Change jaxb-api to jakarta.xml.bind-api artifact dependency
> ---
>
> Key: CXF-7907
> URL: https://issues.apache.org/jira/browse/CXF-7907
> Project: CXF
> Issue Type: Task
>Reporter: Dennis Kieselhorst
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.3.0
>
>
> see [https://github.com/eclipse-ee4j/jaxb-api/pull/66]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7940) FileUtils.delete dramatically slowdown WildFly server shutdown
[
https://issues.apache.org/jira/browse/CXF-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16740514#comment-16740514
]
Daniel Kulp commented on CXF-7940:
--
Just a note: with the removal of this, if there are temp files that are locked
due to streams not being closed properly, they may remain after shutdown. The
purpose of that line was to hopefully get the file streams and such garbage
collected and finalized so that the files can be removed. With this change,
if the delete fails, it will likely just keep the files around. (and this is
really just Windows issue as all the unix's can delete open files)
> FileUtils.delete dramatically slowdown WildFly server shutdown
> --
>
> Key: CXF-7940
> URL: https://issues.apache.org/jira/browse/CXF-7940
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.0-milestone1, 3.3.0
> Environment: *OS*: Windows
> *AppServer*: WildFly 10.0.0.1.Final
> *CXF*: cxf-core-3.1.6
> *jbossws-cxf*: jbossws-cxf-server-5.1.5.Final
>Reporter: Viacheslav
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 3.3.0
>
>
> *Brief introduction:*
> We use WildFly server.
> As we know, WildFly based on JBoss Application Server.
> WildFly have an integration with Apache CXF through
> "[jbossws-cxf|https://github.com/jbossws/jbossws-cxf]"; project.
> When WildFly server is stops we see repeated invokes of
> WSDLFilePublisher.java#unpublishWsdlFiles that invoke FileUtils#removeDir
> *Cause of problems:*
> When the method FileUtils#removeDir is invoked then we see the invoke of
> FileUtils#delete:
> https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/helpers/FileUtils.java#L254.
> We see some strange code:
> {code:java}
> public static void delete(File f, boolean inShutdown) {
> if (!f.delete()) {
> if (isWindows()) {
> System.gc();
> }
> {code}
> This leads to dramatically slowdown of WildFly server shutdown on Windows
> systems.
> For example, our WildFly server stops in 2781ms without this call AND stops
> in 119882ms with this call (~ 43 times slower).
> *Questions:*
> What is the reason of this code?
> Is it bug? What are the disadvantages of removing this code?
> Last changes of this code from Git Blame:
> [commit|https://github.com/apache/cxf/commit/88a9451b92180609b7bb93d0314bc8384f0c24a4#diff-b620deea897fb467b6f42abd1c32b7f2R138].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7941) SamlValidator does not work with chain trust
Tomas Vanhala created CXF-7941: -- Summary: SamlValidator does not work with chain trust Key: CXF-7941 URL: https://issues.apache.org/jira/browse/CXF-7941 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 3.2.7 Reporter: Tomas Vanhala As explained here [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] WSS4J supports specifying constraints on the subject DN of the certificate used for signature validation. We have successfully applied "direct trust" when receiving SOAP requests containing a signed SAML token. We attempted to migrate to "chain trust" by removing the certificate used to sign the requests from the Merlin trust store, and setting an appropriate Subject DN Cert Constraint. It did not work. Our analysis is that WSS4J's SamlValidator is not able to handle a scenario where the certificate used to sign the requests is not in the trust store. The problem seems to be in the method findPublicKeyInKeyStore() of Merlin.java. We were able to make chain trust (and the Subject DN Cert Constraint) work by including the needed PKI code in a customised SamlValidator, but we would rather not go this route. Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16740545#comment-16740545 ] Colm O hEigeartaigh commented on CXF-7941: -- I need more information to try and diagnose what the issue is. A test-case to reproduce the problem would be ideal. Failing that, what does the KeyInfo of the Signature on the Assertion look like. Are you sure the corresponding issuing certificate is in the truststore? What does your WSS4J/CXF security configuration look like? What code did youhave to add to the customised validator to get it to work? > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Priority: Major > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (CXF-7926) MicroProfile Rest Client 1.2
[ https://issues.apache.org/jira/browse/CXF-7926?focusedWorklogId=184362&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-184362 ] ASF GitHub Bot logged work on CXF-7926: --- Author: ASF GitHub Bot Created on: 11/Jan/19 21:43 Start Date: 11/Jan/19 21:43 Worklog Time Spent: 10m Work Description: andymc12 commented on pull request #499: [CXF-7926] Initial MP Rest Client 1.2 impl - part 2 URL: https://github.com/apache/cxf/pull/499 * This includes generation and propagation of HTTPHeaders via @ClientHeaderParam annotations and ClientHeadersFactory. * Ensuring that timeout props only have effect when using CDI. * Related unit and system tests. * Updates from the milestone 2 release to release candidate 1 of the API and TCK (1.2 final release is expected late next week). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 184362) Time Spent: 20m (was: 10m) > MicroProfile Rest Client 1.2 > > > Key: CXF-7926 > URL: https://issues.apache.org/jira/browse/CXF-7926 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Reporter: Andy McCright >Assignee: Andy McCright >Priority: Major > Fix For: 3.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > MicroProfile Rest Client 1.2 adds a lot of new function that should improve > developer experience and third-party product integration. > > The complete list of issues in the new spec are available here: > [https://github.com/eclipse/microprofile-rest-client/milestone/4?closed=1] > > Some of the highlights are: > * the ability to specify the base URI in the `@RegisterRestClient` > annotation. > * `removeContext` method in `AsyncInvocationInterceptor` interface allowing > cleanup of contexts transferred from the calling thread. > * new `RestClientListener` SPI interface for intercepting Rest Client > instances. > * portable timeout properties. > > The official release of MP Rest Client 1.2 will be some time in late January > or early February 2019. There is a 1.2-m2 (milestone 2) early access release > of the API and TCK that we can build on for the CXF 3.3.0 release. Once the > official release of the API/TCK occurs in early 2019, we can update the maven > dependencies to use the official release as part of 3.3.1 or 3.3.2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
